I am rubber, you are glue
Verder is mijn ervaring dat het een retestabiel OS is waar je op kunt bouwen en wat niet zomaar tegen de vlakte gaat. Wat dat betreft is het ontwikkelen van een OS door een bedrijf in plaats van een opensource gemeenschap absoluut niet zo gek.
Ik hoop dat dit topic vrij blijft van ongefundeerde rants richting SCO; er is meer unix op de wereld dan SCO-UNIX
Wat mij op dit moment het harste stoort is da acpi nog niet fatsoenlijk werkt. (Althans niet op mijn laptop ) Maar ik ben er vrij zeker van dat dit ook wel opgelost geraakt.
Was het met ACPI niet zo dat men zich niet aan de standaart houd? Waardoor oa. linux problemen hebben het ondersteunen.Ti_Uhl schreef op woensdag 29 december 2004 @ 15:37:
Wat mij op dit moment het harste stoort is da acpi nog niet fatsoenlijk werkt. (Althans niet op mijn laptop ) Maar ik ben er vrij zeker van dat dit ook wel opgelost geraakt.
En wat mij een klein beetje stoort is dat er niet 1 global programma verantwoordelijke is. Voor alle instellingen ipv. de meeste in /etc en dan nog een paar ergens in /usr en /opt. En de meeste verschillende opmaak stylen.
Niet dat regedit van microsoft ideeal is, maar komt wel in de buurt. Denk ik
[ Voor 45% gewijzigd door wica op 29-12-2004 15:44 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
---
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
Bijvoorbeeld: de huidige implementatie van gebruikers en rechten.
I am rubber, you are glue
Dat is ook het eerste wat ik graag zou willen wetenSpider.007 schreef op woensdag 29 december 2004 @ 15:43:
Even voor de duidelijkheid die uit het Slashdot artikel ook niet blijkt; gaat het hier om UNIX, om *n?x of om Linux?
De ontwikkelingen van de veel Unices gaan trager dan bij Linux. Dat is jammer, en het kan ze gaan opbreken. Tux is taking over
Een van onze AIX servers:
//L / # ps -ef |wc -l
528
Standaard 500 processen, waarvan veel database processen omdat wij voor veel klanten testdatabases hebben staan. Deze worden niet eens allemaal standaard opgestart omdat er dan teveel geheugen nodig zou zijn
het ultieme jaargetijde.... | #!/usr/bin/girl | Art prints and fun
Verwijderd
• er is geen algemene query call voor hardware capabilities (dit zou een std. ioctl kunnen zijn). Hierdoor is backward compatibility slechts per toeval of via enorme omwegen (zoals een hele layer) te bereiken. Een simpele query call zou bv. std. backwards compatibility van ALSA voor OSS zorgen. Base systemen voor dit soort APIs zou zelfs beter zijn.
• er is geen standaard component- of communicatie-systeem (bv. DBUS). Eigenlijk worden overal pipes gebruikt, wat hopeloos is. Door het missen van een systeem-interface voor communicatie (gerelateerd) is er geen enkele integratie tussen systeem en applicaties, tenzij expliciet zo geprogrammeerd, wat wederom hopeloos is. Grafische systeemconfiguratie is bijvoorbeeld hels. Door iets als knotify/HAL standaard in UNIX te proppen zou systeem-administratie wonderlijk simpel zijn.
• de houding dat alles de taak van een ander is, is ook al hopeloos. De houding van UNIX (en ook sommige Linux) programmeurs is verschrikkelijk, altijd afschuiven op anderen. Doe nou eens waar je voor betaald wordt en make it work. Niet UNIX strict gesproken, maargoed.
• Het gemis aan ACL-achtige functionaliteit in de basisopbouw is, gezien de uitgebreide rechtenstructuur, onbegrijpelijk.
[ Voor 20% gewijzigd door Bergen op 29-12-2004 16:49 ]
Designfouten in UNIX? Hm...
• er is geen algemene query call voor hardware capabilities (dit zou een std. ioctl kunnen zijn). Hierdoor is backward compatibility slechts per toeval of via enorme omwegen (zoals een hele layer) te bereiken. Een simpele query call zou bv. std. backwards compatibility van ALSA voor OSS zorgen. Base systemen voor dit soort APIs zou zelfs beter zijn.Is dit niet het hele doel van de kernel? Of begrijp ik je punt verkeerd?[q]• er is geen standaard component- of communicatie-systeem (bv. DBUS). Eigenlijk worden overal pipes gebruikt, wat hopeloos is. Door het missen van een systeem-interface voor communicatie (gerelateerd) is er geen enkele integratie tussen systeem en applicaties, tenzij expliciet zo geprogrammeerd, wat wederom hopeloos is. Grafische systeemconfiguratie is bijvoorbeeld hels. Door iets als knotify/HAL standaard in UNIX te proppen zou systeem-administratie wonderlijk simpel zijn.Wat is er mis aan pipes? Ik vindt dit overzichtelijker en duidelijker dan de manier waarop MS Windows dit oplost. Zoals het kunnen catten van je /dev/mouse; dat is toch handig? Wat is er hopeloos aan het 'alles is een bestand' principe?[q]• de houding dat alles de taak van een ander is, is ook al hopeloos. De houding van UNIX (en ook sommige Linux) programmeurs is verschrikkelijk, altijd afschuiven op anderen. Doe nou eens waar je voor betaald wordt en make it work. Niet UNIX strict gesproken, maargoed.Is dat echt iets UNIX (Of Linux, of Windows) specifieks?
Maar wel zo overzichtelijk; en ik ben nog nooit een situatie tegengekomen waarbij de huidige permissiestructuur niet voldeed?• Het gemis aan ACL-achtige functionaliteit in de basisopbouw is, gezien de uitgebreide rechtenstructuur, onbegrijpelijk.
---
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
Goed punt. In eerste instantie zou ik zeggen: UNIX als in POSIX compliant en dus geen specifieke smaak/variant/what-have-you. Ik denk ook dat het slashdot artikel daarvan uitgaat.Wilke schreef op woensdag 29 december 2004 @ 15:44:
[...]
Dat is ook het eerste wat ik graag zou willen weten
De rechtenstructuur (bv.) van GNU/Linux is zo goed als gelijk aan die van *BSD. De directory-structuur van AIX is zo goed als gelijk aan die van HP-UX om maar wat te noemen.
In tweede instantie denk ik dat je hier ook best wel kwijt kan wat bv. FreeBSD beter onder de knie heeft dan bv. GNU/Linux. Om daarna ook nog over specifieke distributies te gaan praten lijkt mij wat te low-level.
Dus komt-u maar, wat kan er beter aan ULTRIX?
I am rubber, you are glue
Management en Accountancy mogen xyzzy lezen, andere groepen niet, maar er zijn ook bestanden die alleen Management mag lezen, en bestanden die alleen Accountancy mag lezen.Spider.007 schreef op woensdag 29 december 2004 @ 16:55:
Maar wel zo overzichtelijk; en ik ben nog nooit een situatie tegengekomen waarbij de huidige permissiestructuur niet voldeed?
Wordt al aardig lastig met alleen ugo-permissies.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
wat je vervolens alleen kan oplossen door een nieuwe groep te maken waar zowel management als accountancy inzit. Echter zodra dan alleen de groep Management mag lezen en schrijven en de groep Accountancy alleen mag lezen wodt gaat dit niet zo makkelijk meerkenneth schreef op woensdag 29 december 2004 @ 17:00:
[...]
Management en Accountancy mogen xyzzy lezen, andere groepen niet, maar er zijn ook bestanden die alleen Management mag lezen, en bestanden die alleen Accountancy mag lezen.
Wordt al aardig lastig met alleen ugo-permissies.
afaik kan je aan een file maar 1 groep toekennen qua rechten (ugo)YouKnow schreef op woensdag 29 december 2004 @ 17:47:
Een groep maken met management én een groep met accountancy, waar management rw rechten heeft en accountancy r... Kan toch ook? Of mis ik 't punt nu
Verwijderd
Het is niet afdoende. Met de file structuur en standaard system calls kom je een heel eind, maar net niet ver genoeg. Het zou tof zijn als er voor bepaalde dingen net iets uitgebreidere specificaties zouden zijn, zodat je bijvoorbeeld code kan schrijven die hardware op BSD en Linux op dezelfde manier aanspreekt. Momenteel is portability leuk, maar systeem applicaties zijn een absolute hel vanwege het gebrek aan cross-OS standaarden.Spider.007 schreef op woensdag 29 december 2004 @ 16:55:
Is dit niet het hele doel van de kernel? Of begrijp ik je punt verkeerd?
Je copieert platte data. Ik wil pointers en XML node trees kunnen doorgeven. Ik wil tw-way traffic hebben tussen applicaties (ik wil dat grep datapointers van cat krijgt in plaats van dat 'ie de data copieert [wat een van de redenen is dat cat $file | grep $term erg dom is), ik wil dat head mijn log applicatie vertelt dat ik al tien regels heb en dat je de output nu kunt stoppen, ik wil dat dvdauthor mijn MPEG bestandsstructuur van de muxer krijgt (als XML nodetree) en niet opnieuw parst (tijd!), ik wil dat soort dingen.Wat is er mis aan pipes? Ik vindt dit overzichtelijker en duidelijker dan de manier waarop MS Windows dit oplost. Zoals het kunnen catten van je /dev/mouse; dat is toch handig? Wat is er hopeloos aan het 'alles is een bestand' principe?
Pipes zijn bijzonder beperkt.
Dat komt omdat het niet mogelijk is. Nu men HAL heeft, klaagt men steen en been dat het er niet eerder was. Als je eenmaal UTF-8 op systeem-niveau hebt gezien, wil je nooit meer anders. ACLs, eenmaal ingeburgerd, zullen net zo onmisbaar zijn.Maar wel zo overzichtelijk; en ik ben nog nooit een situatie tegengekomen waarbij de huidige permissiestructuur niet voldeed?
3 groepen maken. een groep management, een groep accountancy en een groep management en accountancy.kenneth schreef op woensdag 29 december 2004 @ 17:00:
[...]
Management en Accountancy mogen xyzzy lezen, andere groepen niet, maar er zijn ook bestanden die alleen Management mag lezen, en bestanden die alleen Accountancy mag lezen.
Wordt al aardig lastig met alleen ugo-permissies.
inderdaad... kijk maar naar NTFS.Dat komt omdat het niet mogelijk is. Nu men HAL heeft, klaagt men steen en been dat het er niet eerder was. Als je eenmaal UTF-8 op systeem-niveau hebt gezien, wil je nooit meer anders. ACLs, eenmaal ingeburgerd, zullen net zo onmisbaar zijn.
[ Voor 25% gewijzigd door JackBol op 29-12-2004 19:00 ]
Opbrengst van mijn Tibber Homevolt met externe kWh meter. | Opbrengst van mijn Tibber Homevolt volgens de Tibber Data API.
Zoiets noem ik een workaround, geen ultieme oplossing.Dirk-Jan schreef op woensdag 29 december 2004 @ 18:55:
[...]
3 groepen maken. een groep management, een groep accountancy en een groep management en accountancy.
Verwijderd
Op mijn stagebedrijf hebben we in het UNIX-hok (en nog wat andere plekken) http://www.unixguide.net/cgi-bin/unixguide.cgi aan de muur hangen. Da's een mooie opsomming van nog niet eens alle inconsistenties
ik vind het ook geen oplossing, maar het kan wel zo... ik ben zelf altijd erg pro NTFS geweest...Bergen schreef op woensdag 29 december 2004 @ 18:58:
[...]
Zoiets noem ik een workaround, geen ultieme oplossing.
Opbrengst van mijn Tibber Homevolt met externe kWh meter. | Opbrengst van mijn Tibber Homevolt volgens de Tibber Data API.
Verwijderd
Hoezo? Je hebt die tools ter beschikking, niets meer. Als die derde groep (waar ze beiden in zitten) een beschrijvende naam krijgt, is er niets mis met die oplossing imo. Bijvoorbeeld als de bestanden waar ze beiden aan mogen komen met friet te maken hebben, noem je de groep iets met friet (beetje lastig vergelijken zoBergen schreef op woensdag 29 december 2004 @ 18:58:
[...]
Zoiets noem ik een workaround, geen ultieme oplossing.
In huis-, tuin- en keukenomgevingen zal dat wel niet zo'n vaart lopen, maar bij een wat grotere organisatie krijg je daar geheid problemen mee.
[ Voor 42% gewijzigd door Bergen op 29-12-2004 19:17 ]
Dat RTF met de hand te kloppen valt, wil niet zeggen dat een tekstverwerker niet nodig is
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
http://research.microsoft.com/~daniel/unix-haters.html
Het grote: DAB+ digitale radio topic / IPv6 topic / OpenWRT topic
Mijn tweede ervaring met unix is Solaris 9 (met core install)...ik heb het vervloekt!
Wat is er mis met UNIX: Dependecy hell !!!
(oplossing btw:pkgsrc: The NetBSD Packages Collection, werkt ook op Solaris)