LNX Kroeg - Deel 2

[himlims_]

dat schrijf ik, icm open-source mesa drivers draait dat op de server, 100% cpu

[Thedr]

himlims_ schreef op maandag 17 november 2014 @ 16:09:
dat schrijf ik, icm open-source mesa drivers draait dat op de server, 100% cpu belasting

fixed that for ya

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 15:38 ]

[mcDavid]

Is het niet gewoon dat je daarom kunt vragen als je een toffe nieuwe startpost geklust hebt?

[CAPSLOCK2000]

Het is van voor mijn tijd maar ik heb me laten vertellen dat de forumsoftware vroeger langzaam werd bij hele grote topics. Zo rond de 100 pagina's begonnen mensen te veel te klagen en werd er een nieuw topic gestart. Tegenwoordig zijn de servers sneller en de algoritmes slimmer en is er geen technische reden meer om nieuwe topics te beginnen. Maar de hele IT-wereld hangt van de cargo cult aan elkaar, zeker de Unix wereld, dus blijft het populair om nieuwe topics aan te maken. Het is natuurlijk ook wel stoer als je in "het grote ietstopic, deel 254" mag postene. De beste reden om nu nog nieuwe topics te starten is om de zoekfunctie een beetje te helpen. Megalange topics bevatten vroeg of laat ieder woord uit het woordenboek. Dan heb je ook niks meer aan het woordenboek.
Een erg gedateerde startpost kan ook een goede reden zijn, dus bonuspunten voor mcDavid.

Nu we de 100 naderen is het geen slecht moment om weer eens opnieuw te beginnen. Voelt iemand zich geroepen om een mooie startpost te cheffen?

[Frozen]

Ik zou wel willen maar heb gister voor de 2e keer kennis gemaakt met linux. Heb het gelijk op een usb 3.0 stick gezet om te kijken hoe mobiel het was. En verdomd, het ging eerst dus updaten en tijdens dat het dat aan het doen was waren de filmpjes op youtube flink aan het haperen, maar gimp startte binnen een vrij normale tijd op. Bovendien werkte het na het updaten vrijwel vloeiend.

[Hero of Time]

deadlock2k schreef op dinsdag 18 november 2014 @ 16:11:
Hoe wordt hier eigenlijk bepaald of een topic vol genoeg is? De vorige editie van de NOS kroeg had 41 pagina's, deze iets meer. #durvtevragen #krijgdeteringmetjehekjesdeadlock

Mwah, je bent altijd vrij om er een te maken, maar er is geen echte noodzaak. We hebben nu 'pas' ~3200 replies, dat is bij de default ppp 33 pagina's. Ik heb 'm op 50ppp staan en zit op 65.

Bij andere 'grote' topics wordt een nieuw deel gestart als 't een bepaalde tijd oud is, of als er tegen de 10k aan posts zijn. Omdat we niet aan een tijdspan doen en we nog ver van de 10k posts zitten, is er geen directe noodzaak.

[mcDavid]

CAPSLOCK2000 schreef op woensdag 19 november 2014 @ 01:45:

Een erg gedateerde startpost kan ook een goede reden zijn, dus bonuspunten voor mcDavid.

kan ik een vliegvakantie uitzoeken?

[Hero of Time]

Sorry, maar ze vliegen niet naar Antartica om de pinguïns te bezoeken.

[Dirk]

Niet?

[Hero of Time]

Niet vanaf Eindhoven of Schiphol . Alleen indirect (overstap). En daar doen we niet aan.

[gekkie]

Hero of Time schreef op woensdag 19 november 2014 @ 09:17:
[...]
Mwah, je bent altijd vrij om er een te maken, maar er is geen echte noodzaak. We hebben nu 'pas' ~3200 replies, dat is bij de default ppp 33 pagina's. Ik heb 'm op 50ppp staan en zit op 65.

Bij andere 'grote' topics wordt een nieuw deel gestart als 't een bepaalde tijd oud is, of als er tegen de 10k aan posts zijn. Omdat we niet aan een tijdspan doen en we nog ver van de 10k posts zitten, is er geen directe noodzaak.

Doe een goede leuke flamewar en je bent er zo

[ Voor 6% gewijzigd door gekkie op 19-11-2014 16:59 ]

[deadlock2k]

-

[ Voor 99% gewijzigd door deadlock2k op 06-08-2021 15:38 ]

[Hero of Time]

gekkie schreef op woensdag 19 november 2014 @ 16:58:
[...]

Doe een goede leuke flamewar en je bent er zo

Ik ben de laatste persoon die dat zou moeten beginnen en elk ander persoon die dat doet, zien we hier dan voorlopig niet meer.

[himlims_]

Frozen schreef op woensdag 19 november 2014 @ 02:01:
Ik zou wel willen maar heb gister voor de 2e keer kennis gemaakt met linux. Bovendien werkte het na het updaten vrijwel vloeiend.

tof systeem he, die hippy software

deadlock2k schreef op woensdag 19 november 2014 @ 18:34:
Ben jij trouwens degene die bij ons iSCSI moet komen inrichten?

denk dat Wim dat komt doen. Hebben hier nu 24TB aan SSD in gebruik genomen, VM vliegen! allemaal blauwe ledjes, ik vind mooi

[strandbal]

WTF! Ik gebruik een oud HP Compaq 6710b laptopje icm Ubuntu 14.10 (eerst 14.04) om een beetje te browsen op de bank. Werkt op zich prima.

Ik dacht eerst dat de brightness controls van het display niet werkten, maar het blijkt als je de laptop eerst een keer na het booten suspend, dan werkt het prima

Dit met diverse kernels, en 14.04 en 14.10... Echt heel wazig

[CAPSLOCK2000]

Dat is nieuw. We hebben eerst jarenlang problemen gehad met dingen die stuk gingen na een suspend. De laatste jaren lijkt het echter meestal wel te werken. Nu zijn we dus blijkbaar in het stadium dat je computer beter gaat werken van een suspend.

[mace]

mja. brakke firmware die rare dingen doet als je geen windows gebruikt is helaas een fact of life voor linux laptopgebruikers.

[Hero of Time]

Over suspend gesproken, mijn computer wil soms niet naar suspend, die gaat er dan maar half in en komt er niet meer uit. Normaal gesproken gaat de power led ook uit van de computer, maar als-ie niet wil, blijft die branden en blijven ook de fans draaien. Heb nog niet kunnen achterhalen waar het door komt, mogelijk dat m'n 500 GB schijf in de weg zit, maar dat heb ik nog niet kunnen bevestigen. Ik moet dan een harde power cycle geven om 'm weer te kunnen gebruiken. Best vervelend.

[mcDavid]

Mijn laptop gaat keurig in suspend en komt er ook keurig weer uit, maar daarna werken de input devices (keyboard, muis) niet meer. Niet dat ik 'm ooit suspend, ding start in 5 seconden op ofzo sinds ik er een SSD in heb gezet.

[himlims_]

mace schreef op dinsdag 25 november 2014 @ 22:09:
mja. brakke firmware die rare dingen doet als je geen windows gebruikt is helaas een fact of life voor linux laptopgebruikers.

sterk afhankelijk van device, hanteer een dell xps12, alles werkt! touchscreen, multitouch, brightness, volume etc. suspenden geen idee; laat ding gewoon altijd aan staan

[Ultraman]

Bij mij moet alles gewoon werken wat ik nodig heb (dus o.a. brightness en suspend). Mocht dat niet het geval zijn dan pruts ik net zo lang tot ik een oplossing heb.
Op mijn Sony werkte eigenlijk alles direct, behalve de brightness keys. Maar dat kwam omdat de input van die brightness keys naar de verkeerde driver ging. In het begin opgelost met een scriptje welke direct de juiste brightness waarde in de PCI registers stuurde. Brightnesskeys ingesteld dat dat scriptje een schop moest krijgen na een druk op de knop.
Later ontdekt dat ik X kon opdragen via welk device de input voor de Backlight feature moest lopen.
Dat was natuurlijk de echte manier om het te doen en een vele elegantere oplossing
Sindsdien werkt dus echt alles zoals het moet

[u_nix_we_all]

strandbal schreef op dinsdag 25 november 2014 @ 19:55:
WTF! Ik gebruik een oud HP Compaq 6710b laptopje icm Ubuntu 14.10 (eerst 14.04) om een beetje te browsen op de bank. Werkt op zich prima.

Ik dacht eerst dat de brightness controls van het display niet werkten, maar het blijkt als je de laptop eerst een keer na het booten suspend, dan werkt het prima

Dit met diverse kernels, en 14.04 en 14.10... Echt heel wazig

Er is een boot-setting die misschien helpt, mijn huidige HP laptop moet "acpi_backlight=vendor" op de bootregel erbij hebben. Van mijn vorige laptop (ook een HP 6710b) kan ik mij dat niet herinneren, maar daar draaide ik ubuntu 12.04 op, en dat werkte in 1 keer goed.

[Compizfox]

Ik draai Sabayon op mijn W540, en bij mij werkt Bumblebee (voor Nvidia Optimus) niet meer na S3. Na reboot doet ie het wel weer.

Maar ik denk dat ik er maar Manjaro op ga zetten.

[gekkie]

Yippie .. systemD(isaster) op debian SID heeft m'n test VM omzeep weten te helpen .. fijn.

Hrmm argh .. nou doet tie het spontaan weer .. na 10x te blijven hangen bij de mount van rootfs .. *zucht* ..
goed dan gelijk nu maar eens kijken hoe de terug keer en het vastpinnen van sysvinit werkt.

Briljante hint van de debian systemd wiki:
HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!

Als dat dan zo slim is .. had dat dan voor me gedaan .. grmbl

[ Voor 81% gewijzigd door gekkie op 26-11-2014 21:38 ]

[Compizfox]

Ben je dan nu pas over op SystemD, op sid? Ik draai zelf testing en ben nu al bijna een half jaar over op SystemD.

[ Voor 19% gewijzigd door Compizfox op 26-11-2014 22:03 ]

[gekkie]

Compizfox schreef op woensdag 26 november 2014 @ 21:58:
Ben je dan nu pas over op SystemD, op sid? Ik draai zelf testing en ben nu al bijna een half jaar over op SystemD.

Nee die vm draait al een tijd sid (en daarmee systemd) .. en opzich irriteerde het al wel .. doe er ook wat kernel debugging op .. en het standaard logspammen door systemd bij gebruik van de "debug" parameter is nog steeds .. maar goed .. tot nu toe bootte het wel .. nu dus niet meer ..
al lijkt het meer een udev probleem te zijn in systemd-udevd .. ondanks al die verbose logspamming kon er geen error message van af .. hmmppffrr *frust* ..

Dus daar zal het wel inzitten .. alleen tsja hoe revert je die hap als je het ding niet geboot krijgt, de al oude init=/bin/sh doet helaas pindakaas ook niks .. dus zal wel prutsen met een rescue disk worden.

Hmm duidelijk udev is kapoet .. zonder udev boot het weer .. ah wel ..pluggen we eth0 wel even zelf for the time being ..

[ Voor 25% gewijzigd door gekkie op 26-11-2014 23:42 ]

[Hero of Time]

Als je van systemd af wilt (ik zit met Sid al bijna een jaar op systemd btw), installeer je sysvinit-core en bijbehorende packages. Je gaat conflicten krijgen met systemd, maar in aptitude kan je die prima oplossen. Je kan dus nog gewoon terug als je wilt.

Overigens, als je naar de echt minimale recovery shell wilt zoals init=/bin/sh, moet je 'rd.break' gebruiken in je kernel parameter. Dat is de 'nieuwe' emergency shell met systemd.

---

Ik ga denk vrijdag of dit weekend maar kwin installeren op m'n HTPC. Heb vandaag Compiz 2x achter elkaar moeten killen toen ik wisselde van Kodi naar m'n browser. Eerste keer was niet genoeg, het ging gelijk weer op z'n bek.
Hoewel, eigenlijk heb ik die effecten niet eens nodig op m'n HTPC, ik doe daar niets fancy, alleen maar alt+tab. Dump er wel gewoon Xfwm4 op, draai al Xfce tenslotte. PC is een ander verhaal, maar die doet nog niet zo vaag.

Over Kodi gesproken, zette vanavond m'n HTPC weer aan (resume uit suspend) en 't scherm van Kodi kwam doodleuk op het andere scherm dan waar 't stond. Normaal gesproken komt 't netjes op m'n TV terecht, maar die had ik nog uit staan (receiver ook). Dit heb ik al eens eerder gehad, heel vaag waarom 't opeens besluit om op 't kleine scherm in de behuizing te gaan hangen. Die is in X ingesteld als aparte instance, muis kan wel er naartoe, maar vensters niet (display :0.1 ipv :0.0).

