[discussie] De volgende stappen voor Linux/FreeBSD - Linux en overige clients

zaterdag 25 oktober 2003 01:43

Acties:

Verwijderd

Topicstarter

Linux en FreeBSD zijn ver gevorderd als OS. Maar wat is de volgende stap voor FreeBSD/Linux? Wat is daar voor nodig? Hoe?

Closed source drivers
Opensource drivers zijn beter dan closed source drivers, ze zijn namelijk te porten.
Sommige bedrijven willen graag opensource drivers maken, maar kunnen dat niet zomaar omdat de code van hun closed source drivers code bevat waar ze niet zelf de rechten van hebben. Een voorbeeld hiervan is de nvidia drivers voor XFree86. In die code zitten OpenGL extensies van Sgi. (of was het een ander bedrijf?) die niet in de nv driver zitten.
Het is ook moeilijk voor bedrijven om een driver te maken die geschikt is voor meerdere kernels. Er zijn namelijk meerdere distributies die meerdere kernels hebben, eventueel met patches, en gebruikers kunnen hun kernels nog zelf aanpassen. Er kan dus niet makkelijk een driver voor Linux 2.4 of 2.6 gemaakt worden omdat er zo ontzettend veel versies van die kernels zijn. En die versies verschillen ook nog is enorm. (En grsec of SELinux zal helemaal moeilijk zijn.)
Met FreeBSD is dit eenvoudiger.

Hibernate / Suspend
Windows en Solaris ondersteunen al tijden hibernate/sys-suspend. Dit is leuk voor desktops en laptops. Er zijn suspend-to-disk en suspend-to-ram projecten voor Linux. Dit zal standaard in de kernel en in gnome/kde moeten zitten.

Software installatie
Het zal voor een normale gebruiker makkelijk moeten zijn om b.v. JBuilder of OpenOffice.org te installeren ongeacht de distributie. En dat geld ook voor het deinstalleren. met yast apt/synaptic is het voor een normale gebruiker al makkelijk genoeg om de software te installeren die met de distributie mee is geleverd.

Persistant hardware IDs
Ik voegde vandaag een disk toe aan een van m'n sun systemen. De disk die daarin zat had scsiid 3 gekregen. (SCA gebeuren). Toen voegde ik die nieuw schijf toe, en omdat de rest van de scsiid's al gebruikt werd, gebruikte ik scsiid 2. Toen wilde hij dus niet meer booten, m'n rootfs is namelijk /dev/sda5. Maar die schijf was nu niet de 1e (sda) maar de 2e schijf (sdb) geworden.
Als die schijf niet /dev/sda had geheten, maar /dev/c0t3p5 (controller 0, target 3, partitie 5), dan was alles wel goed gegaan. devfs probeert dit op te lossen. dit probleem is redelijk groot bij het gebruik van meerder netwerkkaarten voor b.v. een zebra router.

LDAP intergratie, en tools
ActiveDirectory/eDirectory is de toekomst. Linux/FreeBSD heeft OpenLDAP, maar dat moet nog een inhaalslag gaan leveren. (zie: ldap guide)

Groupware
Met evolution is er een goede exchange client voor Linux. Nu nog een server gedeelte. Dit gaat dan vooral om het calender gedeelte.
Met Mozilla op meerder computers en IMAP kan ik op meerdere systemen m'n mail lezen. Maar m'n Addresbook, Mailfilters, Junkfilters, en Calender worden niet zo makkelijk gedeeld.

Monitoring
RedHat Network is een van de weinige services die de patch status van meerdere systemen weergeeft. (al moet je wel betalen als je meerdere systemen hebt

) Dat soort dingen zijn handig voor de corporate desktop. (Als je duizenden systemen hevbt, wil je weten welke je nog moet patchen) SNMP tools zouden gebruiksvriendelijker moeten worden om dit gedaan te krijgen. Syslog zou beter gebruikt moeten gaan worden. (mijn hp laserjet schrijft naar m'n syslog van m'n desktop

)