[himlims_]

compiz en Xfwm4 ... don't mix well, probeer een andere DM en systeem zal waarschijnlijk niet crashen met dezelfde actie althans, zo is mijn beleving. Xfwm4 en compiz zijn ook wel tegenstrijdig; ene wil minimaal, strak en geen poespas, compiz=poespas

//edit; hebben jullie dat ook, wanneer je nood gedwongen op een windows bak werkt dat je denk "man, wat een flut systeem" je ziet/weet niets van wat er gebeurd op de achtergrond

[ Voor 26% gewijzigd door himlims_ op 27-11-2014 10:35 ]

[Hero of Time]

Hehe, ik heb xfwm4 niet geïnstalleerd staan, daar heb ik Compiz nu voor. Op m'n HTPC gaat Compiz er dan dus vanaf en xfwm4 erop. Om het nog leuker te maken heb ik toen ik Compiz installeerde een symlink gemaakt in /usr/bin van xfwm4 naar compiz, zodat ik niets extra's hoef te doen om 't te laten starten met m'n sessie (standaard wordt xfwm4 gestart, anders niets).

Het systeem crasht ook niet, alleen Compiz gaat op z'n bek en vreet 100% CPU. Het is niet zozeer een fout van Compiz zelf, maar meer alle wijzigingen die aan het systeem en bijbehorende packages/dependencies door de tijd heen. Er is geen nieuwe build gemaakt tegen nieuwe versies, de code is niet aangepast, etc. Dat is gewoon een ongunstige combinatie dat zich nu zo uit. Op m'n laptop van werk heb ik er geen enkel probleem mee. De driver heeft er ook wel wat mee te maken denk ik, want de laptop heeft een Intel videokaart, m'n PC en HTPC hebben nVidia met de gesloten driver. Die zou ik ook nog kunnen veranderen, van nvidia naar nouveau. Voor recente videokaarten zou VDPAU (hardware decoding) moeten werken met nouveau, dus dat is iets om te bekijken.

Sowieso wil ik uiteindelijk van de nVidia driver af. Op de PC zou dat iets makkelijker kunnen omdat ik niet altijd hier video mee kijk, maar een potje Unreal Tournament 2004 moet niet in de weg komen te zitten hiervoor. In het kerstreces maar eens naar kijken.


Voor wat betreft even op Windows zitten, ja, dat gevoel ken ik wel. Nou is het niet direct het gevoel van 'wat draait er nog meer', maar meer dat ik bepaalde handigheden heb in Linux om dingen gedaan te krijgen en dat werkt op Windows net even anders. Zo ben ik om die reden van baan verandert, ik zat constant te schelden op m'n systeem, terwijl ik de boel moest blijven beheren. Dat gaat je dan aardig tegen zitten als 't even snel wat fixen op een server niet zo makkelijk gaat.

[himlims_]

schaamteloze xpost:

himlims_ schreef op donderdag 27 november 2014 @ 12:38:
met oog op as kerstperiode (vele zijn wat daagjes vrij)

misschien potje knallen/gamen met de mensen uit /23 ?

[deadlock2k]

-

[ Voor 97% gewijzigd door deadlock2k op 06-08-2021 15:37 ]

[Steef]

Kijk, nog meer tafelwaren (fork):
http://www.theregister.co...th_debian_getting_forked/

De verwoording in de announce mail doet wel enigszins dramatisch aan:
https://lists.dyne.org/lu...7.212941.f55acc3a.en.html

Voor de extra, recente Debconf QA met Linus betreffende SystemD:
https://www.youtube.com/watch?v=5PmHRSeA2c8#t=1118

Kortom, het was weer prima popcorn eten afgelopen weekend

[Vicarious]

Wat een dramaqueens die gasten van Devuan Dat je het niet eens bent met de gekozen richting van Debian is prima en dat je daarom een fork wilt maken is ook prima, maar e.e.a. wordt verwoord alsof systemd de bron van alle kwaad is en rechtlijnig tegen alle ideeën van vrije software ingaat. Dat lijkt me niet het geval.

[ Voor 76% gewijzigd door Vicarious op 01-12-2014 15:20 ]

[afraca]

Een beetje te laat om nog aan deel te nemen helaas, maar misschien leuk om terug te lezen, Greg Kroah-Hartman doet een AMA op Reddit .

[-ko-]

Jup, hij heeft nog een vraag van me beantwoord. Vergeten hier te melden. (Stelde de vraag via Twitter app vanaf mijn telefoon)

[strandbal]

u_nix_we_all schreef op woensdag 26 november 2014 @ 13:45:
[...]

Er is een boot-setting die misschien helpt, mijn huidige HP laptop moet "acpi_backlight=vendor" op de bootregel erbij hebben. Van mijn vorige laptop (ook een HP 6710b) kan ik mij dat niet herinneren, maar daar draaide ik ubuntu 12.04 op, en dat werkte in 1 keer goed.

Zo maf dit, allerlei kernel parameters geprobeerd, xorg.conf.d configuratiebestanden, maar niets lijkt te werken. Ik moet na een cold boot eerst even suspenden, anders blijft mijn scherm op 100% backlight draaien

Ubuntu wiki's bestaan over backlight controls die stoppen met werken na suspend, niet andersom

[himlims_]

strandbal schreef op vrijdag 12 december 2014 @ 08:27:
[...]Ubuntu wiki's bestaan over backlight controls die stoppen met werken na suspend, niet andersom

dat had ik met me dell ook; 0 beeld / volledig zwart; bleek de backlight bij booten naar 0% gezet te worden.
en maar kloten, en log files lezen etc. toen andere smaak linux geproeerd, sabayon gentoo gedraaid, werkte direct zonder problemen (ook multi-touch ) sindsdien gebruik ik prive geen ubuntu meer

[ Voor 4% gewijzigd door himlims_ op 12-12-2014 09:02 ]

[Katsunami]

Systemd... Ik heb er nog geen ervaring mee, maar de rellen zijn niet van de lucht. Er begint me een patroon op te vallen hier.

Software: Avahi. Ontwerper: Lennart Poettering. Resultaat: Rellen.
Software: PulseAudio. Ontwerper: Lennart Poettering. Resultaat: Rellen.
Software: Systemd. Ontwerper: Lennart Poettering. Resultaat: Rellen en haat.
Voorstel: Integreer Systemd en Gnome met elkaar. Voorstel door: Lennart Poettering. Resultaat: Rellen, haat, en bedreigingen.
Voorstel: Laat alle compatibiliteit met niet-Linux OS-en vallen. Voorstel door: Lennart Poettering. Resultaat: Verscheidene doodsbedreigingen.

En, alles wat hij ontwerpt bij / voor Red Hat wordt uiteindelijk de standaard, vanwege de macht van Red Hat, ondanks dat zijn software met verve gehaat wordt.

Volgens mij is die gast de meest gehate figuur in de wereld van vrije software.

[Boudewijn]

Mwa Theo de Raadt maakt ook nog wel goede kans?

[K93]

Hey, ik ben zelf al sinds begin 2013 bezig met Linux en vind het toch wel heel erg gaaf! Dus wilde even melden dat ik dit topic voortaan een beetje in de gaten ga houden. Heb een deel van de last tab gelezen hier. En heb ook gemerkt dat mijn notebook (Asus X75VC met Arch Linux) pas een wi-fi verbinding heeft nadat ik een suspend heb gedaan.

persoonlijk draai ik Linux alleen als hobby, ben niet specifiek voor of tegen een bepaald operating system. Ik gebruik zowel Mac OS X, Arch Linux en Windows. Dus ben een tevreden mens.

Even kort vraagje: mogen hier desktop pictures geshared worden? want ben wel trots hoe het er bij mij nu uitziet. Voor een voorstelling:
- Arch Linux
- Kernel 3.17.6
- Cinnamon DE 2.4.5 (Vertex Dark theme)
- Vertex-Dark GTK themes.
- Faience Icon Theme.
- Random wallpaper die ik gevonden heb die er wel tof uitzag..

[Dirk]

het topic is al een tijdje stil, maar: Post hier je Non-Windows screenshots - Deel 6

[RoestVrijStaal]

Katsunami schreef op zaterdag 13 december 2014 @ 23:52:
Systemd... Ik heb er nog geen ervaring mee, maar de rellen zijn niet van de lucht. Er begint me een patroon op te vallen hier.

Software: Avahi. Ontwerper: Lennart Poettering. Resultaat: Rellen.
Software: PulseAudio. Ontwerper: Lennart Poettering. Resultaat: Rellen.
Software: Systemd. Ontwerper: Lennart Poettering. Resultaat: Rellen en haat.
Voorstel: Integreer Systemd en Gnome met elkaar. Voorstel door: Lennart Poettering. Resultaat: Rellen, haat, en bedreigingen.
Voorstel: Laat alle compatibiliteit met niet-Linux OS-en vallen. Voorstel door: Lennart Poettering. Resultaat: Verscheidene doodsbedreigingen.

En, alles wat hij ontwerpt bij / voor Red Hat wordt uiteindelijk de standaard, vanwege de macht van Red Hat, ondanks dat zijn software met verve gehaat wordt.

Volgens mij is die gast de meest gehate figuur in de wereld van vrije software.

Daarom zet ik ook telkens vraagtekens of ik weer aan linux moet beginnen als primairy os.

Door al dat gerel -ongeacht door wie of welke belangen- ontstaan er meer forks en dergelijke waardoor er steeds minder out-of-the-box gaat worden en meer handmatige configuratie vereist is om pakketen met elkaar samen te laten werken.

Ik gebruikte Sabayon totdat ik een update kreeg en heel mijn op smaak gebrachte thema-met-Compiz kapot werd gemaakt door GNOME 3.

Toen maakte ik mijn pc Windows-only. Ik had er genoeg van om telkens in de configs te duiken om het werkend systeem te krijgen en houden.

Desniettemin benut ik de kracht van bash op Windows via MSYS. Hoef ik te minste een paar minimale aanpassingen in m'n shell scripts te doen als ik ooit opnieuw naar een linux-distro verhuis.

Van de andere kant vraag ik mezelf als coder af in hoeverre GPL en FSF echt "vrij" is en of je nog onderdeel uit wil maken van dat geheel.

[ Voor 3% gewijzigd door RoestVrijStaal op 14-12-2014 16:06 ]

[gekkie]

RoestVrijStaal schreef op zondag 14 december 2014 @ 16:04:
[...]

Daarom zet ik ook telkens vraagtekens of ik weer aan linux moet beginnen als primairy os.

Door al dat gerel -ongeacht door wie of welke belangen- ontstaan er meer forks en dergelijke waardoor er steeds minder out-of-the-box gaat worden en meer handmatige configuratie vereist is om pakketen met elkaar samen te laten werken.

Ik gebruikte Sabayon totdat ik een update kreeg en heel mijn op smaak gebrachte thema-met-Compiz kapot werd gemaakt door GNOME 3.

Toen maakte ik mijn pc Windows-only. Ik had er genoeg van om telkens in de configs te duiken om het werkend systeem te krijgen en houden.

Desniettemin benut ik de kracht van bash op Windows via MSYS. Hoef ik te minste een paar minimale aanpassingen in m'n shell scripts te doen als ik ooit opnieuw naar een linux-distro verhuis.

Van de andere kant vraag ik mezelf als coder af in hoeverre GPL en FSF echt "vrij" is en of je nog onderdeel uit wil maken van dat geheel.

Mjah had de hoop dat Debian het nog even aan zou kijken (ze waren meestal niet de snelste met adoptie van nieuwigheden) .. laat systemd zich eerst maar bewijzen .. (en geef een alternatief de kans zich te ontwikkelen)

en als zelfs Poettering zelf al zegt dat de adoptie veel sneller gaat dan hij verwachte .. voorlopig ploppen er nog genoeg bugs op ..

Maar goed het heeft niet zo mogen zijn .. en inmiddels is ook duidelijk dat je bij een upgrade standaard over gezet gaat worden naar systemd. Ben benieuwd of ze Jessie op tijd kunnen en willen releasen en hoe de adoptie snelheid daarvan gaat zijn. Qua servers kijk ik de kat wel uit de boom, ik wil geen verrassingen met niet willen booten.

[ Voor 4% gewijzigd door gekkie op 14-12-2014 17:02 ]

[CAPSLOCK2000]

RoestVrijStaal schreef op zondag 14 december 2014 @ 16:04:
Door al dat gerel -ongeacht door wie of welke belangen- ontstaan er meer forks en dergelijke waardoor er steeds minder out-of-the-box gaat worden en meer handmatige configuratie vereist is om pakketen met elkaar samen te laten werken.

Voor mijn gevoel is dat niet waar en zijn de verschillen tussen de distributies kleiner geworden dan pakweg 10 jaar geleden. Zelfs over systemd is er razendsnel overeenstemming gevonden. Lang niet iedereen vindt het leuk, maar alle grote distro's gebruiken inmiddels systemd.

Van de andere kant vraag ik mezelf als coder af in hoeverre GPL en FSF echt "vrij" is en of je nog onderdeel uit wil maken van dat geheel.

Dat is een filosofische discussie die groter is dan alleen software. "Vrij" is geen absolute toestand maar juist heel erg relatief. De klassieker is dat jouw vrijheid om met je vuist te zwaaien ophoudt waar mijn neus begint.

Het kan verhelderend zijn om te beseffen dat het GPL niet op programmeurs is gericht maar op gebruikers. Als programmeur is BSD fijner, dan mag je alles gebruiken en niemand kan iets van jouw verlangen (op naamsvermelding na). Als gebruiker is GPL echter in mijn voordeel. Als gebruiker weet ik dat ik van GPL software de sources kan krijgen en mag hergebruiken. Aangezien ik veel meer software gebruik dan ik zelf ooit zal schrijven heb ik graag GPL.

gekkie schreef op zondag 14 december 2014 @ 17:01:
Maar goed het heeft niet zo mogen zijn .. en inmiddels is ook duidelijk dat je bij een upgrade standaard over gezet gaat worden naar systemd.

Volgens mij is dat van de baan. Voor zover ik weet is er nooit besloten om mensen te dwingen om naar systemd over te gaan maar kwam het "toevallig" zo uit door dependencies. Dat is aangepast:
https://lists.debian.org/...nce/2014/11/msg00010.html

Volgens mij is het nu zo dat als je upgrade je bij je oude init-systeem blijft tenzij je zelf kiest om te veranderen. Tot op zekere hoogte want als je Gnome wilt gebruiken dan moet je wel overstappen op systemd.

Ben benieuwd of ze Jessie op tijd kunnen en willen releasen en hoe de adoptie snelheid daarvan gaat zijn. Qua servers kijk ik de kat wel uit de boom, ik wil geen verrassingen met niet willen booten.

Ik heb eigenlijk geen bezwaren tegen systemd als init-systeem. Ik geloof dat systemd werkelijk een hoop vooruitgang biedt tenopzichte van sys-v. Niet dat ik er nooit problemen mee heb gehad maar ook sys-v heb ik systemen gehad die niet meer wilde booten door bugs in de init-scripts. Dusver heb ik alle problemen weten op te lossen, het hoort er natuurlijk een beetje bij als je SID draait. Ik vind dat de declaratieve aanpak van systemd fundamenteel beter is dan de "zoek het zelf maar uit" aanpak van sys-v.

Ik heb wel bezwaren tegen de manier waarop systemd het hele basissysteem overneemt. De naam zegt het eigenlijk al, het is niet "initd" maar "systemd". Dat gaat wat mij betreft veel te hard. Door de grote verwevenheid is het moeilijk om het gradueel in te voeren. Het is al snel alles of niets. Dat staat me niet aan. De systemd mensen hebben een hoop goede ideeen maar om die uit te voeren herschrijven ze maar even alles. Hierdoor worden bergen uitontwikkelde code weggegooid en vervangen door verse code met verse bugs.

[Katsunami]

RoestVrijStaal schreef op zondag 14 december 2014 @ 16:04:
Daarom zet ik ook telkens vraagtekens of ik weer aan linux moet beginnen als primairy os.

Ik heb het een paar keer geprobeerd, maar er valt voor mij niet aan te beginnen, al was het maar omdat ik zo nu en dan nog wel eens foto's wil schieten. Hoewel RawTherapee en GIMP op Windows wel voeldoen (net, krap), maak ik tegenwoordig ook gebruik van een hardwarematig gekalibreerde Eizo-monitor.

Vroeger heb ik een paar keer geprobeerd om mijn Eizo Flexscan softwarematig te kalibreren in Linux, en hoewel het mogelijk was, was het elke keer gigantisch ***. Mijn huidige ColorEdge hoef ik niet eens te proberen; daar heb je ColorNavigator voor nodig, en de officiële bijgeleverde drivers. Dat werkt niet, ook niet in WINE.

Ik ben niet van plan om mijn gekalibreerde monitor op te geven, nadat ik 10 jaar lang naar perfecte / correcte kleuren heb gekeken.

Dan heb ik het nog niet eens over Windows-software die ik zou moeten vervangen; op het moment zijn dat niet veel programma's, maar degene die ik gebruik hebben onder Linux simpelweg geen gelijkwaardig alternatief, zoals Foobar, CueTools, CueRipper, en Blu-Ray Rebuilder. (Toevallig allemaal ripping software.)

Door al dat gerel -ongeacht door wie of welke belangen- ontstaan er meer forks en dergelijke waardoor er steeds minder out-of-the-box gaat worden en meer handmatige configuratie vereist is om pakketen met elkaar samen te laten werken.

Ik gebruikte Sabayon totdat ik een update kreeg en heel mijn op smaak gebrachte thema-met-Compiz kapot werd gemaakt door GNOME 3.

Toen maakte ik mijn pc Windows-only. Ik had er genoeg van om telkens in de configs te duiken om het werkend systeem te krijgen en houden.

Ik heb hetzelfde. Hetgeen ik vervelend vind is dat het zeer lastig is om een bepaald programma op een bepaalde versie te houden, als je dat om wat voor reden dan ook wilt. Op een gegeven moment krijg je gewoon altijd conflicten.

Desniettemin benut ik de kracht van bash op Windows via MSYS. Hoef ik te minste een paar minimale aanpassingen in m'n shell scripts te doen als ik ooit opnieuw naar een linux-distro verhuis.

Ik gebruik hiervoor al ruim 10 jaar jaar Cygwin. De Linux/Unix command line is het onderdeel van het OS waar ik wel danig verliefd op ben.

Hetgeen waar ik Linux voor gebruik (ook op mijn werk, op het moment) is om een systeem bovenop te bouwen. Ik start dan met een zo ver mogelijk gestripte versie van Debian Stable, met een eigen gecompileerde kernel. Daarop komt dan (indien het system output vereist) een zo klein mogelijke versie van X.org, LXDE met alles uitgeschakeld, en Chromium in Kiosk mode, met een webapp erin (meestal bovenop nginx, of Apache, indien nodig) die laat zien wat het systeem aan het doen is. Vaak schrijf ik kleine shell-scripts of, indien nodig, command-line tools in C, die dan via de webapp worden aangestuurd.

[Katsunami]

CAPSLOCK2000 schreef op zondag 14 december 2014 @ 18:13:
Ik heb wel bezwaren tegen de manier waarop systemd het hele basissysteem overneemt. De naam zegt het eigenlijk al, het is niet "initd" maar "systemd". Dat gaat wat mij betreft veel te hard. Door de grote verwevenheid is het moeilijk om het gradueel in te voeren. Het is al snel alles of niets. Dat staat me niet aan. De systemd mensen hebben een hoop goede ideeen maar om die uit te voeren herschrijven ze maar even alles. Hierdoor worden bergen uitontwikkelde code weggegooid en vervangen door verse code met verse bugs.

Een tijdje terug heb ik gelezen dat systemd zijn gehele configuratie en logging binair doet. Is dat (nog steeds) zo? Dat helpt het hele principe van /etc (*editable* text configuration) over de zeik. Soms maak ik tijdens de ontwikkeling van embedded software ook wel eens (configuratie)fouten. Dan start het hele systeem niet meer. Nu kan ik gewoon de schijf / SD / SSD uit dat systeem nemen, in een computer hangen, booten met een live distro, backup file terugzetten, en gaan met die banaaan. Dat kon vroeger met DOS / Windows ook, met Windows 7 is dat een heel stuk lastiger.

Ik zou het heel erg lastig vinden als ik toeren moet gaan uithalen om een defect systemd weer aan het booten te krijgen in de toekomst.

[Compizfox]

Ik heb eigenlijk geen bezwaren tegen systemd als init-systeem. Ik geloof dat systemd werkelijk een hoop vooruitgang biedt tenopzichte van sys-v. Niet dat ik er nooit problemen mee heb gehad maar ook sys-v heb ik systemen gehad die niet meer wilde booten door bugs in de init-scripts. Dusver heb ik alle problemen weten op te lossen, het hoort er natuurlijk een beetje bij als je SID draait. Ik vind dat de declaratieve aanpak van systemd fundamenteel beter is dan de "zoek het zelf maar uit" aanpak van sys-v.

Ik heb wel bezwaren tegen de manier waarop systemd het hele basissysteem overneemt. De naam zegt het eigenlijk al, het is niet "initd" maar "systemd". Dat gaat wat mij betreft veel te hard. Door de grote verwevenheid is het moeilijk om het gradueel in te voeren. Het is al snel alles of niets. Dat staat me niet aan. De systemd mensen hebben een hoop goede ideeen maar om die uit te voeren herschrijven ze maar even alles. Hierdoor worden bergen uitontwikkelde code weggegooid en vervangen door verse code met verse bugs.

Kijk, dat is zo ongeveer hoe ik er ook over denk.

Ik draai zelf al geruime tijd systemd op mijn server (die Debian testing draait) en ik heb er totaal geen problemen mee op een paar programma's na die niet geheel op tijd waren met het systemd-proof maken van hun initfiles.

De initfiles zijn een stuk korter en zitten logischer in elkaar dan de sysv-init-files. Bij sysv-init kon je alles in je initfiles zetten wat je maar wilde; het enige wat een beetje structuur aanbracht waren de LSB-headers. Het systeem van systemd vind ik veel beter omdat het veel gestructureerder is.

Ik zie het punt van de tegenstanders ook wel (datgene wat jij in je tweede alinea uitlegt) maar weet niet zo goed wat ik daar nou over moet denken. Met andere woorden: ik weet niet zo goed of het wel zo'n groot probleem is als de tegenstanders ervan maken.

Wat ik wel zeker weet is dat al het gedoe eromheen grotendeels uit de hand gelopen is. Als ik het me goed herinner is er zelfs een gerespecteerde developer bij Debian weggelopen naar aanleiding van de vele bedreigingen die hij kreeg omtrent systemd. Dat is toch te gek voor woorden?

[Raynman]

Katsunami schreef op zondag 14 december 2014 @ 19:28:
[...]


Een tijdje terug heb ik gelezen dat systemd zijn gehele configuratie en logging binair doet. Is dat (nog steeds) zo?

Configuratie gaat gewoon met tekstbestanden. De ingebouwde logging (journal) is wel binair, maar je kunt het ook laten forwarden naar syslog.

[gekkie]

CAPSLOCK2000 schreef op zondag 14 december 2014 @ 18:13:
Het kan verhelderend zijn om te beseffen dat het GPL niet op programmeurs is gericht maar op gebruikers. Als programmeur is BSD fijner, dan mag je alles gebruiken en niemand kan iets van jouw verlangen (op naamsvermelding na). Als gebruiker is GPL echter in mijn voordeel. Als gebruiker weet ik dat ik van GPL software de sources kan krijgen en mag hergebruiken. Aangezien ik veel meer software gebruik dan ik zelf ooit zal schrijven heb ik graag GPL.

heuh .. bij BSD krijg je ook de sources en mag je die hergebruiken .. het enige wat je wellicht niet krijgt zijn de wijzigingen van bepaalde gebruikers. (het is dus van invloed op zowel de ontwikkelaar die wijzigingen terug krijgt als de gebruiker lijkt me)

Volgens mij is dat van de baan. Voor zover ik weet is er nooit besloten om mensen te dwingen om naar systemd over te gaan maar kwam het "toevallig" zo uit door dependencies. Dat is aangepast:
https://lists.debian.org/...nce/2014/11/msg00010.html

Hmm ik zag de recentere ctte beslissing in https://lists.debian.org/debian-ctte/2014/12/msg00021.html

Volgens mij is het nu zo dat als je upgrade je bij je oude init-systeem blijft tenzij je zelf kiest om te veranderen. Tot op zekere hoogte want als je Gnome wilt gebruiken dan moet je wel overstappen op systemd.

Gezien de bovenstaande ctte beslissing verwacht ik dus van niet .. en moet je van te voren sysvinit-core installeren en eventueel met pinnen zorgen dat systemd ook weg blijft als je dat wil.