IPv6
Linux en FreeBSD kunnen goed met IPv6 overweg, maar nog niet goed genoeg. Nog niet alle apps ondersteunen IPv6. Providers moeten dit nog beter gaan ondersteunen. (XS4ALL $_/-\o_$ ) Maar het moet ook makkelijker worden om proxy/nat gebeuren goed in te stellen. (al zijn er met ipv6 genoeg ip's zodat nat alleen voor de security nog interessant is)

Volgensmij gaat het met de politiek (op de DMCA na) redelijk goed. En GNOME vs. KDE is ook niet echt een issue. Office ondersteuning is goed. (op een access clone na). Hardware en Software voor Linux/FreeBSD is er genoeg.

Iemand oplossingen, ideeën of andere problemen?

[ Voor 11% gewijzigd door Verwijderd op 25-10-2003 14:24 . Reden: spell ]

zaterdag 25 oktober 2003 03:21

Acties:

CyBeR

💩

Verwijderd schreef op 25 October 2003 @ 01:43:

Persistent hardware IDs

Als die schijf niet /dev/sda had geheten, maar /dev/c0t3p5 (controller 0, target 3, partitie 5), dan was alles wel goed gegaan. devfs probeert dit op te lossen.

Moet je me even uitleggen waarom dat gaat werken, want ik zie het zo: Verwissel je drive van controller? C wordt anders. Verwissel je drive van SCSI-ID? T wordt anders. Het enige dat gelijk blijft is P. Je hebt er dus minder aan dan de 'normale' aanduidingen omdat ze IMO minder leesbaar zijn en makkelijker fout te typen.

Dit probleem is IMO niet op te lossen door drives op deze manier te identificeren. Die zou je moeten identificeren aan de hand van, bijvoorbeeld, een label in de partitietabel. Nu zijn er gegarandeerd betere mechanismen om dat bij te houden, maar het is laat en ik heb geen zin om ze te bedenken

Anyway, ik ben het er albsoluut mee eens dat hier wat aan gedaan moet worden, ik heb ook al gezien dat sda, sdb, en sdc van plaats verwisselden en dat ik niet meer kon booten omdat ik vergeten was dat aan te passen.

All my posts are provided as-is. They come with NO WARRANTY at all.

zaterdag 25 oktober 2003 05:33

Acties:

Verwijderd

Wat je wil met "Persistant hardware IDs" zou met udev (userspace devfs) en sysfs mogelijk gaan worden, in de pdf geven ze daar een paar voorbeelden van. Alleen zal dit waarschijnlijk pas gebruiksklaar zijn ergen midden in de 2.7 kernelversie.

Vastere kernel interfaces voor drivers zou ik ook erg graag zien, maar ik zie eerder hardware fabrikanten hun drivers opensources dan dat de kernel devvers een vaste driver interface accepteren. Als het je alleen om video drivers gaat zou je kunnen kijken naar SciTech SNAP voor linux. Daarmee zou het mogelijk zijn om dezelfde binary driver te gebruiken op OS/2, Linux en in de toekomst mischien ook BSD en Windows. Als videokaart makers niet te overtuigen zijn om hun drivers en specs te opensourcen zou SNAP een goede 2e keus zijn.

zaterdag 25 oktober 2003 11:39

Acties:

Verwijderd

Topicstarter

CyBeR schreef op 25 October 2003 @ 03:21:

Moet je me even uitleggen waarom dat gaat werken, want ik zie het zo: Verwissel je drive van controller? C wordt anders. Verwissel je drive van SCSI-ID? T wordt anders. Het enige dat gelijk blijft is P. Je hebt er dus minder aan dan de 'normale' aanduidingen omdat ze IMO minder leesbaar zijn en makkelijker fout te typen.

sda is de eerste scsi schijf. eerst was dat target 3. er was 1 schijf.
toen kwam er een 2e schijf bij, met target 2.
nu is de schijf die eerste de eerste was de tweede (dus sdb) geworden.
de oude schijf is niet van ID en/of Controller veranderd.
Bij RedHat proberen ze dat op te losssen door de labels van partities te gebruiken in fstab, maar dit is niet de meest mooie oplossing. In het mooiste gevan zou ik willen zeggen: Ik wil van de boot partitie van de schijf met ID ST950430303 willen booten.
En dan nog iets, als je een server met een boel schijven hebt is het wel zo makkelijk om te weten welke er zo juis overleden is zo dat je niet per ongeluk de verkeerde er uit haald. (er zijn servers met honderden schijven)
Zie hier voor een toespraak van Martin Schwenke over dit onderwerp.

Dit probleem is IMO niet op te lossen door drives op deze manier te identificeren. Die zou je moeten identificeren aan de hand van, bijvoorbeeld, een label in de partitietabel. Nu zijn er gegarandeerd betere mechanismen om dat bij te houden, maar het is laat en ik heb geen zin om ze te bedenken

De RedHat manier dus?

Anyway, ik ben het er albsoluut mee eens dat hier wat aan gedaan moet worden, ik heb ook al gezien dat sda, sdb, en sdc van plaats verwisselden en dat ik niet meer kon booten omdat ik vergeten was dat aan te passen.

En met netwerkkaarten is dit helemaal leuk. Ik had een keer dat bij een systeem met 2 nics, waarvan de ene zonder beveiliging aan een LAN hing en aan de andere interface zat een DSL verbinding, die beveiligd moest zijn. Maar opeens waren eth0 en eth1 verwisseld en waren de samba shares alleen over internet beschikbaar

zaterdag 25 oktober 2003 12:48

Acties:

mOrPhie

❤️❤️❤️❤️🤍

Verwijderd schreef op 25 October 2003 @ 01:43:

LDAP intergratie, en tools
ActiveDirectory/eDirectory is de toekomst. Linux/FreeBSD heeft OpenLDAP, maar dat moet nog een inhaalslag gaan leveren. (zie: ldap guide)

Hou in de gaten dan Novell de linux-kant op aan het gaan is. Het overnemen van Ximian, de development van Novell Linux e.a. zijn belangrijke punten. Ik denk dat je diezins wel kan stellen, dat Novell directory-services voor linux highly wil gaan ondersteunen. Althans, dat gok ik zo.

Chris stone zei ooit ooit dat Netware nooit zou verdwijnen, maar met het betreden van het linux-segment denk ik dat ze die mening nog wel 'ns bij zouden gaan stellen.

Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.

zaterdag 25 oktober 2003 13:01

Acties:

AlterEgo

De technische aandachtspunten die genoemd worden zijn zeker van belang, maar volgens mij is de volgende stap politiek, niet technisch:
Open standaarden moeten worden afgedwongen. Zonder deze open standaarden worden de ontwikkeling van software hopeloos vertraagd, en zal er nooit een economisch gezonde bedrijfstak kunnen ontstaan. Juridisch is er ook nog een en ander mis (EUCD/DMCA).
Totdat er voldoende kritische massa is bereikt staat linux/BSD in het defensieve hoekje.

zaterdag 25 oktober 2003 13:43

Acties:

CyBeR

💩

Verwijderd schreef op 25 October 2003 @ 11:39:
[...]

sda is de eerste scsi schijf. eerst was dat target 3. er was 1 schijf.
toen kwam er een 2e schijf bij, met target 2.
nu is de schijf die eerste de eerste was de tweede (dus sdb) geworden.
de oude schijf is niet van ID en/of Controller veranderd.
Bij RedHat proberen ze dat op te losssen door de labels van partities te gebruiken in fstab, maar dit is niet de meest mooie oplossing. In het mooiste gevan zou ik willen zeggen: Ik wil van de boot partitie van de schijf met ID ST950430303 willen booten.
En dan nog iets, als je een server met een boel schijven hebt is het wel zo makkelijk om te weten welke er zo juis overleden is zo dat je niet per ongeluk de verkeerde er uit haald. (er zijn servers met honderden schijven)
Zie hier voor een toespraak van Martin Schwenke over dit onderwerp.

Mja het is minder veranderlijk dan de huidige manier, maar het is nog steeds heel makkelijk om te laten veranderen.

De RedHat manier dus?

Het schijnt.

En met netwerkkaarten is dit helemaal leuk. Ik had een keer dat bij een systeem met 2 nics, waarvan de ene zonder beveiliging aan een LAN hing en aan de andere interface zat een DSL verbinding, die beveiligd moest zijn. Maar opeens waren eth0 en eth1 verwisseld en waren de samba shares alleen over internet beschikbaar

Ik heb 3 nics, waarvan 1 built-in (Altijd eth0). De andere nics zijn nog NOOIT van interface gewisseld, dus ik weet niet wat je er mee gedaan hebt om dat voor elkaar te krijgen.. Bovendien is het eventueel hard te maken met kernel arguments.

All my posts are provided as-is. They come with NO WARRANTY at all.

zaterdag 25 oktober 2003 14:18

Acties:

Verwijderd

Topicstarter

CyBeR schreef op 25 October 2003 @ 13:43:

Ik heb 3 nics, waarvan 1 built-in (Altijd eth0). De andere nics zijn nog NOOIT van interface gewisseld, dus ik weet niet wat je er mee gedaan hebt om dat voor elkaar te krijgen.. Bovendien is het eventueel hard te maken met kernel arguments.

Nieuwe kernel, een bios update, etc. vooral bij meerder kaarten van exact het zelfde type is dit lastig. Als ik het me goed herinner doet FreeBSD het op de Solaris manier, onder solaris heb je namelijk le0, hme0 (lance ethernet, happy meal ethernet) en onder FreeBSD xl0 etc. (3com etherlink xl) Voor elke driver heet de interface dus anders. Dit is wel lastig als je op een machine simpelweg het ip van de netwerk kaart wilt achter halen, onder linux is dit namelijk "ifconfig eth0" en bij FreeBSD en Solaris moet je dus weten welke driver er wordt gebruikt, of ifconfig -a doen.

zondag 26 oktober 2003 02:40

Acties:

Verwijderd

Oh man, die device filesystem bezorgt me dagelijks hoofdpijn. Ik wil dat helemaal niet. Okee, stel je voor: ik wil een GUI maken (dat is per definitie het einddoel - servers boeien niet) en daarin wil ik alle soundcards listen...

Goed, vertel maar... /dev/dsp (75%), /dev/sound/dsp (95%), /dev/audio/dsp (99%), /dev/sound (99,3%), ... En dan heb ik alleen maar OSS... Bij ALSA is dit nog veel ingewikkelder... hw:0, hwdev:0, sw:0, ... Linux (of Unix) is een horrible piece of crap als je al dit soort inconsistensies bij elkaar optelt. Er moet iets komen om dit op te lossen. Het boeit me niet of die device op dev/foo of /dev/bar zit, ik wil een GUI maken met de naam van de hardware ("Maxtor HD") als selectiemogelijkheid.

Vind daar nou eens een oplossing voor.

. Die kernel is goed zat - we moeten aan bruikbaarheid werken.

zondag 26 oktober 2003 02:50

Acties:

Verwijderd

Jij bedoelt de HAL zoals bij Windows..?

[ Voor 74% gewijzigd door Verwijderd op 26-10-2003 02:52 ]

zondag 26 oktober 2003 09:43

Acties:

Verwijderd

HAL werkt toevallig omdat Microsoft alle driver interfaces controleert, zoiets is veel te beperkt voor een extendible interface systeem zoals Linux/Unix. Maar inderdaad, zoiets dergelijks moet er wel ooit eens komen.

DevFS was een leuk idee, maarja, zoals je ziet gebruikt slechts een klein deel van de gebruikers het, en dan heb je er al niks meer aan...

zondag 26 oktober 2003 12:37

Acties:

Verwijderd

Ze zouden misschien aan het virtualiseren kunnen denken zonder de HAL helemaal te kopieren, en de koppelig op software interface niveau zetten in plaats van die devFS.

Maar inderdaad, wie controleert de drivers dan op functioneren....

Wat ze kunnen doen misschien is dat deel van de ontwikkelaars dat nu devFS doen, in een ander "Linux driver forum" organiseren...

PS
Beelzebubu-> Een andere vraag die er wel op aansluit denk ik, kun je onder linux de PCI-identificatie strings scannen / opvragen zoals het systeem die herkent, of moet je dat helemaal zelf implementeren ?

[ Voor 30% gewijzigd door Verwijderd op 26-10-2003 12:46 ]

zondag 26 oktober 2003 12:54

Acties:

Verwijderd

Verwijderd schreef op 26 October 2003 @ 12:37:
Beelzebubu-> Een andere vraag die er wel op aansluit denk ik, kun je onder linux de PCI-identificatie strings scannen / opvragen zoals het systeem die herkent, of moet je dat helemaal zelf implementeren ?

Het enige wat de kernel kent zijn de PCI device/vendor IDs en subIDs (4x 16bit). De link tussen device string en IDs zit in applicaties, de kernel heeft daar geen weet van. Voor een complete beschrijving van alle IDs die de kernel momenteel herkent, zie /usr/src/linux/include/linux/pci_ids.h. Daar staat ook een beschrijving van elke ID. Overigens staan subIDs/IDs of vendor/device IDs compleet random door elkaar.

.

zondag 26 oktober 2003 18:10

Acties:

Verwijderd

Trouwens, waarom mis ik desktop-werk in dit topic?

.

zondag 26 oktober 2003 19:36

Acties:

Verwijderd

Verwijderd schreef op 26 October 2003 @ 18:10:
Trouwens, waarom mis ik desktop-werk in dit topic? .

- alle major Linux distro's (en BSDs??) over naar ALSA
- gstreamer multimedia backend voor zowel GNOME als KDE
- alle office APPS de bestandformaten van OOo/Star Office laten gebruiken
- database als filesystem voor multimedia/documenten etc
- nieuwe init om eerder gdm/kdm weer te geven

maandag 27 oktober 2003 10:17

Acties:

Verwijderd

Verwijderd schreef op 26 October 2003 @ 19:36:
- alle major Linux distro's (en BSDs??) over naar ALSA

.

. _{ALSA is zo broken als het maar kan. ALSA is over-complicated crap, er zijn nauwelijks applicaties die ALSA volledig implementeren, laat staan dat er ontwikkelaars zijn die ALSA (willen) begrijpen.}

Nouja, als mensen ALSA willen...

.

- gstreamer multimedia backend voor zowel GNOME als KDE

$_/-\o_$ . _{Had ik al verteld dat GStreamer sinds gisteren eindelijk Sorensen afspeelt? .}

- alle office APPS de bestandformaten van OOo/Star Office laten gebruiken
- database als filesystem voor multimedia/documenten etc

$_/-\o_$ . En multi-root trees in je file manager!

- nieuwe init om eerder gdm/kdm weer te geven

Hm.. RHGB?

.

Nog enkelen:
• standaardisatie op desktop-UI-protocollen via freedesktop.org of Xouvert, dit voor dingen als panel-embedding, WM-applicatie interactie, event notification, etc. Ik wil alle Blackbox en KDE applicaties zonder regressie in Gnome kunnen gebruiken!
• Cross-desktop file-type-linkage. Dit betekent dat ik desnoods vanuit een console een document kan "starten" en dat automatisch de juiste applicatie wordt gestart om die document te openen. Allemaal natuurlijk wel met normale unix security.
• hardware manager a la kudzu of yast2 als standaard onderdeel van elke distributie, met automatische hardware detectie gebaseerd op PCI/USB/... IDs in elke driver beschikbaar in /lib/modules/$(versie)/ (dat bestaat al!) en automatische configuratie van beschikbare modules.
• een video editor.

.

maandag 27 oktober 2003 14:34

Acties:

Verwijderd

Topicstarter

En is het nodig om het formaat waarin config files geschreven worden te standariseren? (zie het verschil tussen apache's conf, slapd's conf, en jabberd's cofigs.) (en waarom zou dit wel/niet XML moeten worden? zoals gconf?)

maandag 27 oktober 2003 14:41

Acties:

dawg

🇪🇺 🇳🇱

Ik denk dat het noodzakelijk is dat men voor elke distro een uniforme standaard aanhoudt (directory-tree, locatie van bestanden, formaat van configuratiebestanden, etc.).

Verder is het belangrijk dat de politiek zich ermee gaat bemoeien:

AlterEgo schreef op 25 October 2003 @ 13:01:
De technische aandachtspunten die genoemd worden zijn zeker van belang, maar volgens mij is de volgende stap politiek, niet technisch:
Open standaarden moeten worden afgedwongen. Zonder deze open standaarden worden de ontwikkeling van software hopeloos vertraagd, en zal er nooit een economisch gezonde bedrijfstak kunnen ontstaan. Juridisch is er ook nog een en ander mis (EUCD/DMCA).
Totdat er voldoende kritische massa is bereikt staat linux/BSD in het defensieve hoekje.

It’s the economy, stupid!

maandag 27 oktober 2003 14:53

Acties:

Verwijderd

Topicstarter

dawg schreef op 27 October 2003 @ 14:41:
Ik denk dat het noodzakelijk is dat men voor elke distro een uniforme standaard aanhoudt (directory-tree, locatie van bestanden, formaat van configuratiebestanden, etc.).

http://www.pathname.com/fhs/

maandag 27 oktober 2003 15:36

Acties:

Verwijderd

Verwijderd schreef op 27 oktober 2003 @ 14:34:
En is het nodig om het formaat waarin config files geschreven worden te standariseren? (zie het verschil tussen apache's conf, slapd's conf, en jabberd's cofigs.) (en waarom zou dit wel/niet XML moeten worden? zoals gconf?)

Waarom? Lijkt me logisch: het schrijven van alternatieve config/parse tools voor dezelfde tool wordt supersimpel en gestandaardiseerd. Is het je al eens opgevallen dat GConf Editor een preferences screen is voor alle Gnome applicaties samen? Denk nu eens aan taken als accessibility of automated first-login config. GConf is onmisbaar!

Nu zie ik Apache nog niet zo snel GConf gebruiken.

. Maar het zou wel goed zijn als in elk geval alle desktop applicaties GConf gebruiken.

maandag 27 oktober 2003 15:55

Acties:

kenneth

achter de duinen

[quote]Verwijderd schreef op 27 October 2003 @ 10:17:
• Cross-desktop file-type-linkage. Dit betekent dat ik desnoods vanuit een console een document kan "starten" en dat automatisch de juiste applicatie wordt gestart om die document te openen. Allemaal natuurlijk wel met normale unix security.
Ik vind zelf de BeOS-manier de beste die er is. Ieder bestand heeft een mimetype (metadata in het FS.) Voor een bepaald mimetype zijn er handlers. Bijvoorbeeld text/html:
• Een generieke voor text (een texteditor ofzo)
• Een specifieke voor html (epiphany), die niet verplicht is. Zo kan je voor image/* alleen gimp instellen, zodat alle plaatjes met gimp worden geopend.

Die stel je systeemwijd in. Je kan dan nog evt. voor een enkel bestand een andere handler instellen.

Stukken beter dan het foute extensiesysteem uit Windows, en het praktisch ontbreken van enig systeem onder Linux.

[q]• een video editor.

.Aan je werk jij

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

maandag 27 oktober 2003 16:01

Acties:

AlterEgo

Verwijderd schreef op 27 October 2003 @ 15:36:
[...]
GConf is onmisbaar!

Are you sure [yes/no]

Als ik Gnome-filosofie een beetje begrijp, dan stop je alleen de meest belangrijke configuratie-opties in de menu's, en de rest van de opties in gconf, right?
Daarvoor is zeker wat te zeggen. Het doet me alleen erg denken aan "registry"

, en dat stoort me, want ik vind het een onveilige situatie om vele configuraties op te slaan in 1 bestand, dat eventueel ook nog automagisch geupdate (of verknald) kan worden.

Ik zou er veel meer voor voelen dat configuratie-opties, en veel meer configuraties in een gestandaardiseerde, meer op de desktop-user geënte versie van Webmin zou lijken: een "klikbaar' en universeel frontend waarmee je config-files kan inrichten, en dat je ook behulpzaam zou moeten zijn bij het updaten van config-files bij versie-veranderingen van je software.

maandag 27 oktober 2003 17:06

Acties:

Verwijderd

Topicstarter

kenneth schreef op 27 oktober 2003 @ 15:55:
Ik vind zelf de BeOS-manier de beste die er is. Ieder bestand heeft een mimetype (metadata in het FS.) Voor een bepaald mimetype zijn er handlers. Bijvoorbeeld text/html:
• Een generieke voor text (een texteditor ofzo)
• Een specifieke voor html (epiphany), die niet verplicht is. Zo kan je voor image/* alleen gimp instellen, zodat alle plaatjes met gimp worden geopend.

Die stel je systeemwijd in. Je kan dan nog evt. voor een enkel bestand een andere handler instellen.

Stukken beter dan het foute extensiesysteem uit Windows, en het praktisch ontbreken van enig systeem onder Linux.

Onder unix is het zo geregeld dat je b.v. een file makebackup hebt, waar op de eerste b.v.

code:

1	#!/bin/bash

staat, maar als je dat script uitbreid kan je dat veranderen in

code:

1	#!/usr/bin/perl

zo dat je zonder dat je de filename veranderd toch een andere scripttaal kunt gebruiken. Onder windows zou je 'm van .bat naar .pl moeten renamen.

En die extensies van windows zijn idd slecht. (ga maar is met file door je mp3 collectie, daar zullen vast wel een aantal wav en mpeg2 files tussen zitten.) Ik had een keer een win32 prog wat een file niet wilde openen. (een .gif file) Na die file met file geinspecteerd te hebben bleek het een jpeg file te zijn. ff mv'en naar .jpeg en het werkte weer!

[ Voor 4% gewijzigd door Verwijderd op 27-10-2003 17:08 ]

maandag 27 oktober 2003 17:12

Acties:

kenneth

achter de duinen

compukid, de hash-bang werkt natuurlijk alleen voor scriptfiles. Is erg handig, maar werkt niet voor databestanden.
Het voordeel van mimetypes is dat het (met een goed geconfigureerde webserver) bij downloaden gelijk goedstaat.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

maandag 27 oktober 2003 17:20

Acties:

MadEgg

Tux is lievvv

Die hardware ID's vind ik een belangrijk punt.

Vooral voor USB/firewire mass-storage apparaten is dat erg irritant atm. Ik heb een iPod en een digitale camera, die beide via mass-storage en scsi emulation werken.
Het gevolg daarvan is dat beide op /dev/sda of /dev/sdb etc terecht kunnen komen, afhankelijk of de ander al aangesloten is of niet.

Het gevolg is dus dat ik niet fstab zo kan instellen dat

code:

1	mount /mnt/ipod

en/of

code:

1	mount /mnt/camera

altijd het goede apparaat mount. Vind ik vrij vervelend.

Misschien is http://www.freedesktop.org/Software/hal een uitkomst hiervoor, alhoewel ik het systeem wel weer een beetje teveel op het Windows registry

vind lijken met allerlei sporen die overblijven van ooit aangesloten apparaten. Maar misschien ontkom je daar niet aan om dit probleem op te lossen

Tja

maandag 27 oktober 2003 17:37

Acties:

bkor

AlterEgo schreef op 27 October 2003 @ 16:01:
Als ik Gnome-filosofie een beetje begrijp, dan stop je alleen de meest belangrijke configuratie-opties in de menu's, en de rest van de opties in gconf, right?

Nee, alle configuratie opties zitten in gconf. Sommige opties kunnen ook aangepast worden via de desbetreffende applicatie. Dit is niet opgelegd door gconf (komt voort uit the HIG).

Daarvoor is zeker wat te zeggen. Het doet me alleen erg denken aan "registry" , en dat stoort me, want ik vind het een onveilige situatie om vele configuraties op te slaan in 1 bestand, dat eventueel ook nog automagisch geupdate (of verknald) kan worden.

Gconf slaat (standaard) de configuratie opties op in verschillende bestanden. Je kan natuurlijk ook een nieuwe backend module voor gconf schrijven welke alles in 1 groot binary bestand schrijft (in /tmp met chmod 777 ofzo

).

Ik zou er veel meer voor voelen dat configuratie-opties, en veel meer configuraties in een gestandaardiseerde, meer op de desktop-user geënte versie van Webmin zou lijken: een "klikbaar' en universeel frontend waarmee je config-files kan inrichten, en dat je ook behulpzaam zou moeten zijn bij het updaten van config-files bij versie-veranderingen van je software.

Gconf is alleen een systeem dat de instellingen opslaat. Je kan daaroverheen weer je 200+ wizard 'webmin' systeem maken.

Meer info over gconf: http://www.gnome.org/projects/gconf/plans.html
Bevat een .ps bestand over de mogelijke toekomst van gconf. Hierbij ook vergelijkingen met andere systemen, zoals Windows registry en IntelliMirror.

maandag 27 oktober 2003 19:58

Acties:

AlterEgo

bkor schreef op 27 October 2003 @ 17:37:

+1 informatief/behulpzaam

Voor desktop-integratie heeft een centrale config inderdaad voordelen.
Als je daarin inderdaad alleen user-preferences opslaat, dan zijn de gevaren die ik hierboven schetste overdreven.
Toen ik dacht aan per-user printer-configuraties/keuzes en file-associations (en aan eye-candy) op de desktop, zag ik de voordelen van een gconf wel in.

maandag 27 oktober 2003 22:07

Acties:

deadinspace

The what goes where now?

Verwijderd schreef op 25 October 2003 @ 14:18:
Als ik het me goed herinner doet FreeBSD het op de Solaris manier, onder solaris heb je namelijk le0, hme0 (lance ethernet, happy meal ethernet) en onder FreeBSD xl0 etc. (3com etherlink xl) Voor elke driver heet de interface dus anders.

Maar dat is een workaround, geen oplossing. Wat gebeurt er namelijk met meerdere kaarten die door dezelfde driver ondersteund worden? Exact hetzelfde!

Die hardware identificatie is inderdaad een punt waar werk op verricht mag worden. Volume labels op partities is bijvoorbeeld een aardige, maar dat wordt nog niet extreem veel gebruikt meen ik.

Verwijderd schreef op 26 oktober 2003 @ 02:40:
Goed, vertel maar... /dev/dsp (75%), /dev/sound/dsp (95%), /dev/audio/dsp (99%), /dev/sound (99,3%), ... En dan heb ik alleen maar OSS... Bij ALSA is dit nog veel ingewikkelder... hw:0, hwdev:0, sw:0, ... Linux (of Unix) is een horrible piece of crap als je al dit soort inconsistensies bij elkaar optelt. Er moet iets komen om dit op te lossen. Het boeit me niet of die device op dev/foo of /dev/bar zit, ik wil een GUI maken met de naam van de hardware ("Maxtor HD") als selectiemogelijkheid.

Dat zijn ook OS-specifieke dingen, daar horen applicaties zich niet mee bezig te houden. Wat netjes zou zijn is een library die weet welke devices er zijn, en wat ze betekenen. Programma's kunnen dan aan die library een lijst met sound-devices vragen, compleet met paths naar de devices zelf, details over het device en een human-readable naam. Dat is zowel elegant als prettig voor applicatie-programmeurs als prettig voor gebruikers.

Ik zit nu net over udev te lezen, en dat komt eigenlijk aardig in die richting. Lees bv maar eens http://archive.linuxsympo...Kroah-Hartman-OLS2003.pdf.

Verwijderd schreef op 26 October 2003 @ 19:36:
- alle office APPS de bestandformaten van OOo/Star Office laten gebruiken

Ik zie liever een onafhankelijk opgestelde standaard als universele document standaard (was de OASIS group ook mee bezig iirc).

database als filesystem voor multimedia/documenten etc

Meh, daar zit ik nou echt niet op te wachten.

- nieuwe init om eerder gdm/kdm weer te geven

Zit ik ook niet op te wachten... Dan krijg je van die Windows-praktijken, dat je ingelogd bent en nog niet kunt werken omdat alles nog geladen wordt.

Verwijderd schreef op 27 October 2003 @ 10:17:
standaardisatie op desktop-UI-protocollen via freedesktop.org of Xouvert, dit voor dingen als panel-embedding, WM-applicatie interactie, event notification, etc. Ik wil alle Blackbox en KDE applicaties zonder regressie in Gnome kunnen gebruiken!

Da's bij mijn beste weten niet iets waar Xouvert zich mee bezig houdt... Die opereren een laagje lager

hardware manager a la kudzu of yast2 als standaard onderdeel van elke distributie, met automatische hardware detectie gebaseerd op PCI/USB/... IDs in elke driver beschikbaar in /lib/modules/$(versie)/ (dat bestaat al!) en automatische configuratie van beschikbare modules.

Hmm? Dat is juist hetgene dat per distributie moet verschillen. Verschillende mensen hebben verschillende eisen (ook mbt hardware-detectie en -beheer), en daar springen de verschillende distro's op in.

Verwijderd schreef op 27 October 2003 @ 15:36:
Waarom? Lijkt me logisch: het schrijven van alternatieve config/parse tools voor dezelfde tool wordt supersimpel en gestandaardiseerd. Is het je al eens opgevallen dat GConf Editor een preferences screen is voor alle Gnome applicaties samen? Denk nu eens aan taken als accessibility of automated first-login config. GConf is onmisbaar!

Mja, alleen krijg ik telkens zo'n Windows-registry-huiveringen bij GConf. Ik moet allemaal meuk hebben om een enkele Gnome app te draaien, config settings zijn verspreid over .gconf/, .gnome/ en .galeon/ . Als er iets mis is met Galeon is .conf/ wegflikkeren deel van het oplos-proces. Dan draait er ook nog eens een apart proces voor (al ruimt die zichzelf iig op sinds een tijd). Niet dat het idee van een gegeneraliseerde configuratie slecht is, maar ik ben niet bepaald te spreken over de pogingen tot nu toe.

Nu zie ik Apache nog niet zo snel GConf gebruiken. .

Nee, maar goed ook. Eens even kijken wat gconf allemaal meesleept. oaf, orbit, popt, libwrap, libxml. Apache heeft al genoeg spul nodig as is.

Ik snap dat het voordelen oplevert, maar alles gaan lopen bloaten met te generieke oplossingen is ook niet goed.

maandag 27 oktober 2003 22:43

Acties:

Spider.007

* Tetragrammaton

Het gebruiken van XML om een DTD standaard voor configuratiefiles op te zetten vindt ik wel interessant. Ik denk echter dat de punten die wij hier bediscussieren niet het succes van Linux/FreeBSD zullen bepalen. Deze beslissing ligt namelijk niet in onze (de techneuten) handen.

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate

dinsdag 28 oktober 2003 00:47

Acties:

Verwijderd

^^^ oh so true ^^^

Het gaat erom dat linux eindelijk eens een keer consistent en beheersbaar over gaat komen op grote bedrijven. Er dienen simpelweg nog een paar dingen gedaan te worden voordat het volledige acceptatie zal krijgen:

- fatsoenlijke groupware
- fatsoenlijke directory support
- fatsoenlijke management systemen

Zolang die drie er nog niet zijn zal linux geen grote vlucht nemen. Novell is overigens goed bezig, en brengen binnenkort hun Edirectory en Zenworks(mgmt + policy suite, schijnt multi-distro te zijn) uit voor linux.

[ Voor 12% gewijzigd door Verwijderd op 28-10-2003 00:48 ]

dinsdag 28 oktober 2003 11:40

Acties:

Verwijderd

E-Directory van novell is toch al een tijdje op de mark, ik heb zo'n 1.5 jaar geleden al eens geprobeerd om Linux met E-directory samen te laten werken, maar dat was wat minder suc6. Mijn kennis was dan ook wat minder.

Binnen kort wil ik weer een poging wagen...maar het schijn wel een mooie oplossing te zijn voor een Directory system

dinsdag 28 oktober 2003 11:58

Acties:

Verwijderd

deadinspace schreef op 27 October 2003 @ 22:07:
Dat zijn ook OS-specifieke dingen, daar horen applicaties zich niet mee bezig te houden. Wat netjes zou zijn is een library die weet welke devices er zijn, en wat ze betekenen. Programma's kunnen dan aan die library een lijst met sound-devices vragen, compleet met paths naar de devices zelf, details over het device en een human-readable naam. Dat is zowel elegant als prettig voor applicatie-programmeurs als prettig voor gebruikers.

Ik zit nu net over udev te lezen, en dat komt eigenlijk aardig in die richting. Lees bv maar eens http://archive.linuxsympo...Kroah-Hartman-OLS2003.pdf.

Maar ook dan. Dit soort dingen moeten worden opgelost voor de applicatie. GStreamer zou dat bijvoorbeeld aan de media-kant kunnen of moeten oplossen. Udev zal ik eens bekijken...

.

kenneth schreef op 27 October 2003 @ 15:55:
Ik vind zelf de BeOS-manier de beste die er is. Ieder bestand heeft een mimetype (metadata in het FS.) Voor een bepaald mimetype zijn er handlers.

Zoiets gebruikt gnome-vfs ook (gnome-mime-info). Werkt "redelijk", maar is helaas niet cross-desktop...

Aan je werk jij

Ja papa.

.

dinsdag 28 oktober 2003 13:27

Acties:

Verwijderd

Verwijderd schreef op 26 oktober 2003 @ 09:43:
HAL werkt toevallig omdat Microsoft alle driver interfaces controleert, zoiets is veel te beperkt voor een extendible interface systeem zoals Linux/Unix. Maar inderdaad, zoiets dergelijks moet er wel ooit eens komen.

DevFS was een leuk idee, maarja, zoals je ziet gebruikt slechts een klein deel van de gebruikers het, en dan heb je er al niks meer aan...

Er is wel wat gaande over HAL onder Debian Linux...
http://lists.debian.org/d...evel-200310/msg01881.html
http://www.freedesktop.org/Software/hal

[ Voor 4% gewijzigd door Verwijderd op 28-10-2003 13:28 ]

dinsdag 28 oktober 2003 13:36

Acties:

TGEN

Hmmmx_

Waarom wel Linux algemeen, maar maar een BSD variant?

Pixilated NetphreaX
Dronkenschap is Meesterschap
DragonFly

dinsdag 28 oktober 2003 22:13

Acties:

Verwijderd

Verwijderd schreef op 28 October 2003 @ 20:00:
[...]
Wat is er mis met OpenGroupware.org, Kolab en SuSE OpenExchange? En als client Ximian Evolution (evt. met connector)?
_{OpenExchange is niet gratis evenals de Ximian connector voor ms office. Server kant is nogal in ontwikkel fase. Evolution ondersteund geen Notes en Groupwise. (terwijl 't van novell is )}

OpenGroupware.org ken ik niet, maar ziet er interesanter uit dan de rest:
Kolab is leuk, maar zonder dat je fatsoenlijke kennis hebt van de verschillende subsystemen krijg je dat niet zondermeer in de lucht (waar is de nette installer voor de "standaard" beheerders ?). Om nog maar niet te spreken over de functionaliteit. Groupware werkt bijvoorbeeld alleen maar onder kmail. (en dan alleen nog maar met custom pakketten van het kroupware project. Er zijn echter plannen dit te integreren met de kde main tree...). Theoretisch zou je onder outlook(mbv de insight connector van bynari) ook de groupware functionaliteiten moeten kunnen gebruiken van kolab, maar in de praktijk is het alleen mogelijk om mail via imap te gebruiken. Evolution heeft standaard alleen support voor de imap functionaliteit van kolab, Geen idee of de ximian connector evolution gebruik kan laten maken van de groupware functionaliteit (al betwijfel ik dit ...)

Openexchange is idd niet gratis (zeer zeker niet: E15.000,- exclusief hardware

). De functionaliteit die ik ervan gezien heb is vrij compleet, al heb ik begrepen dat de integratie met outlook nog niet volledig is ... 't voornaamste probleem is de E15.000 en het feit dat je eigenlijk toegeeft dat de oss community niet in staat is om zoiets te bouwen. Het tegendeel word vandaag de dag steeds beter bewezen, alleen zijn de projecten nog niet zo "af" als openexchange dat is.

[...]
Sun ONE Directory? Novell eDirectory? Oracle Internet Directory? OpenLDAP?
_{OpenLDAP is de enige die gratis/opensource is. Slecht geintergreerd.}

Same as above, het mooiste moet uit de oss community komen. Voor een sun directory heb je natuurlijk wel een solaris bak nodig, en dat gaat je afhankelijk van de grootte van de installatie weer bakken met geld kosten. Novell eDir mag ik binnenkort uitproberen, dus daar heb ik nog geen oordeel over. Oracle idir ken ik niet. Alle oplossingen rond OpenLDAP zijn nu te gefragmenteerd en onduidelijk. Hiervoor moet een generieke frontend voor komen, waardoor een willekeurige beheerder het kan installen en onderhouden zonder linux ervoor te hoeven kennen.

[...]
Zenworks zou zijn.

Zenworks voor linux komt eraan (voor 't eind van het jaar uit m'n hoofd)

dinsdag 28 oktober 2003 22:35

Acties:

Verwijderd

Topicstarter

Verwijderd schreef op 28 oktober 2003 @ 22:13:
Voor een sun directory heb je natuurlijk wel een solaris bak nodig, en dat gaat je afhankelijk van de grootte van de installatie weer bakken met geld kosten.

Van de website van Sun ONE Directory:

Supported:

* Sun Solaris 9 Operating System, SPARC Platform Edition (SPARC 32-and 64-bit)
* Sun Solaris 8 Operating System, SPARC Platform Edition (UltraSPARC 32-and 64-bit)
* Sun Solaris 9 Operating System, x86 Platform Edition (Pentium II or later IA-32 processors)
* Linux from Sun (Pentium II or later IA-32 processors)
* Red Hat Linux 7.2 (Pentium II or later IA-32 processors)
* Microsoft Windows 2000 Server and Advanced Server SP3 (Pentium II or later IA-32 processors)
* Hewlett-Packard HP-UX 11.i (PA-RISC 1.1 or 2.0 32- and 64-bit)
* IBM AIX 5.1 (PowerPC processors)

offtopic:
Waarom heet het bij Solaris 9 SPARC en bij Solaris 8 UltraSPARC? Ik dacht dat die IBM dingen POWER heette, en geen PowerPC?

Dus je hebt geen solaris bak nodig.

Novell eDir mag ik binnenkort uitproberen, dus daar heb ik nog geen oordeel over.

Als je 't uitgeprobeerd hebt moet je wel ff op 't forum vertellen of 't beviel.

Alle oplossingen rond OpenLDAP zijn nu te gefragmenteerd en onduidelijk. Hiervoor moet een generieke frontend voor komen, waardoor een willekeurige beheerder het kan installen en onderhouden zonder linux ervoor te hoeven kennen.

Volledig mee eens.

[ Voor 3% gewijzigd door Verwijderd op 28-10-2003 22:38 ]