Ik heb eigenlijk geen bezwaren tegen systemd als init-systeem. Ik geloof dat systemd werkelijk een hoop vooruitgang biedt tenopzichte van sys-v. Niet dat ik er nooit problemen mee heb gehad maar ook sys-v heb ik systemen gehad die niet meer wilde booten door bugs in de init-scripts. Dusver heb ik alle problemen weten op te lossen, het hoort er natuurlijk een beetje bij als je SID draait. Ik vind dat de declaratieve aanpak van systemd fundamenteel beter is dan de "zoek het zelf maar uit" aanpak van sys-v.

Zal deels m'n nog onbekendheid met systemd zijn, maar tot nu toe heb ik het gevoel dat een in de soep gelopen boot met sysvinit een stuk makkelijker te herstellen is. (omdat je met simpele basic tools kunt werken desnoods van een rescue disc .. of ergens wat echo's erin kan plakken op een willekeurig punt .. dat is toch wat anders dan een of andere binary moeten gaan debuggen tijdens een bootproces).
En sneller is het ook niet altijd ... heb onder Jessie vaak nog wat vage journal flush meuk die een half jaar duurt.
Maar dat init scripts ook vaak een janboel kunnen zijn ben ik wel met je eens, aan de andere kant wordt de api van systemd dat waarschijnlijk ook .. omdat ze er steeds meer in moeten knutselen om alle dingen die met shell-scripts mogelijk zijn er ook in te bakken (en dan schiet het ook z'n doel weer voorbij).

Ik heb wel bezwaren tegen de manier waarop systemd het hele basissysteem overneemt. De naam zegt het eigenlijk al, het is niet "initd" maar "systemd". Dat gaat wat mij betreft veel te hard. Door de grote verwevenheid is het moeilijk om het gradueel in te voeren. Het is al snel alles of niets. Dat staat me niet aan. De systemd mensen hebben een hoop goede ideeen maar om die uit te voeren herschrijven ze maar even alles. Hierdoor worden bergen uitontwikkelde code weggegooid en vervangen door verse code met verse bugs.

Ik sta er opzich hetzelfde in .. ben opzich niet tegen een ander init systeem .. alleen de wijze waarop en de principes die systemd ontwikkelaars lijken te hanteren die staan me beduidend minder aan. Ik vrees dat we daar in de toekomst nog veel plezier aan gaan beleven.
Feest zal al wel beginnen met als kdbus in de kernel wordt opgenomen en er een al aangekondigde harde knip in de ondersteuning van kernels door systemd zal komen.
Daarbij komt dat ze relatief veel dingen kunnen maken .. ze geven zelf al aan dat het een groot voordeel is dat alles in dezelfde repository zit, alleen vergeten voor het gemak dat dat ook betekend dat je al gauw over abi/api stabiliteit issues heen stapt. Iets wat ze zelf ook al wel kenbaar maken met de wens tot lockstep updaten. Het draait bij systemd om systemd .. systemd is het basis blok voor het os.

Kunnen ze bij Debian nog zo hard roepen dat het een do'ocracy is .. en dat je mensen geen werk mag opleggen, ik vrees gezien de snelle ontwikkelingen dat het backporten van bugfixes een aardig zware taak gaat worden. Zeker na zo'n harde knip, waarbij Jessie op een versie voor de knip zit, en alle andere distrubties straks op versies er na.

Wat mij betreft was het dus qua project status nog niet geschikt voor Debian (en zeker niet zo relatief kort voor een freeze) waarbij alle mogelijkheden tot het verzachten door bijvb installatie van sysvinit nu buiten boord worden gehouden met als argument "ja we zitten in een freeze, dikke pech".

Had systemd graag gezien als expiriment waarin de mogelijkheden zijn geexploreerd, waarna er daarna gewoon een beheerste implementatie in losse tools was ontstaan. Opzich hadden Debian, deriviates, gentoo, slackware en de BSD's ook wel een deuk in een pakje boter kunnen slaan voor een alternatief, maar helaas.

Maar goed .. wordt maar voorzichtig upgraden deze keer.

Hmmzz waarom zijn al die self hosted git dingen (gitorious, gitlab) in ruby

[Blokker_1999]

heuh .. bij BSD krijg je ook de sources en mag je die hergebruiken

Het gaat in deze context over de BSD licentie, en niet de verschillende BSD distributies. Van software de welke uitgebracht is onder een BSD licentie hoeft de developer de sources niet beschikbaar te stellen.

[K93]

Ik vind systemd wel prettig werken op mijn Arch systeem Maar heb maar weinig met sysvinit gewerkt. Toen ik begon met Arch Linux was het net overgegaan of bijna in ieder geval, waardoor ik het oude systeem niet veel van heb meegekregen.

[gekkie]

Blokker_1999 schreef op zondag 14 december 2014 @ 22:43:
[...]
Het gaat in deze context over de BSD licentie, en niet de verschillende BSD distributies. Van software de welke uitgebracht is onder een BSD licentie hoeft de developer de sources niet beschikbaar te stellen.

Het originele project heeft toch de BSD licentie en is toch opensource, alleen kunnen afgeleide werken closed source zijn en een andere licentie waardoor je de gewijzigde source dus niet hebt ?
Dus voor het originele werk is er voor de gebruiker niet echt een verschil tussen GPL en BSD licentie ?
(behalve via de weg van de developer van het originele werk die wellicht minder bugfixes/features terug krijgt en daarmee dus een verminderde progressie in het project wat dan weer terugkoppelt op de gebruiker)

[CAPSLOCK2000]

gekkie schreef op zondag 14 december 2014 @ 20:42:
heuh .. bij BSD krijg je ook de sources en mag je die hergebruiken .. het enige wat je wellicht niet krijgt zijn de wijzigingen van bepaalde gebruikers. (het is dus van invloed op zowel de ontwikkelaar die wijzigingen terug krijgt als de gebruiker lijkt me)

Nee, dat hoeft niet. Je kan prima je software onder de BSD-licentie uitbrengen zonder ooit je sources te publiceren. Dat is niet zo voor de hand liggend, maar het kan. Een waarschijnlijker scenario is dat iemand een stuk BSD-software pakt, daar wat mooie verbetering op aanbrengt en de nieuwe software als closed-source uitbrengt. Zo zijn er nog een paar scenario's denkbaar. Als gebruiker ben je met GPL-software beschermd.
Als particulier klinkt dat allemaal wat overdreven maar sommige bedrijven zijn bang dat ze iets moois maken waar de concurrentie dan mee van door gaat. GPL geeft daar wat extra zekerheid.

Hmm ik zag de recentere ctte beslissing in https://lists.debian.org/debian-ctte/2014/12/msg00021.html

Is dat al een beslissing of nog een voorstel tot discussie? Op grond van de link die ik poste dacht ik juist dat ze probeerde om upgrades niet te forceren om systemd te installeren.

Zal deels m'n nog onbekendheid met systemd zijn, maar tot nu toe heb ik het gevoel dat een in de soep gelopen boot met sysvinit een stuk makkelijker te herstellen is. (omdat je met simpele basic tools kunt werken desnoods van een rescue disc .. of ergens wat echo's erin kan plakken op een willekeurig punt .. dat is toch wat anders dan een of andere binary moeten gaan debuggen tijdens een bootproces).

Ik ben er nog niet helemaal uit. Ik denk ook dat het herstellen van fouten makkelijker is met sysv maar dat de kans op het ontstaan van fouten kleiner is met systemd. Het zal nog wel een paar jaar duren voor ik genoeg ervaring heb met systemd om het zeker te weten. Zelfs als het een beetje moeilijker is vind ik dat geen echt bezwaar.

En sneller is het ook niet altijd ... heb onder Jessie vaak nog wat vage journal flush meuk die een half jaar duurt.

Sneller vind ik de minst interessante kant van systemd. Sysv is voor mij ook al snel genoeg. Misschien is het interessant voor telefoons of de embedded markt maar voor mijn servers en desktops heeft dat geen toegevoegde waarde.

Wat ik wel interessant vind is dat heel veel functionaliteit makkelijk beschikbaar komt. Veelal zijn het niet echt nieuwe dingen maar features van de Linux-kernel die op zich al lang bestaan maar nauwelijks gebruikt worden omdat ieder init-scriptje al die dingen opnieuw zou moeten implementeren. Met systemd is het een enkele variabele waarmee je een hoop kan doen. Zie bv Security Features in systemd

Maar dat init scripts ook vaak een janboel kunnen zijn ben ik wel met je eens, aan de andere kant wordt de api van systemd dat waarschijnlijk ook .. omdat ze er steeds meer in moeten knutselen om alle dingen die met shell-scripts mogelijk zijn er ook in te bakken (en dan schiet het ook z'n doel weer voorbij).

Daar ben ik ook bang voor, het is nu al een rommeltje. Overigens kun je op veel punten stukje shell gebruiken zodat niet alles voorgeprogrammeerd hoeft te zijn.

Ik sta er opzich hetzelfde in .. ben opzich niet tegen een ander init systeem .. alleen de wijze waarop en de principes die systemd ontwikkelaars lijken te hanteren die staan me beduidend minder aan. Ik vrees dat we daar in de toekomst nog veel plezier aan gaan beleven.

Feest zal al wel beginnen met als kdbus in de kernel wordt opgenomen en er een al aangekondigde harde knip in de ondersteuning van kernels door systemd zal komen.
Daarbij komt dat ze relatief veel dingen kunnen maken .. ze geven zelf al aan dat het een groot voordeel is dat alles in dezelfde repository zit, alleen vergeten voor het gemak dat dat ook betekend dat je al gauw over abi/api stabiliteit issues heen stapt. Iets wat ze zelf ook al wel kenbaar maken met de wens tot lockstep updaten. Het draait bij systemd om systemd .. systemd is het basis blok voor het os.

Ik deel je angsten. Ik zie eigenlijik ook geen weg terug meer als we ooit weer van systemd af willen.

Kunnen ze bij Debian nog zo hard roepen dat het een do'ocracy is .. en dat je mensen geen werk mag opleggen, ik vrees gezien de snelle ontwikkelingen dat het backporten van bugfixes een aardig zware taak gaat worden. Zeker na zo'n harde knip, waarbij Jessie op een versie voor de knip zit, en alle andere distrubties straks op versies er na.

Ik weet niet of er een keuze was zonder dit soort pijnlijke gevolgen. Geen systemd gebruiken als de meeste andere grote distro's dat wel doen en Gnome dat ook verwacht zou ook een hoop gedoe opleveren.

Wat mij betreft was het dus qua project status nog niet geschikt voor Debian (en zeker niet zo relatief kort voor een freeze) waarbij alle mogelijkheden tot het verzachten door bijvb installatie van sysvinit nu buiten boord worden gehouden met als argument "ja we zitten in een freeze, dikke pech".

Ik had ook liever gehad dat ze nog een release hadden gewacht, maar op zich zit systemd al ruime tijd in Debian, het is geen last-minute werk. Het vervelende is dat steeds meer software afhankelijk is geworden van systemd.

Had systemd graag gezien als expiriment waarin de mogelijkheden zijn geexploreerd, waarna er daarna gewoon een beheerste implementatie in losse tools was ontstaan. Opzich hadden Debian, deriviates, gentoo, slackware en de BSD's ook wel een deuk in een pakje boter kunnen slaan voor een alternatief, maar helaas.

Het is niet alsof het niet geprobeerd is. Upstart is bijvoorbeeld de poging van Ubuntu, maar daar gingen de handen ook niet voor op elkaar. Zelf heb ik mijn hoop gevestigd op uselessd. Dat is een project dat als reactie op systemd is begonnen en een init-systeem schreeft gebaseerd op ideeen uit systemd maar nadrukkelijk van plan is om niet meer te zijn dan een init.

[gekkie]

CAPSLOCK2000 schreef op maandag 15 december 2014 @ 00:47:
Nee, dat hoeft niet. Je kan prima je software onder de BSD-licentie uitbrengen zonder ooit je sources te publiceren. Dat is niet zo voor de hand liggend, maar het kan. Een waarschijnlijker scenario is dat iemand een stuk BSD-software pakt, daar wat mooie verbetering op aanbrengt en de nieuwe software als closed-source uitbrengt. Zo zijn er nog een paar scenario's denkbaar. Als gebruiker ben je met GPL-software beschermd.
Als particulier klinkt dat allemaal wat overdreven maar sommige bedrijven zijn bang dat ze iets moois maken waar de concurrentie dan mee van door gaat. GPL geeft daar wat extra zekerheid.

Aan de ene kant wel .. aan de andere kant kan het ook weer gedoe opleveren .. bij een BSD licentie is de kans op eventueel juridisch gedoe wel lager.
Maar geen idee hoe die verhoudingen en afwegingen liggen bij contributors van projecten onder een BSD license.

Is dat al een beslissing of nog een voorstel tot discussie? Op grond van de link die ik poste dacht ik juist dat ze probeerde om upgrades niet te forceren om systemd te installeren.

Ik heb er geloof ik nog geen vote over gezien .. dus ik denk dat de status nu een ctte proposal is .. waarover ze wellicht de volgende keer wel zullen stemmen (maar als ik het ctte-irc-log las dan zal dat wel aangenomen worden). Wellicht in de hoop om uit de support spagaat te komen door zoveel mogelijk upgrades naar systemd te krijgen.
Ik verbaas me er echt hogelijk over dat alles waarbij een gebruiker gewoon makkelijk zelf de keuze wordt voorgelegd wordt afgefakkeld (niet in het minst door voorstanders van sytemd op kritieke plekken). Een DE mag je wel kiezen .. een init systeem moet je voor een nieuwe install preseeden en voor een upgrade gaan pinnen.
Als gebruikers het het beste vinden sinds gesneden brood .. dan zouden ze vanzelf toch ook wel overstappen ?

Ik ben er nog niet helemaal uit. Ik denk ook dat het herstellen van fouten makkelijker is met sysv maar dat de kans op het ontstaan van fouten kleiner is met systemd. Het zal nog wel een paar jaar duren voor ik genoeg ervaring heb met systemd om het zeker te weten. Zelfs als het een beetje moeilijker is vind ik dat geen echt bezwaar.

Klopt .. achja het advies op de Debian systemd wiki is toch wel briljant:
HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!
Ze vervangen na genoeg elke systemutil terwijl het niet nodig is .. maar als het het niet meer doet .. moet je maar uit gaan huilen met sysvinit. Toch wel een klein zwakte bod mijnsinziens, maak dan een /sbin/systemdisaster ... die gewoon minimaal is en gewoon altijd boot

Sneller vind ik de minst interessante kant van systemd. Sysv is voor mij ook al snel genoeg. Misschien is het interessant voor telefoons of de embedded markt maar voor mijn servers en desktops heeft dat geen toegevoegde waarde.

Ik ook niet .. maar goed een van de argumenten waarmee het zo ongeveer begon .. maar ik zie er nog steeds dus niet altijd wat van terug

Wat ik wel interessant vind is dat heel veel functionaliteit makkelijk beschikbaar komt. Veelal zijn het niet echt nieuwe dingen maar features van de Linux-kernel die op zich al lang bestaan maar nauwelijks gebruikt worden omdat ieder init-scriptje al die dingen opnieuw zou moeten implementeren. Met systemd is het een enkele variabele waarmee je een hoop kan doen. Zie bv Security Features in systemd

Dat een hoop kernel features nauwelijks gebruikt worden is wel waar ja .. en opzich was misschien een "schok" als systemd ook wel nodig om er vooruitgang in te krijgen (ipv vastlopend overleg tussen allelei betrokken losse subprojecten).

Daar ben ik ook bang voor, het is nu al een rommeltje. Overigens kun je op veel punten stukje shell gebruiken zodat niet alles voorgeprogrammeerd hoeft te zijn.

Ja .. maar uiteindelijk krijg je 100000 hooks in je binary waar je dan een stukje script aan kunt gaan hangen .. waar weer allemaal environment en parameters heen en weer geschoven moeten worden .. en als je niet op past ... heb je sysvinit terug
Wat dat betreft is het wel vaker met projecten .. die starten dan heel verfrissend en licht .. maar uiteindelijk als alles van de voorganger dan eindelijk geimplementeerd is .. + bergen quirks en is het opeens ook niet zo verfrissend en licht meer.

Ik deel je angsten. Ik zie eigenlijik ook geen weg terug meer als we ooit weer van systemd af willen.

Tsja maarja het mocht van vele geen criterium zijn .. geen politiek .. alleen technische zaken .. (en mogelijke rampen met technische gevolgen in de toekomst vallen in deze onder politiek). En opzich zit er ook wel wat in dat je niet alles moet tegenhouden omdat het in de toekomst slecht kan uitpakken.

Het belangrijkste wat systemd heeft veroorzaakt is een enorm momentum aan ontwikkeluren.
Voor een alternatief zal dat lastig worden .. aan de andere kant .. als het echt in de soep loopt dan heb je wel een mooi onderzoek waar dan inmiddels alle pro's en con's van bepaalde oplossingen duidelijk zijn, zodat een alternatief makkelijker geimplementeerd kan worden.

Maar opzich was het voorstel tijdens de GR van Ian ook zo onredelijk nog niet. Zoveel moeite zou het voor de gemiddelde package maintainer niet moeten zijn om bijvb in iedergeval sysvinit compatabiliteit te behouden. Het zou in iedergeval een weg terug makkelijker bereikbaar houden.

Ik weet niet of er een keuze was zonder dit soort pijnlijke gevolgen. Geen systemd gebruiken als de meeste andere grote distro's dat wel doen en Gnome dat ook verwacht zou ook een hoop gedoe opleveren.

De keuze voor een andere default had voor Jessie nog uitgesteld kunnen worden volgens mij, vervolgens zou je dan vroegtijdig bekend kunnen maken dat systemd voor de volgende release wel default gaat worden en daar aan werken. Ondertussen draaien de earlyadopters het al wel op Jessie .. zorgt voor mooi voor bugfixes van mensen die het willen draaien .. ipv van mensen die het moeten draaien.

Het dwingt upstream ook om zich gedurende de tijd tot een nieuwe release zich te gedragen .. zo niet had je de beslissing nog kunnen terugdraaien .. en in iedergeval dingen als kdbus af kunnen wachten.

Ik had ook liever gehad dat ze nog een release hadden gewacht, maar op zich zit systemd al ruime tijd in Debian, het is geen last-minute werk. Het vervelende is dat steeds meer software afhankelijk is geworden van systemd.

Dat ben ik dan weer niet met je eens, de beslissing was te laat zodat alle ellende van depedencies en upgrade en installer problematiek die nu naar boven is gekomen niet netjes opgelost wordt .. want ja .. we hebben een freeze.
Opzich vooral Gnome3 toch, zou zo nog geen andere dingen weten die expliciet systemd wilden vereisen (waarbij je dan nu deels omheen kunt werken met systemd-shim) ?

Het is niet alsof het niet geprobeerd is. Upstart is bijvoorbeeld de poging van Ubuntu, maar daar gingen de handen ook niet voor op elkaar. Zelf heb ik mijn hoop gevestigd op uselessd. Dat is een project dat als reactie op systemd is begonnen en een init-systeem schreeft gebaseerd op ideeen uit systemd maar nadrukkelijk van plan is om meer te zijn dan een init.

Volgens mij mist er ergens een keer het kritieke woordje "niet"
Het zou opzich mooi zijn als eudev en uselessd wat tractie zouden krijgen ja, maar ik het het gevoel dat iedereen op het moment een beetje lamgeslagen is door de systemd storm. Ergens jammer dat de BSD's meer op openrc zitten, daar zit opzich ook nog wel wat ontwikkelingspotentieel als die wat op hun heupen krijgen (zie libressl)

[CAPSLOCK2000]

gekkie schreef op maandag 15 december 2014 @ 01:56:
Klopt .. achja het advies op de Debian systemd wiki is toch wel briljant:
HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!
Ze vervangen na genoeg elke systemutil terwijl het niet nodig is .. maar als het het niet meer doet .. moet je maar uit gaan huilen met sysvinit. Toch wel een klein zwakte bod mijnsinziens, maak dan een /sbin/systemdisaster ... die gewoon minimaal is en gewoon altijd boot

Ik hoop dat ze dat nog wat netter oplossen.

Dat een hoop kernel features nauwelijks gebruikt worden is wel waar ja .. en opzich was misschien een "schok" als systemd ook wel nodig om er vooruitgang in te krijgen (ipv vastlopend overleg tussen allelei betrokken losse subprojecten).

Ik dacht meer aan features als namespaces. Ieder programma z'n eigen filesystem-namespace geven waarin filesystems waar je niet hoeft te schrijven read-only of zelfs niet gemount zijn is een leuk idee, maar (bijna) niemand doet het omdat iedereen die een init-script schrijft het weer opnieuw moet doen. Onder systemd regel je dat met een enkele setting.

Ja .. maar uiteindelijk krijg je 100000 hooks in je binary waar je dan een stukje script aan kunt gaan hangen .. waar weer allemaal environment en parameters heen en weer geschoven moeten worden .. en als je niet op past ... heb je sysvinit terug

Het zou kunnen, maar ik maak me er niet zo heel erg veel zorgen over. De meeste software is toch vrij simpel. Die kan enorm profiteren van versimpeling door systemd. Als het echt nodig is om enorm veel te scripten kun je altijd nog een traditioneel init scriptje gebruiken door systemd 'start' en 'stop' laten aanroepen.

Ik zie wat dat betreft meer gevaar in dat ze veel meer doen dan alleen init. Dan heb ik het niet over cron of at, ik vind het redelijk dat init die taken overneemt, dat gaat allemaal over het starten van processen. Dat initd ook het netwerk wil configureren en z'n eigen dhcp en pppoe schrijft vind ik weer te ver gaan.

Maar opzich was het voorstel tijdens de GR van Ian ook zo onredelijk nog niet. Zoveel moeite zou het voor de gemiddelde package maintainer niet moeten zijn om bijvb in iedergeval sysvinit compatabiliteit te behouden. Het zou in iedergeval een weg terug makkelijker bereikbaar houden.

Dat had ik graag gezien. Van de andere kant, vrijwel al die software heeft al een sysvinit script, die verdwijnen niet zomaar. Ik verwacht dat voor jessie vrijwel alles nog compatible blijft met sysv.

De keuze voor een andere default had voor Jessie nog uitgesteld kunnen worden volgens mij, vervolgens zou je dan vroegtijdig bekend kunnen maken dat systemd voor de volgende release wel default gaat worden en daar aan werken. Ondertussen draaien de earlyadopters het al wel op Jessie .. zorgt voor mooi voor bugfixes van mensen die het willen draaien .. ipv van mensen die het moeten draaien.

systemd zit ook al in wheezy, de echte early-adapters draaien het al jaren dus ik maak me hier niet zo'n zorgen over.

Het dwingt upstream ook om zich gedurende de tijd tot een nieuwe release zich te gedragen .. zo niet had je de beslissing nog kunnen terugdraaien .. en in iedergeval dingen als kdbus af kunnen wachten.

Ik geloof niet dat het veel verschil zou maken. Wanneer heeft Poetering zich nou ooit ergens iets van aangetrokken?

Volgens mij mist er ergens een keer het kritieke woordje "niet"

oeps , bedankt voor het opmerken. Opgelost!

[gekkie]

CAPSLOCK2000 schreef op maandag 15 december 2014 @ 05:13:
Ik dacht meer aan features als namespaces. Ieder programma z'n eigen filesystem-namespace geven waarin filesystems waar je niet hoeft te schrijven read-only of zelfs niet gemount zijn is een leuk idee, maar (bijna) niemand doet het omdat iedereen die een init-script schrijft het weer opnieuw moet doen. Onder systemd regel je dat met een enkele setting.

Dat klinkt idd niet verkeerd, zeker niet voor iets wat ook nog over een netwerk communiceert.

Ik zie wat dat betreft meer gevaar in dat ze veel meer doen dan alleen init. Dan heb ik het niet over cron of at, ik vind het redelijk dat init die taken overneemt, dat gaat allemaal over het starten van processen. Dat initd ook het netwerk wil configureren en z'n eigen dhcp en pppoe schrijft vind ik weer te ver gaan.

Altijd moeilijk om de grens te trekken .. niet is zwart wit .. en ja .. sinds alles tegenwoordig aan een netwerk hangt en daemons daar ook afhankelijk van zijn ... is netwerk net zo belangrijk of misschien nog wel belangrijker als cron. Maarja .. fsck moet je soms toch ook tijdens het booten en liefst zo vroeg mogelijk ... hmm waarom bestaat grub nog ... en .. en .. ik zie nog wel uitbreindingsmogelijkheden.

Maar opzich wordt het redelijk gecommuniceerd, hoe ze willen werken, waar ze naar toe willen, ze zich bijna elke vrijheid permitteren.
Daarbij strookt het geheel met de visie van Poettering en anderen (ook deels Torvalds als ik z'n Q&A op debconf zo beluisterde) voor zover ik die heb meegekregen en juist interpreteer.
Systemd als het building block voor het os ... kernel erbij ... en applicaties het liefst gestandaardiseerd in een container (gelijk vanaf de maker), kortom wat er over blijft voor een distributie is een set met linkjes naar containers van programma's.
En opzich zit er ook wel wat in .. het packagen voor zoveel subplatformen/distributies is natuurlijk ook een berg waarvan je opzich het hogere nut zou kunnen betwijfelen .. maar goed of het ooit zover zal komen en of het er beter op gaat worden ..

Dat had ik graag gezien. Van de andere kant, vrijwel al die software heeft al een sysvinit script, die verdwijnen niet zomaar. Ik verwacht dat voor jessie vrijwel alles nog compatible blijft met sysv.

Ik denk het ook wel .. wellicht bij een aantal packages van echte systemd adepten niet .. maar goed dat zal dan alsnog wel zoveel trammelant opleveren dat het wel goed zal komen.

Ik geloof niet dat het veel verschil zou maken. Wanneer heeft Poetering zich nou ooit ergens iets van aangetrokken?

Dan zou dat hopelijk nog een paar keer goed duidelijk geworden zijn "before the point of no return"

oeps , bedankt voor het opmerken. Opgelost!

Euj geschiedvervalsing

[Katsunami]

Nou, wat betreft die standardisatie mag er eens wat werk verzet worden. Ik heb die Q&A op DebConf ook gezien, en een paar quotes van Torvalds waren:

"Binary creation for Linux is a hell."
"We have binaries for Windows, we have binaries for OSX.... we don't... have binaries for Linux."
"Debian Stable is so old that nothing built in the last century will run on it."

Een tijdje terug heb ik op Mobileread een discussie gehad met Kovid Goyal (maker van Calibre), en die is het met mij eens: alle software in één repository, waarin alles van alles afhankelijk is, werkt niet. De software kan wel een in repository zitten, maar dan moet dat zo gebeuren dat het programma volledig onafhankelijk van het besturingssysteem is.

Het wordt tijd dat Linux standardiseert naar één base-OS, waar alle distributies zich aan dienen te houden; een beetje zoals dat in elkaar zit voor FreeBSD. Dan moeten programma's en drivers worden gecompileerd, en op zo'n manier worden verpakt dat het hele programma zelfstandig is; vergelijkbaar met de PBI van DesktopBSD. Deze pakketten kunnen dan in een repo worden gestopt. Als het programma wordt geïnstalleerd, hoeft het slechts uitgepakt te worden naar /programs/prog_name (eventueel met een symlink naar de binary in /bin oid), en zijn configuratie in /etc/prog_name. Als het programma zo verpakt wordt dat het al zijn dependencies meelevert, en niet hardwired vastzit aan bepaalde kernel-features en drivers, dan kan het eigenlijk bijna oneindig blijven lopen. Het lukt MS toch ook om een heleboel 32-bit programma's uit de Windows 95 tijd te draaien op 64-bit Windows 7 en 8.x, zonder aanpassingen van het programma zelf? Dat moet onder Linux net zo goed gaan. Nu moet je altijd wachten totdat iemand zo lief is om de laatste versie van een programma opnieuw te packagen zodat het compatible is met de libraries en de kernel die op dat moment in de distributie worden geleverd.

[ Voor 3% gewijzigd door Katsunami op 15-12-2014 12:37 ]

[Hero of Time]

Dat idee van alle dependencies in het package zelf levert ook zo z'n problemen op. Denk aan bugs in een library zoals OpenSSL. Als je 10 programma's hebt die OpenSSL gebruikt, moet je er 10 updaten. Zouden ze OpenSSL aanroepen, hoef je maar 1 bij te werken om 10 bugs te pletten. En zo heb je meer punten die juist door de manier hoe Linux nu in elkaar zit veel prettiger is.

Eigenlijk is hetgeen wat je nu beschrijft als zijnde 'zoals DesktopBSD het doet' vergelijkbaar met OSX. Daar knal je ook alles in /Applications 'en het werkt'. Ik geloof niet dat dat principe erin gaat komen. Ik zou het iig niet fijn vinden.

[Compizfox]

CAPSLOCK2000 schreef op maandag 15 december 2014 @ 00:47:
[...]

Nee, dat hoeft niet. Je kan prima je software onder de BSD-licentie uitbrengen zonder ooit je sources te publiceren. Dat is niet zo voor de hand liggend, maar het kan. Een waarschijnlijker scenario is dat iemand een stuk BSD-software pakt, daar wat mooie verbetering op aanbrengt en de nieuwe software als closed-source uitbrengt. Zo zijn er nog een paar scenario's denkbaar. Als gebruiker ben je met GPL-software beschermd.
Als particulier klinkt dat allemaal wat overdreven maar sommige bedrijven zijn bang dat ze iets moois maken waar de concurrentie dan mee van door gaat. GPL geeft daar wat extra zekerheid.

Wat je zegt klopt helemaal, maar ik begrijp niet hoe je dit ziet als een bescherming voor de gebruiker. Maakt het de gebruiker iets uit of een bepaald bedrijf bepaalde software forkt en het dan closed-source uitbrengt?

Voor zover ik het begrijp, is die clausule in de GPL er vooral voor bedoeld om vrije software altijd vrij te houden. Dus dat de inzet die ontwikkelaars in de vrije software hebben gestopt niet 'misbruikt' wordt door grote 'evil' bedrijven.

---

Het wordt tijd dat Linux standardiseert naar één base-OS, waar alle distributies zich aan dienen te houden; een beetje zoals dat in elkaar zit voor FreeBSD.

Is dat niet zo'n beetje juist het grootste verschil tussen FreeBSD en GNU/Linux? Met andere woorden: als jij dat graag zo hebt, kun je dan beter niet gewoon FreeBSD gaan gebruiken?

Dan moeten programma's en drivers worden gecompileerd, en op zo'n manier worden verpakt dat het hele programma zelfstandig is; vergelijkbaar met de PBI van DesktopBSD. Deze pakketten kunnen dan in een repo worden gestopt. Als het programma wordt geïnstalleerd, hoeft het slechts uitgepakt te worden naar /programs/prog_name (eventueel met een symlink naar de binary in /bin oid), en zijn configuratie in /etc/prog_name. Als het programma zo verpakt wordt dat het al zijn dependencies meelevert, en niet hardwired vastzit aan bepaalde kernel-features en drivers, dan kan het eigenlijk bijna oneindig blijven lopen. Het lukt MS toch ook om een heleboel 32-bit programma's uit de Windows 95 tijd te draaien op 64-bit Windows 7 en 8.x, zonder aanpassingen van het programma zelf? Dat moet onder Linux net zo goed gaan. Nu moet je altijd wachten totdat iemand zo lief is om de laatste versie van een programma opnieuw te packagen zodat het compatible is met de libraries en de kernel die op dat moment in de distributie worden geleverd.

Dus je bedoelt eigenlijk gewoon dat software statisch gelinkt moet worden, zoals ook onder Windows gebruikelijk is?

Dat is natuurlijk wel mogelijk, maar vergeet niet dat dat erg inefficiënt is. Nu kun je 20 programma's hebben die allemaal dezelfde library nodig hebben (laten we zeggen iets universeels zoals libssl). Als je dat statisch wilt compileren moet elk van die 20 programma's voor een eigen kopie van libssl zorgen.

Als je dan libssl wilt updaten (vanwege een één of ander securityprobleem of zo ) moet je al die 20 programma's updaten. Aan de andere kant, als je het dynamisch linkt kun je gewoon libssl updaten en de 20 programma's hetzelfde laten (zolang je de ABI van libssl maar hetzelfde houdt)

Dus, volgens mij is de manier waarop GNU/Linux nu in elkaar zit juist het sterke punt. Ja, het is met zijn vele distributies niet erg 'centraal' maar dat is juist een voordeel omdat dat betekent dat je erg veel keuze hebt. Zoals ik (en Hero of Time) hierboven net hebben uitgelegd heeft dynamisch linken juist een hoop voordelen.
Als je dat niet aanstaat kun je denk ik beter naar iets anders zoeken, want ik denk niet dat dat ooit zal gaan veranderen aan GNU/Linux. Ze zijn misschien niet zo bekend, maar er zijn behalve GNU/Linux nog een hoop andere POSIX-achtige OS'sen die dit soort dingen wél anders doen (zoals FreeBSD bijvoorbeeld)

@Hero of Time: Damn, net te laat Ik gebruik toevallig ook nog hetzelfde voorbeeld als jij

[ Voor 9% gewijzigd door Compizfox op 15-12-2014 13:10 ]

[Hero of Time]

Great minds...

[Katsunami]

Hero of Time schreef op maandag 15 december 2014 @ 13:03:
Dat idee van alle dependencies in het package zelf levert ook zo z'n problemen op. Denk aan bugs in een library zoals OpenSSL. Als je 10 programma's hebt die OpenSSL gebruikt, moet je er 10 updaten. Zouden ze OpenSSL aanroepen, hoef je maar 1 bij te werken om 10 bugs te pletten. En zo heb je meer punten die juist door de manier hoe Linux nu in elkaar zit veel prettiger is.

Eigenlijk is hetgeen wat je nu beschrijft als zijnde 'zoals DesktopBSD het doet' vergelijkbaar met OSX. Daar knal je ook alles in /Applications 'en het werkt'. Ik geloof niet dat dat principe erin gaat komen. Ik zou het iig niet fijn vinden.

Tja, elk voordeel heeft zijn nadeel natuurlijk. In mijn beschrijving is het wel zo dat elk programma kan blijven werken op (bijna) elke versie van Linux, omdat het volledig los staat. Het is echter inderaad ook zo dat je voor een onderdeel dat nu gedeeld is, dan meerdere updates uitgevoerd moeten worden. Uiteraard nemen de dubbele libraries ook meer schijfruimte in beslag.

Persoonlijk zou ik het updaten van meerdere programma's geen probleem vinden, zeker niet als deze als één compleet package via een repository binnengehaald kunnen worden. Het extra gebruik aan schijfruimte en/of geheugen interesseert me eerlijk gezegd nog veel minder.

Hetgeen zoals het nu is, zorgt ervoor dat je (in elk geval onder Debian) een programma moet pinnen, als je dat om de een of andere reden niet wilt bijwerken, maar op een gegeven moment ga je daar conflicten mee krijgen, omdat versies van bibliotheken uit elkaar gaan lopen. (Je gepinde programma moet X hebben, alle anderen moeten X+1 hebben, en dan moet je rare toeren gaan uithalen.)

Compizfox schreef op maandag 15 december 2014 @ 13:04:
Is dat niet zo'n beetje juist het grootste verschil tussen FreeBSD en GNU/Linux? Met andere woorden: als jij dat graag zo hebt, kun je dan beter niet gewoon FreeBSD gaan gebruiken?

Dat is wat ik het liefste zou doen, maar dat OS ondersteunt veel minder hardware dan Linux. Als ik de mogelijkheid heb, zou ik FreeBSD gebruiken, maar vaak kan dat niet. Op dit moment ben ik bijvoorbeeld bezig met een systeem dat wordt aangestuurd door een embedded computer (één per onderdeel), en sommige onderdelen hebben hardware die alleen onder Linux werkt (er zijn geen drivers voor FreeBSD). Dan is het onhandig om sommige delen op FreeBSD te laten draaien en anderen op Linux; dan kan ik beter Debian Stable met een custom kernel gebruiken, voor alle systemen.

[ Voor 19% gewijzigd door Katsunami op 15-12-2014 14:39 ]

[gekkie]

Hero of Time schreef op maandag 15 december 2014 @ 13:03:
Dat idee van alle dependencies in het package zelf levert ook zo z'n problemen op. Denk aan bugs in een library zoals OpenSSL. Als je 10 programma's hebt die OpenSSL gebruikt, moet je er 10 updaten. Zouden ze OpenSSL aanroepen, hoef je maar 1 bij te werken om 10 bugs te pletten. En zo heb je meer punten die juist door de manier hoe Linux nu in elkaar zit veel prettiger is.

Eigenlijk is hetgeen wat je nu beschrijft als zijnde 'zoals DesktopBSD het doet' vergelijkbaar met OSX. Daar knal je ook alles in /Applications 'en het werkt'. Ik geloof niet dat dat principe erin gaat komen. Ik zou het iig niet fijn vinden.

There is no such thing as a free lunch
Zoals je al aangeeft verschuif je eigenlijk de problemen vanuit het packagen naar de gebruiker/beheerder.
(wat dat betreft blijken wel meer "verbeteringen" uiteindelijk vooral "veranderingen" te zijn, de verbetering zit hem erin dat iemand er in geslaagd de last te verplaatsen en bij een ander te dumpen).

[Vicarious]

Hero of Time schreef op maandag 15 december 2014 @ 13:03:
Dat idee van alle dependencies in het package zelf levert ook zo z'n problemen op. Denk aan bugs in een library zoals OpenSSL. Als je 10 programma's hebt die OpenSSL gebruikt, moet je er 10 updaten. Zouden ze OpenSSL aanroepen, hoef je maar 1 bij te werken om 10 bugs te pletten. En zo heb je meer punten die juist door de manier hoe Linux nu in elkaar zit veel prettiger is.

Volgens mij werkt Windows net zo met al die .dll bestandjes. Daarvan kan maar 1 versie in Windows aanwezig zijn, en als verschillende programma's hetzelfde .dll bestandje nodig hebben maar dan van een andere versie heb je de bekende dll-hell. http://en.wikipedia.org/wiki/Dynamic-link_library

[Compizfox]

Dynamic linking (met .dll's dus) wordt onder Windows echter lang niet zoveel gedaan als bij Linux (met .so's)

Voor libraries die met Windows zelf meekomen is het wel gebruikelijk, maar met niet-Microsoft dingen juist niet. Ga maar eens in de Program Files kijken, daar zie je per applicatie een zooitje .dll's van bv. Qt.

Het mogen dan wel .dll's zijn en technisch gezien zijn ze ook wel dynamisch gelinkt (ze zitten niet in de executable zelf, maar daarbuiten), maar ze worden niet system-wide geshared zoals bij Linux. Bij Linux staat er per library maar één kopie centraal in /lib/ en /usr/lib waar alle applicaties gebruik van maken, terwijl bij Windows elke applicatie heeft z'n eigen kopieën van de Qt DLL's in z'n Program Files heeft.

[ Voor 12% gewijzigd door Compizfox op 15-12-2014 20:19 ]

[begintmeta]

Ik heb met linux binaeries nooit echt problemen gehad, in een geval (een bepaald statistiekprogramma) preload ik een oudere lib gewoon maar.

[CAPSLOCK2000]

Compizfox schreef op maandag 15 december 2014 @ 13:04:
Wat je zegt klopt helemaal, maar ik begrijp niet hoe je dit ziet als een bescherming voor de gebruiker. Maakt het de gebruiker iets uit of een bepaald bedrijf bepaalde software forkt en het dan closed-source uitbrengt?

Voor zover ik het begrijp, is die clausule in de GPL er vooral voor bedoeld om vrije software altijd vrij te houden. Dus dat de inzet die ontwikkelaars in de vrije software hebben gestopt niet 'misbruikt' wordt door grote 'evil' bedrijven.

Het is enerzijds software vrij houden en anderzijds zorgen dat de gebruiker er ook van kan profiteren. Tegenwoordig draaien een hoop routers op GPL-software (Linux enzo). Als gebruiker heb je dan recht op de sources. Bij BSD-software heb je niet het recht om die sources ook op te eisen. Sommige van die routerfabrikanten probeerden zich nog er af te maken met "de originele sources kun je op internet vinden", maar dat is niet goed genoeg, ze moeten ze zelf aanbieden met hun aanpassingen er bij.

Nu is van de meeste BSD-software de source ook wel te vinden, maar er is geen verplichting en de last licht bij de gebruiker. Bij GPL weet ik waar ik de source kan vinden: bij de leverancier van de binary. In die zin geeft GPL meer bescherming aan de gebruiker.

Ik zal direct toegeven dat het het hele verhaal over licenties in de meeste gevallen een nogal theoretische discussie is. De meeste mensen zijn daar absoluut niet mee bezig en weten niet eens wat source is of wat je er aan hebt. Voor de meeste toepassingen die er wel toe doen is er geen verschil tussen BSD of GPL.

Het is mijn overtuiging dat software steeds belangrijker wordt. Inzicht in en toegang tot de code die de wereld laat werken vind ik daarom erg belangrijk. Niet helemaal toevallig is bij het werk dat ik doe toegang tot de source en alles wat je nodig hebt om die aan te passen erg prettig.

[Brent]

Hero of Time schreef op maandag 15 december 2014 @ 13:03:
Dat idee van alle dependencies in het package zelf levert ook zo z'n problemen op. Denk aan bugs in een library zoals OpenSSL. Als je 10 programma's hebt die OpenSSL gebruikt, moet je er 10 updaten. Zouden ze OpenSSL aanroepen, hoef je maar 1 bij te werken om 10 bugs te pletten. En zo heb je meer punten die juist door de manier hoe Linux nu in elkaar zit veel prettiger is.

Eigenlijk is hetgeen wat je nu beschrijft als zijnde 'zoals DesktopBSD het doet' vergelijkbaar met OSX. Daar knal je ook alles in /Applications 'en het werkt'. Ik geloof niet dat dat principe erin gaat komen. Ik zou het iig niet fijn vinden.

Dit is alleen echter geen echt probleem: de packager compilet ook, en heeft dus, mits fatsoenlijke buildscripts, binnen een handomdraai alles geupdate. Kost wat meer bandbreedte, maar dat is inmiddels geen probleem meer. Net zo min dat je geheugen zou besparen door dynamic te linken: het gaat om wat megabytes, ooit een probleem, niet meer, temeer daar geheugen dedup volgens mij standaard is tegenwoordig. Bovendien is static strict genomen sneller dan dynamic, het scheelt een laagje indirectie.

Libraries zijn leuk als APIs constant gehouden zouden worden. En dat gebeurt gewoon niet.

Het is niet voor niets dat Go zo aanslaat binnen de webservice gemeenschap: er zitten enorme voordelen aan slechts een binary te hoeven kopieren en klaar.

[Boudewijn]

Mwa er zijn anders genoeg luie ontwikkelaars die niet heel snel een release doen na een CVE in hun product. Heb dan liever 1 pakket dat dingen moet fixen (openssl) dan 3000000 pakketten die het gebruiken.

offtopic:
Kijk voor de gein maar eens naar de traagheid van files voor hpux of solaris

[Brent]

Boudewijn schreef op woensdag 17 december 2014 @ 22:18:
Mwa er zijn anders genoeg luie ontwikkelaars die niet heel snel een release doen na een CVE in hun product. Heb dan liever 1 pakket dat dingen moet fixen (openssl) dan 3000000 pakketten die het gebruiken.

offtopic:
Kijk voor de gein maar eens naar de traagheid van files voor hpux of solaris

Als het uit de repo van je OS/distro komt, mag je er vanuit gaan dat alles gerecompiled wordt, niet? Dat is dan tegelijk ook het enige dat ertoe doet, want wat je buitenom installeert is sowieso op eigen risico.

Misschien moet ik het anders formuleren: als je software buiten OS repos om distribueert, moet dat een static compile zijn + source vrij beschikbaar. Anders ga ik slaan

[Hero of Time]

Er kan ook gedoeld worden op trage package maintainers. Heb met Debian al een paar keer gezien dat een package maar geen nieuwe build kreeg om een ernstig probleem op te lossen, simpelweg omdat er gewacht werd op upstream voor een nieuwe versie. De patch die het probleem verhielp, zou pas toegepast worden als upstream dus een nieuwe versie gaf. Volgens mij was dat van libopus, zo'n 2 jaar geleden. Multiarch was daardoor gewoon onbruikbaar vanwege conflicten met z'n andere arch. Heeft iets van 2 maanden ofzo geduurd voordat 't was aangepast.

En er was ook nog eens een item van de touchpad driver voor bepaalde hardware. Scrollen deed 't niet en hoewel er een patch beschikbaar was om het mogelijk te maken, was 't pas 'gefixt' toen 't upstream in de kernel zat en deze beschikbaar was.

Dus om nou te zeggen dat je distro altijd snel is, of sneller dan externe bron, nee, dat is dus niet waar. Debian heeft echter wel de naam dat ze met security fixes snel zijn. Als er dus een CVE is, kan je er met iig Sid vanuit gaan dat je binnen 36 uur na het verschijnen van de fix wel een update hebt. Testing (voornamelijk) en Stable zijn iets later. Voor Stable is 't voornamelijk afhankelijk wat de impact is van het backporten en hoe complex dat is. In Sid zou bijvoorbeeld gewoon een nieuwe versie van Apache worden gemaakt, maar Stable kan pas een week later de update krijgen vanwege de complexiteit van 't backporten en quality checks.

[Katsunami]

Hero of Time schreef op woensdag 17 december 2014 @ 22:41:
Er kan ook gedoeld worden op trage package maintainers. Heb met Debian al een paar keer gezien dat een package maar geen nieuwe build kreeg om een ernstig probleem op te lossen, simpelweg omdat er gewacht werd op upstream voor een nieuwe versie. De patch die het probleem verhielp, zou pas toegepast worden als upstream dus een nieuwe versie gaf. Volgens mij was dat van libopus, zo'n 2 jaar geleden. Multiarch was daardoor gewoon onbruikbaar vanwege conflicten met z'n andere arch. Heeft iets van 2 maanden ofzo geduurd voordat 't was aangepast.

Volgens mij heb ik over dit, of een vergelijkbaar probleem zelfs een topic geopend (of in elk geval hier ergens in het subforum gepost), want ik heb een tijd terug, toen ik weer eens probeerde full time Linux te draaien, alweer moeten opgeven. Dit was destijds een conflict met geluidshardwware c.q. software; Ik had twee pakketten nodig, en beiden hadden dezelfde library, maar niet dezelfde versie; ik kon dus niet beide pakketten tegelijk installeren.

Het grootste nadeel van Linux vind ik nog steeds dat er veel hardware is die simpelweg niet fatsoenlijk ondersteund wordt (hardwarematig gecalibreerde monitoren bijvoorbeeld), omdat fabrikanten er gewoon geen brood in zien om software voor Linux te schrijven. Ik heb nog zat andere hardware die ik onder Linux alleen met heel veel moeite aan de praat krijg, en dan moet ik inboeten op functionaliteit.

Het grootste voordeel aan Linux is de command line. Zonder Unix-type command line kan ik thuis (meestal) nog weg, maar op mijn werk heb ik die gewoon nodig. Zo ongeveer alles wat ik zou willen kan ik met één regel op de command line oplossen, terwijl het onder Windows niet eens mogelijk is (of alleen met Powershell, waar ik niks vanaf weet). Soms doe ik zelfs een exec() in PHP met een commando-regel erin, in plaats van dat ik een functie schrijf, simpelweg omdat de functie me een halve dag zou kosten om te maken en idiot-proof te testen, terwijl ik de commando-regel er in 10 minuten getest en al in heb zitten. dit ondanks dat ik weet dat de software niet meer op Windows kan draaien. (Gelukkig gaat dat in mijn huidige situatie nooit gebeuren.)

Onder Windows installeer ik dan ook standaard Cygwin.

[ Voor 3% gewijzigd door Katsunami op 17-12-2014 23:43 ]

[begintmeta]

Katsunami schreef op woensdag 17 december 2014 @ 23:41:
...
Ik had twee pakketten nodig, en beiden hadden dezelfde library, maar niet dezelfde versie; ik kon dus niet beide pakketten tegelijk installeren.
...

Hoe bedoel je dat precies?

[Boudewijn]

Waar ik vooral op doel is toko's, zoals in dit geval HP, die in 2014 shit uit 2013 eens fixen:
https://www.ncsc.nl/diens...che+Web+Server+Suite.html

Best lelijk imo. Nu is 2014 'maar' een jaar, maar je ziet nu en dan nog dingen uit 2009 of 2010 gefixed worden. Dat is in de wereld van vandaag beschamend, zeker als het om vulnerabilities gaat (een touchpad dat het niet doet is zuur, maar dat liever dan pwnd zijn).

[Hero of Time]

begintmeta schreef op donderdag 18 december 2014 @ 00:08:
[...]

Hoe bedoel je dat precies?

Dat je boekhoudprogramma bijvoorbeeld libgtk3.10 vereist (niet hoger, niet lager), maar je mail client ofzo heeft minstens libgtk3.12 nodig. Dat gaat dan niet samen.

[begintmeta]

Soms is het dan mogelijk om (in een startscript bijvoorbeeld) een andere LD_LIBRARY_PATH op te geven, de juiste lib te preloaden of, maar helaas is dat niet altijd mogelijk omdat men resolved naar een .so in plaats van een .so.x, gewoon de juiste library bij te installeren. Mocht de package-manager conflicten opleveren zit er natuurlijk niets anders op dan de package wat aan te passen. Stomme, bij handigere packaging overbodige, klusjes inderdaad.

Maar goed, dat zou dus ook niet nodig moeten zijn, helaas compileren linuxsoftwaremakers vaak specifiek voor distro's in plaats van voor (bijvoorbeeld) kernels of glibc-versies, als ze dat zouden doen zou het een hoop dergelijke problemen schelen. De oplossing is natuurlijk ook dat leveranciers van dergelijke software de software inderdaad zoveel mogelijk bij elkaar houden, dus eigen libs mee, eventueel statisch etc. Bij windows zit je uiteindelijk trouwens ook vaak met een dozijn of wat Visual C-versies met eigen installers etc...

Ik snap trouwens ook wel een beetje dat je er eventueel voor zou kiezen je op distro't te richtens, dat kan ondersteunen van gebruikers soms wel wat makkelijker maken.

[ Voor 69% gewijzigd door begintmeta op 18-12-2014 09:02 ]

[Katsunami]

begintmeta schreef op donderdag 18 december 2014 @ 00:08:
[...]

Hoe bedoel je dat precies?

Precies zoals ik dat zeg.

Als ik pakket A installeerde, dan werkte dat.
Installeerde ik Pakket B, dan zeurde deze over het feit dat een bepaalde library al op het systeem stond, maar een andere versie had dan degene die nodig was voor pakket B. Als ik de library verving door de nieuwere versie dan werkte pakket A niet meer. Verving ik de library niet, dan werkte pakket B niet.

Aangezien het hier om multimedia-programma's ging, zou libopus best wel eens de oorzaak kunnen zijn geweest.

[begintmeta]

Zoals in mijn vorige post aangegeven is het, helaas met geklooi, vaak wel mogelijk om twee versies van een lib naast elkaar in gebruik te hebben.

Het ging hier inderdaad eerder wel al eens over libopus0 laat een korte search zien: Katsunami in "NOS Kroeg - Deel 2"

[ Voor 46% gewijzigd door begintmeta op 18-12-2014 09:12 ]

[strandbal]

Zitten hier ook FreeBSD users? De laatste update voor 10.1 is wel erg broken

https://forums.freebsd.or...eebsd-update-fetch.49552/

Ik draai een x64 installatie, viel me al op dat er een enorme lading lib32 geinstalleerd werden, gevolgd door een foutmelding dat hij / niet kon verwijderen

[FRidh]

libopus in Debian was inderdaad een ramp...

Wat betreft meerdere versies tegelijk denk ik dat de Nix package manager (en NixOS) eigenlijk wel de toekomst is. Bij Nix wordt iedere versie van ieder pakket in een 'store' geplaatst. Als verschillende versies dan tegelijk nodig zijn is dat geen probleem. Met NixOS kunnen gebruikers bovendien andere versies installeren wanneer ze die nodig hebben.

[Boudewijn]

Is Nixos nu eindelijk wat geworden? Jaar of 5-6 geleden een prachtig verhaal van wat promovendi aan de UU gehoord, en eigenlijk nooit echt de indruk gehad dat het van de grond kwam.

[Ultraman]

strandbal schreef op donderdag 18 december 2014 @ 13:02:
Zitten hier ook FreeBSD users? De laatste update voor 10.1 is wel erg broken

https://forums.freebsd.or...eebsd-update-fetch.49552/

Ik draai een x64 installatie, viel me al op dat er een enorme lading lib32 geinstalleerd werden, gevolgd door een foutmelding dat hij / niet kon verwijderen

Mijn servertje zit op FreeBSD 9.3. Ben nog niet naar de 10 geupgrade, want ik zat eigenlijk een beetje te wachten op 10.1. Op zich hoef ik niet zo nodig want het machientje draait keurig en er zijn niet echt nieuwe features die ik nodig heb.
BHyve lijkt mij interessant en wil ik binnenkort een keer mee experimenteren. Dat ga ik doen op mijn testbakkie, puur om het eens te ervaren.

[FRidh]

Boudewijn schreef op donderdag 18 december 2014 @ 22:16:
Is Nixos nu eindelijk wat geworden? Jaar of 5-6 geleden een prachtig verhaal van wat promovendi aan de UU gehoord, en eigenlijk nooit echt de indruk gehad dat het van de grond kwam.

Nouja, er lijkt zeker nog wel vooruitgang in te zitten, maar er is nog steeds geen fatsoenlijke installer, en ik denk dat dat toch wel essentieel is om meer gebruikers te krijgen. Het aantal contributors lijkt wel toe te nemen.
https://www.openhub.net/p/nixos/contributors/summary

Ik vind het wel mooi dat alle pakket definities in 1 git repository zitten. Ze lijken ook wel redelijk eenvoudig te maken en bij te houden wat denk ik de drempel om bij te dragen ook zeker verlaagt.

[Compizfox]

Ik heb laatst van 10.0-RELEASE naar 10.1-RELEASE geupgradet (op twee bakken nog wel) en daarbij had ik dat probleem niet.

Of gaat dit over een minor security upgrade die ná de upgrade naar 10.1-RELEASE komt?

[strandbal]

Ja is een patch (via freebsd-update). Overigens net geprobeerd en hij wil nog steeds m'n root opruimen, dat valt me toch tegen

[d1ng]

strandbal schreef op maandag 22 december 2014 @ 12:13:
Ja is een patch (via freebsd-update). Overigens net geprobeerd en hij wil nog steeds m'n root opruimen, dat valt me toch tegen

Dat kun je negeren

[Hero of Time]

Waarom kan je het verwijderen van / negeren? Er is juist lange tijd ophef geweest over 't feit dat je op allerlei systemen doodleuk 'rm -rf /' kon doen, waardoor je alles kwijt was. Het lijkt mij nogal van belang dat je enige pogingen om / te verwijderen niet negeert, maar juist probeert te achterhalen wat het wil doen, waarom en vooral: waarom is het na bijna een week nog steeds niet opgelost.

[d1ng]

Omdat er niks zal worden verwijderd.

Zie ook deze aankondiging op de mailinglist. https://lists.freebsd.org...2014-December/001611.html

Als je deze niet wenst te negeren kun je als alternatief een source upgrade doen. Het probleem zit namelijk in de freebsd-update tool en niet in de upgrade.

[ Voor 34% gewijzigd door d1ng op 22-12-2014 16:12 ]

[u_nix_we_all]

Linux is eng !

Blijft toch apart, mensen die meteen in de "kan ik niet, weet ik niet, wil ik niet" modus springen als het woord Linux valt

[mace]

Maar ff een zetje gegeven dan.

[gekkie]

u_nix_we_all schreef op maandag 22 december 2014 @ 18:01:
Linux is eng !
Blijft toch apart, mensen die meteen in de "kan ik niet, weet ik niet, wil ik niet" modus springen als het woord Linux valt

Mwah .. ter verzachting .. als het eerste wat je er mee moet doen .. gelijk recovery van je data is .. kan ik me voorstellen dat je liever niet wil uit angst wat verkeerd te doen. Maar goed bij iets van recovery gaat hier idd gelijk de USB stick met linux tools erin .. altijd present in de protomonnee.

[Verwijderd]

m.i. Laat een tekst als "ik heb er totaal geen verstand van, en eerlijk gezegd.... dat wil ik zo houden" toch vrij duidelijk zien dat het geen kwestie van angst is, maar van onwil. Iets niet willen leren, jezelf doelbewust onwetend willen houden, daar kan ik me nou niks bij voorstellen.

[strandbal]

Ach, die angst voor verandering heb je ook onder Windows gebruikers onderling. Die hadden liever eeuwig XP gehad. Doe je niks aan.

[gekkie]

Verwijderd schreef op maandag 22 december 2014 @ 21:16:
m.i. Laat een tekst als "ik heb er totaal geen verstand van, en eerlijk gezegd.... dat wil ik zo houden" toch vrij duidelijk zien dat het geen kwestie van angst is, maar van onwil. Iets niet willen leren, jezelf doelbewust onwetend willen houden, daar kan ik me nou niks bij voorstellen.

Ach niet iedereen heeft tijd en zin om iets nieuws te leren.
En opzich is de gemiddelde linux distributie niet moeilijker dan windows (of je nou een string zoekt in een set tekst configuratie files .. of je moet je een ongelukg zoeken naar een vinkje of naar een obscure registry key).
Aan de andere kant als je het wat meer gebruikt zul je wellicht toch wel tegen wat dingen aan kunnen lopen dit wat tijd kunnen kosten om op te lossen, opzich niet erg, maar niet iedereen heeft er trek in (of kan vooraf overzien of hij er trek in heeft).

[Hero of Time]

Jep, en nu met 8 schreeuwen ze om W7, wat ze met W10 redelijk terug krijgen.

Er zijn ook genoeg Windows gebruikers die pertinent weigeren een ander OS te leren. Dat kunnen fanboys zijn, maar ook mensen die gewoon echt niets anders willen zien. Het type dat de vingers in de oren steekt en "LALALALALA!!!" roepen zodra je ook maar iets in die richting gaat met een gesprek. Degene die 't topic heeft geopend is duidelijk bang om uit z'n eigen vertrouwde omgeving te stappen. Zou die persoon ook zo en public zijn? Vragen... vragen...

[gekkie]

Hmmm kan tweakers geen "Eliza" knopt maken .. voor automagische psychoanalyse

hmmm tis wel hongkong ssh scan night geloof ik.

Ah kijk eens aan .. schedule van Fosdem 2015 begint langzaam aan wat gevulder te raken, nu hopen dat ze niet net als vorig jaar op de avond van te voren het schema nog wijzigen zodat je geplande dingen toch niet meer kunt volgen. Wel jammer dat de Uni daar geen grotere zalen heeft .. wat afgelopen jaar toch regelmatig lastig om een plekje te bemachtigen.

[ Voor 81% gewijzigd door gekkie op 22-12-2014 22:40 ]

[d1ng]

strandbal schreef op maandag 22 december 2014 @ 12:13:
Ja is een patch (via freebsd-update). Overigens net geprobeerd en hij wil nog steeds m'n root opruimen, dat valt me toch tegen

De officiële fix is er inmiddels. https://lists.freebsd.org...2014-December/001614.html

Wordt meegepikt bij de eerstvolgende keer dat je deze invoked.

code:

# freebsd-update fetch
# freebsd-update install

[Steef]

* Steef zwaait vanuit KF5 / plasma-next

Dolphin heeft het niet gehaald naar de 14.12 release maar de rest is best stabiel.

Andere KF5 / plasma-next testers hier ?

[ Voor 4% gewijzigd door Steef op 25-12-2014 14:39 ]

[Verwijderd]

Beste Wensen

*1ste post ooit!!*

'Nieuwe' lid meld zich.

Eigenlijk kom ik al jaren op Tweakers,want via 1 van de NLse computervakblad(die ik al leest sinds winter/lente 2002) had ik me aangemeld voor het nieuwsbrief.

Tweakers.net is eigenlijk de allereerste website waarbij ik mijn gmail account gebruikt (technisch had ik het op de 22e December 2004,maar officieel is het sinds 2 januari 2005 als main email account voor letterlijk alles).

28 December 2004 was de eerste nieuwsbrief aanmelding(18:00 als de tijdstip),maar op 13 januari 2005 had ik voor 2e keer aangemeld(met 12:00 als tijdstip) en sindsdien is het onveranderd gebleven.

Bovendien ontdekte ik Linux(en dus Debian/Ubuntu familie) voor het eerst via nieuwsbrief bericht van 2 januari 2005(was een zondag*),en juist die dag was ik bezig met mijn 1ste GeOtGa** marathon(was maar 5 uur in totaal). Quake 2 op een AMD computer(die we bijna 1 jaar eerder hadden gekocht) in godmode.

*Tweakers is sinds die dag 1 van de 10 websites als startpagina(samen met Google natuurlijk) als ik main webbrowser opent.Van 2 januari 2005 tot 2 januari 2012 maakte ik gebruik van Mozilla Firefox(na 8-9 weken in test,met versie 1.0),sinds 2 januari 2012 Google Chrome(die opmerkelijk genoeg weinig moeite heeft met ~20 tabs gelijkertijd in gebruik).

**Geek/Otaku/Gaming

_{(ik ben altijd specifiek met veel dingen)}

[Ultraman]

Hero of Time schreef op maandag 22 december 2014 @ 22:06:
Er zijn ook genoeg Windows gebruikers die pertinent weigeren een ander OS te leren. Dat kunnen fanboys zijn, maar ook mensen die gewoon echt niets anders willen zien. Het type dat de vingers in de oren steekt en "LALALALALA!!!" roepen zodra je ook maar iets in die richting gaat met een gesprek.

Ik bedenk mij dat dat eigenlijk prima Unix/Linux users zouden kunnen zijn. Als er iets al jaren en jaren nagenoeg hetzelfde werkt is het wel de command line met een Unix shell. Precies datgene wat ik nou ook zo prettig vind, die gelijkheid afgezien van soms wat dialect tussen verschillende varianten (GPL userland of BSD userland bijv). Distro-specifieke zaken zoals pkg management daargelaten.

En verder zitten er in diezelfde wereld ook genoeg conservatievelingen die alles graag bij het oude wat werkt houden. Zouden ze prima tussen passen mits ze 1x een grondige aanpassing durven te slikken.