Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 91 reacties
Submitter: sybrenw

Debian 8.0, met codenaam Jessie, moet op 25 april als final beschikbaar komen. Dat heeft ontwikkelaar Niels Thykier van het Debian Release Team laten weten op de mailinglijst van de Linux-distributie.

Debian logoVolgens Thykier zijn de leden van het ontwikkelteam achter Debian het er over eens geworden dat een release van Jessie op 25 april haalbaar is. Er moeten nog wel enkele tientallen bugs worden weggewerkt voordat Debian 8.0 vrijgegeven kan worden. Dit moet voor 18 april gebeurd zijn. Alleen als er nog kritieke bugs worden gevonden zal de geplande release op 25 april niet doorgaan.

Debian 8.0 Jessie belooft onder andere verbeterde multimediamogelijkheden. Zo is veel mediasoftware bijgewerkt en is er een 'XBMC for Debian'-package beschikbaar. Daarnaast bevat de Linux-distributie een verbeterde installer onder de naam Jessie Installer. Verder kan de gebruiker voortaan de Cinnamon- en Mate-desktopomgevingen installeren en er is ondersteuning voor Docker. Ook nieuw in de repositories zijn Owncloud, https-everywhere in Firefox en de tool 'needrestart' waarmee nagegaan kan worden of bepaalde services na een update een herstart nodig hebben.

Moderatie-faq Wijzig weergave

Reacties (91)

Vergeet er niet bij te vermelden dat de overstap ook gemaakt is naar systemd.
Dat is geen keuze, dat is verplicht en zonder werkt een hoop niet.
Jammer dat Debian zich zo over heeft gegeven aan een pakket.
Gelukkig word er al aan een versie gewerkt zonder systemd (devuan), al weet ik niet hoe snel die zal uitkomen....
Een aantal voordelen van systemd op een rij:

- veel snellere (paralelle) boot tijden (handig voor servers en devices)
- het systeem kan processen betrouwbaar stoppen.
- het systeem kan processen goed sandboxen (quota/resource gebruik)
- het systeem kan zelfstandig netwerkverbindingen starten/stoppen.
- het systeem kan services expliciet starten nadat een netwerk mount up is.
- het systeem kan services on demand starten.
- het systeem kan start/fail en log messages per service bijhouden.
- sysadmins kunnen processen afschermen, als een soort docker/jail/chroot op systeemniveau.
- goede afhandeling van encrypted harddisks
- goede sysadmin tools, bijvoorbeeld raadplegen wat er mis gaat met: systemctl --failed
- goede log-analyse tools (zie journalctl, gewoon zien wat op datum X of voor sevice Y gebeurt, t.t.t. bladeren door losse log files)

Voor laptops:
- het systeem kan beter met hotplugging en veranderende omgevingen omgaan
- betere snapshot/restore functie (voor hybernate)

Er is met systemd eindelijk 1 dirigent die over het systeem gaat, en zorgt dat alles opstart/draait en afsluit. Daar staat sysvinit maar kaal tegenover, wat alles met een hoop losse scripts opstart. Mijn Macbook kan met 4 seconden afsluiten, Linux doet daar 1 minuut over, omdat al die losse scriptjes 1 voor 1 moeten draaien en continue nieuwe processen forken. Tuurlijk was het hacken met scriptjes leuk (bijv. in Slackware :)) en iets nieuws leren vervelend, maar ik zie dat dit toch een grote sprong vooruit is. Voor servers een ander opstartsysteem houden dan voor Laptops/desktops is vragen om moeilijkheden, des te beter dat ze 1 lijn trekken. (en die is hard bevochten)

[Reactie gewijzigd door YaPP op 1 april 2015 17:40]

Tja, systemd...

Allemaal leuk en aardig voor workstations/laptops, alleen zijn bijna al de genoemde 'voordelen' in het geheel niet belangrijk voor servers. Die horen niet of nauwelijks te booten.

Daarnaast wordt voorbij gegaan aan de UNIX filosofie, ik noem er een paar;

"Rule of Modularity: Write simple parts connected by clean interfaces."
kleine simpele tools welke bepaalde taken heel goed kunnen, door ze samen te laten werken kunnen ze complexe taken doen: 'Do one thing and do it well'.

"Rule of Composition: Design programs to be connected with other programs."
Dus geen binary files, zoals bij systemd het geval is bij logging. Wat is er mis met text based logs ??

"Rule of Simplicity: Design for simplicity; add complexity only where you must."
Systemd wil zoveel tegelijk regelen waardoor je al snel door de bomen het bos niet meer ziet. Dit is niet nodig.

"Rule of Robustness: Robustness is the child of transparency and simplicity."
Systemd is verre van transparant en simpel.
Ik vergelijk het altijd maar met sendmail versus postfix. Aan sendmail configs durven maar weinig mensen aan te komen vanwege de complexheid en gebrek aan transparantie. Postfix configureren en begrijpen is een makkie.

Ik ben geen tegenstander van veranderingen, maar systemd is naar mijn mening geen stap in de juiste richting. Helaas worden we gedwongen deze richting op te gaan.

Systemd, leuk en aardig voor desktops, minder leuk en aardig voor serverfarms van enkele honderden machines. Complexe software heeft nou eenmaal veel bugs, simpele software veel minder.

Keep It Simple Stupid!
Systemd, leuk en aardig voor desktops, minder leuk en aardig voor serverfarms van enkele honderden machines.
Systemd wordt al gebruikt binnen RHEL en SLES. Beiden worden voornamelijk gebruikt voor servers. Dit "niet geschikt voor servers" is zo duidelijk nergens op gebaseerd.

Je hebt het b.v. over robustness. Ik heb vaak genoeg gehad dat het vertrouwen op PID files ertoe leidde dat een service niet goed opstartte. Zulk soort problemen zijn er niet meer. Verder leken soms sommige services op te starten, om vervolgens toch niet te werken.

Dit allemaal gebeurde niet vaak (denk 1x/jaar ofzo), maar toch enorm vervelend.

Ik vraag me echt af of je ervaring hebt met het beheren van servers. B.v. stderr+stdout logging van elke service en die output zien als je de status vraagt is echt enorm handig.
Ik vraag me echt af of je ervaring hebt met het beheren van servers. B.v. stderr+stdout logging van elke service en die output zien als je de status vraagt is echt enorm handig.
Inderdaad. Ik zit hier als serveradmin even naar te kijken en ik zie eigenlijk alleen maar supervette, ontzettend handige dingen juist voor servers.

[Reactie gewijzigd door CyBeR op 3 april 2015 11:30]

(...)
Daarnaast wordt voorbij gegaan aan de UNIX filosofie, ik noem er een paar;
(...)
Keep It Simple Stupid!
Compleet bogus. "systemd" naast pid1 ook een grote verzameling kleine tools die volgens de UNIX filosofie werken. Dit wordt heel mooi weerlegd door de developer:. Zie: http://0pointer.de/blog/projects/the-biggest-myths.html

1. Het bestaat uit 69 losse binaries. Die allemaal 1 ding doen.
2. Simplicify: Er worden vaak langzamere code oplossingen gekozen als deze duidelijker blijven.
3. Ook boottijden zijn voor servers relevant (denk ook aan VPS systemen en automatische opschaling van een cloud). Met 1 sec boottime kan je dynamisch vps'en starten/stoppen bij load.
4. Je kunt gewoon shell scripts blijven gebruiken als je dat nodig hebt.
5. Eenvoud: configuratiefiles zijn juist makkelijker geworden.
6. Het is supermodulair te configureren/compilen.
7. Het is ook voor servers. Daarom investeerd Red Hat er zoveel in.
8. Geen NIH. Aanvankelijk probeerde Red Hat juist Upstart over te nemen.
...
17. Je hebt gewoon text files voor de config! Geen XML oid.

Die UNIX filosofie wordt juist heel erg goed aangehouden door systemd.
Een nadeel: je bent verplicht glibc te gebruiken. Dat is een harde dependency waar je niet onder uit komt. SystemD + glibc samen alleen al is groter dan de gemiddelde embedded linux distro. Je kan het dus niet gebruiken op non-desktop/server/laptop systemen. Daarnaast vreet het in verhouding ook best veel RAM en CPU cycles.

Dit is vooral ook een probleem aan het worden om dat er kernel straks voornamelijk nog in combinatie met systemd gebruikt wordt door de grote distro's, waar door de grootste schare gebruikers en developers opeens hun tijd niet meer in non-systemd steken en eventuele nieuwe ontwikkelingen en optimalisaties straks dus niet buiten systemd om kunnen.
Systemd gebruikt sommige dingen van glibc die niet beschikbaar zijn in alternatieven. In plaats van workarounds in elk project kunnen de alternatieve libc's de missende functionaliteit toevoegen. Er is namelijk geen hard dependency, d'r is alleen een duidelijk statement dat indien the libc functionaliteit mist, het opgelost moet worden in de libc, niet in systemd.
- veel snellere (paralelle) boot tijden (handig voor servers en devices)
Na 3+ minuten wachten op server BIOSen is die 20 seconde voor Linux booten en sequential starts van services niks.
Na 3+ minuten wachten op server BIOSen is die 20 seconde voor Linux booten en sequential starts van services niks.
Dan raad ik je zeer aan een VM te nemen, want dan boot je wel snel! ;)

En met socket-based activatie kan je dus een cloud snel opschalen met meer VPS systemen, omdat die in 1 seconde kunnen booten. Heel handig juist voor servers!

[Reactie gewijzigd door YaPP op 2 april 2015 12:50]

Mijn laptop start in 6 seconden na Grub en sluit af in 5 seconden.
Het systeem is Xubuntu 15.04 !
Wat is dan je bezwaar tegen systemd? Toegegeven, sysvinit of Ubuntu's variatie upstart werkte prima en ik zie niet direct een reden om het te vervangen, maar ik zie ook weinig redenen om het niťt te vervangen. Blijkbaar is er een aardige schare developers bij diverse distributies die meent dat Systemd een betere aanpak is.

Alhoewel ik ArchLinux in zijn geheel als een van mijn slechtste Linux-ervaringen ooit beschouw had ik bijzonder weinig moeite met het systemd-systeem wat daar al tijden in gebruik is. Het werkt prima, doet wat het moet doen, scripts ervoor zijn eenvoudig te schrijven en opstarten ging wel degelijk sneller dan een Debian-machine met vergelijkbare software.
Het nadeel van upstart is dat Ubuntu het gaat uitfaseren - ten gunste van systemd, uiteraard. Voor PC's en laptops is het voordeel van systemd overduidelijk.

Nu kun je 2 dingen doen met servers. Of je kiest als Debian ervoor om init te blijven ondersteunden (nadeel: alle packages moeten 2 init systemen ondersteunen) of je kiest ervoor om te standaardiseren op systemd (nadeel: klagende sysadmins die iets nieuws moeten leren).

Ik ben het wel eens met de keuze voor consistentie, overal systemd.
Fijne korte uitleg. Ik kom net een beetje bij Linux om de hoek kijken en gebruik nu ook Jessie. Had wat gelezen over kritiek op systemd maar gebreep de voors- en tegens niet.
-edit- Miste dit een beetje in het stuk.

[Reactie gewijzigd door FearlessAss op 1 april 2015 12:47]

Dan zou ik me nog maar even verder inlezen, want het is veel en veel te simplistisch om het zo samen te vatten.
Iets nieuws leren is soms inderdaad vervelend, maar als ik een aantal verhalen op internet mag geloven, zijn de meeste sysadmins bijzonder blij met systemd, aangezien het een heleboel dingen makkelijker maakt.
Inderdaad, de tevreden sysadmins hoor je minder dan de klagende sysadmins dus dat kan inderdaad het beeld iets vertekenen.

Mijn eigenlijke punt was dat package developers niet klagen over de standaardisatie op systemd. Meer keuze voor sysadmins betekent meer werk voor developers.
(nadeel: klagende sysadmins die iets nieuws moeten leren).
Daar heb ik eigenlijk nog niemand over zien klagen. De grote klacht is dat SystemD andere projecten opslokt en verdringt. Systemd is niet alleen een init-systeem. Dan hadden ze het wel initd genoemd. Het doel van systemd is het hele management van Linux-systemen over te nemen. In een enorm tempo wordt tientallen jaren aan werk weggegooid en vervangen door nieuwe code. Nieuwe code is leuk maar bevat altijd bugs. Het zal nog jaren duren voor alle randgevallen die nu worden ondersteund ook in systemd zitten.

Daarbij verlies je de mogelijkheid die je vroeger had om te kiezen uit verschillende componenten. Er zien nu verschillende NTP-implementaties, dhcp-clients, netwerkmanagers, etc. Systemd wil die allemaal vervangen en doet dat op een vrij dwingende manier. Het is alles of niets. Daarmee conflicteren ze met de Unix-traditie om voor ieder probleem een kleine tool te maken die zich helemaal specialiseert op dat ene probleem.

Systeembeheerders willen best iets nieuws leren, dat is een essentieel onderdeel van het vak. Ook is er brede overeenstemming dat er een nieuw init-systeem nodig is en dat systemd momenteel de beste papieren heeft. Het verzet is tegen de expansiedrift van systemd waardoor niet alleen het initsysteem vervangen wordt maar allerlei andere onderdelen vervangen moeten worden.

Debian heeft het nog vrij conservatief aangepakt, zo is Debian nu eenmaal, maar nu ook Debian over is voelt het of het hek van de dam is. De versie van systemd die voor jessie is gekozen is nog vrij terughoudend. Latere versies nemen steeds grotere stukken van het basisysteem over. Bij de volgende release van Debian zal ook een van de nieuwere releases van systemd gebruikt moeten worden.
Een hoop projecten zullen veel gebruikers kwijt raken omdat die gedwongen worden om de systemd-alternatieven te gebruiken. Als iemand ooit systemd wil vervangen zal er ook vervanging moeten komen voor alle componenten die nu door systemd zijn overgenomen. Dat voelt als het verbranden van bruggen.

Persoonlijk hoop is dat uselessd een succes wordt. Dat is een spin-off van systemd die zich juist alleen op het init-systeem wil richten.
Er zien nu verschillende NTP-implementaties, dhcp-clients, netwerkmanagers, etc. Systemd wil die allemaal vervangen en doet dat op een vrij dwingende manier. Het is alles of niets.

En dat is mijn grote probleem met systemd. Wil je de boot beter regelen, doe dat dan. Niet alle andere zut erbij. Dan kan ik bij de rest nog kiezen voor eender welk programma. Wat als ik om welke reden dan ook een andere dhcp client of ntp wil? Als ik aan systemd vast zit valt er niets meer te kiezen.
Het gaat om keuzes. In de OSS wereld is het altijd zo, ik probeer een pakketje of wat en kies voor mij de beste uit, ik hoor om me heen probeer dit eens, dit is snel/nieuw/gaaf en test het uit en stap over, of niet. Nu wordt een *zeer ingrijpende wijziging zonder meer opgedrongen, zonder duidelijke voordelen, eerder nadelen (binaire syslogs). Verder werkt het vast prima, maar wat ik al tig jaar gebruik werkt ook prima. Sneller booten? Alleen van belang op een desktop. Daarnaast worden veel zaken begraven onder een systemd abstractie layer, wat het lastiger maakt het onderliggende proces te doorgronden, en dat is nou juist zo mooi aan de huidige werkwijze. Voor Linux beginners is dit een groot nadeel.

Ik en vele anderen zien het voordeel gewoon niet. Ik sta open voor alles altijd, nu wordt ik gedwongen open te staan voor 1 zeer grote wijziging, afkomstig van een relatief kleine groep ontwikkelaars, zonder keuze mogelijkheid. Dat druist tegen alles in waar OSS voor staat.

Edit: typos.

[Reactie gewijzigd door Vinzz op 1 april 2015 12:27]

Naar mijn zeggen is systemd niet alleen sneller, maar ook robuuster, flexibeler in het configureren. Ik zie het als een redelijk grote technische vooruitgang. Daarnaast kan systemd flink helpen om de fragmentatie van de Linux wereld tegen te gaan.
Ik draai nu op Arch al een tijdje op systemd, het kost uiteraard even wennen maar nu ben ik er erg tevreden mee.
Sneller booten? Alleen van belang op een desktop.
Of bij een router, of bij Android-telefoons en -laptops, of bij Sailfish, ...
In ieder geval zorgt de straight upgrade sysvinit -> systemd niet voor dezelfde bende als je momenteel op Ubuntu (Server) hebt, namelijk dat een hoop pakketten zowel via

# /etc/init.d/dingetje start

als via

# service dingetje start

gestart kunnen worden, wat er vaak voor zorgt dat bij pakketten die het niet goed geregeld hebben, er ineens twee daemons draaien :D Heb je geen idee waardoor die daemon overeind blijft staan, ook al stop je alles? Dan moet je de andere variant nog hebben 8)7 topsysteem.

Onder andere bij elasticsearch is dit het geval om maar een voorbeeld te noemen.
Vergeet er niet bij te vermelden dat de overstap ook gemaakt is naar systemd.
Dat is geen keuze, dat is verplicht en zonder werkt een hoop niet.
Systemd is niet verplicht, maar een default.

Zie bv wiki.debian.org/systemd:
Jessie installs systemd by default on new installs. Should one desire to install without systemd, i.e use sysvinit-core instead (old sysV5 init), it is possible to use preseed to replace systemd with sysvinit at the end of the install (This probably won't work if selecting one of the desktop environments that require systemd specific features however).
En without-systemd.org:
First install the SysV init packages
# apt-get install sysvinit-core sysvinit sysvinit-utils
Then reboot your machine and remove all of the systemd packages. BE AWARE that the following command removes packages that depend on systemd itself or things like libpam-systemd!
# apt-get remove --purge --auto-remove systemd
Prevent apt from installing systemd packages in the future.
# echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
Het is misschien niet triviaal, maar voor mensen die Łberhaupt weten wat systemd is goed te doen.

[Reactie gewijzigd door deadinspace op 1 april 2015 17:55]

Ja, je kan systemd weg halen...maar dat zeg ik, dan werkt een hoop niet.
Op diezelfde pagina staat namelijk hoe je door hoepels moet springen om udisk en policykit te kunnen krijgen zonder systemd (want die hebben daar blijkbaar een afhankelijkheid voor ingebouwd)
KDE wil ook gebruik gaan maken van systemdcomponenten ... leuk, maar dan gaat dat dus ook niet meer werken etc.
Dus nee, ook niet voor mensen die weten wat het is, is het niet goed te doen om het te verwijderen.
Debian heeft juist prima mogelijk gemaakt om systemd niet als init system te gebruiken. Alleen als je enorm anti "systemd" bent zal je problemen zien die er niet zijn. Er is b.v. 1 library dat niks doet als je geen systemd draait. Deze library zal wel op je systeem blijven staan maar doet dus helemaal niks. D'r zijn een aantal mensen die hier een probleem van maken en vervolgens hun systeem op zeep helpen.. tjah.

Debian bevat verder "systemd-shim" zodat je prima GNOME en KDE kan gebruiken. Het was in het begin een beetje buggy, maar tjah, als je zo graag alternatieven wilt gebruiken en denkt dat dit automatisch beter of meer "UNIX-like" is, dan vind ik het persoonlijk wel grappig dat in de praktijk dit gewoon zorgt voor bugs :-P Inmiddels zijn de meeste bugs al opgelost trouwens (behalve theoretische "race conditions" bugs).
Fijn iemand die niet een keer alles voor zoete koek aanneemt. Ik snap niet dat zo'n ingrijpende wijzigingen zo opgedrongen wordt. Koen Vervloesem zei vorig jaar al in Linux Magazine, Linux wordt Windows, en dan kunnen er sws weer veel boeken en consultancy verkocht worden bij Red Hat (waar het systemd initiatief begonnen is).

En met welk ECHT voordeel? Voor de Linux desktop kan ik er misschien nog inkomen.. Maar op een server, nee.
Mijn servers draaien nu 7.6 / 7.8, heb net afgelopen maandag weer een 7.8 geinstalleerd. En ik was daar al aan het kijken naar systemd. Wat is namelijk mijn probleem? Mijn applicatie-servers draaien een service, die NAS toegang nodig heeft. Omdat SysV init geen filesystemen kan mounten, kan ik geen dependency aangeven tussen het mounten en de service start. Ik moet dus een hack gebruiken die niet de service start, maar een shellscript wat wacht op de NAS. Met systemd kan ik wel die dependency aangeven.
In mijn ogen is dit een uitdaging en is dat wat het hele werk leuk maakt.. Als alles voor je geregeld moet worden, moet je idd systemd, of Windows gaan gebruiken
Ik ben een professional. "Leuk" is een criterium wat ergens onderaan de lijst van relevante criteria bungelt. Betrouwbaar staat een stuk hoger, en ik weet dat mijn scriptjes niet zo goed gereviewed worden als de systemd code.
Ik vind de argumenten van MSalters stukken beter tot nu toe. Software draait niet om leuk zijn..
Fout. Leuk is niet het criterium voor fouten. Je bent mogelijk in de war door routinewerk, wat niet leuk is en ook nog tot fouten leidt. Daaruit mag je geen conclusies afleiden voor niet-routinewerk.

En ik vertrouw jouw scripts nog minder nu ik je houding zie. Juist dat gebrek aan zelfinzicht vertelt me dat jij niet kritisch genoeg bent op je eigen werk, en dat is een groot risico.
Een professional weet dat zij regelmatig fouten maakt. Een amateur daarentegen is vaak overtuigd van eigen perfectie.

Ik wist het wel als ik moest kiezen welke admin ik liever in dienst had. Iemand die sarcastisch "jij niet dan, professional?" blert verdient geen respect.
Klopt, de overstap naar systemd is erg ingrijpend, vooral voor de embedded tak van Debian.

Het feit dat systemd nieuwere kernels werkt ook totaal niet mee, omdat een upgrade vaak niet mogelijk of erg moeizaam is door beperkte support van de fabrikanten.
Hopelijk komt Devuan een beetje van de grond..
Het is ons bij XBian prima gelukt om systemd te overulen met upstart. Het is dus wel mogelijk.
Klinkt voor een .0 versie nog niet heel spannend.. of moet ik dit niet vergelijken met MacOSX of Windows? :)

Wel tijd om Linux weer een kans te geven bij mij thuis.
Ja en nee, debian bestaat altijd uit 3 releases
development: bleeding edge software dat dingen mag breken
testing: software dat dingen kan breken
stable: tried and tested software dat dingen niet mag breken

bij een nieuw release dan gaat het als volgt development->testing->stable->old.

Bij debian gaat het altijd om stabiliteit.
En FOSS. Geen pakket komt de default repos in wat zich niet houd aan de debian guidelines.
Andere distro's zijn hier imo erg laks in.
The code name for Debian's development distribution is "sid", aliased to "unstable". Most of the development work that is done in Debian, is uploaded to this distribution. This distribution will never get released; instead, packages from it will propagate into testing and then into a real release.
https://www.debian.org/releases/sid/

Releases gaan altijd: testing -> stable -> old-stable
Packages worden mature genoeg om in testing te plaatsen (tenzij de freeze is begonnen).

[Reactie gewijzigd door elmuerte op 1 april 2015 23:25]

Wanneer je linux wilt uitproberen zou ik Mint of Ubuntu nemen. Beide werken out-of-the-box beter op een desktop dan Debian. Dan heb je zonder gedoe meteen een systeem draaien dat zich zeker kan meten met OSX of Windows. Zelf gebruik ik Mint als desktop en Debian voor m'n servers.
Sory ben ik het totaal niet mee eens. Debian installeert makkelijk en probleemloos en werkt als en zonnetje. Mint of Ubuntu bieden in dat opzicht niets beter (nieuwere versies betekent niet beter). Sterker nog, met meerdere versies van Ubuntu en Mint ervaarde ik wel problemen met de installer, terwijl Debian altijd zonder problemen installeert.

Uiteindelijk is het voor mij Arch Linux geworden. Arch is de bom! :).
Debian installeert zeker makkelijk en werkt altijd als een zonnetje. Helemaal mee eens! (dat is ook waarom ik het voor m'n servers gebruik) Het kost nog wel de nodige moeite flash e.d. aan de praat te krijgen, iets waar je met Mint of Ubuntu geen omkijken naar hebt. Arch is beslist top, maar vergt relatief veel onderhoud en een hoop kennis. Mijn ervaring met Mint is dat je redelijk bij bent wat software betreft en dat het altijd werkt - best of both worlds.

Hoe dan ook, deze discussie geeft wat mij betreft meteen aan wat er zo geweldig is aan linux: genoeg distro's om elk wat wils te bieden! :-)

[Reactie gewijzigd door menocchio op 1 april 2015 12:39]

Dat is waar in de tijd van Squeeze en Wheezy idd. Ik draai Jessie nu twee weken: Flash installeren was een kwestie van deze twee commando's:

apt-get install flashplugin-nonfree
update-flashplugin-nonfree --install

Er zal vast ook wel een gui variant zijn, maar ik gebruik zelf geen gui package manager.
Op Wheezy kan je ook apt-get/aptitude install flashplugin-nonfree uitvoeren. Op Squeeze werkte dit dacht ik zelfs al.(Squeeze zelf vrij weinig gebruikt).
En elke debian komt met een mooie grafische packet manager als je desktop aanvinkt bij installatie.

Ik zie niet waarom mensen altijd gaan voor de Ubuntu's/Mints e.d., wat juist gebaseert is op Debian. Debian doet niets moeilijker. En de werkwijze van de Debian devs is gewoon baas.

Ubuntu, Mint e.d. breken IMO juist af aan de credits die aan debian toebehoort. Beetje meeliften op 95% van het werk wat in Debian gestopt word.

Netflix, flash of veel andere basis meuk voor de internettende henk en ingrid werkend krijgen is op zowel Mint, Ubuntu of Debian hetzelfde.

Alleen een mafkees draait Debian Sid voor henk en ingrids of in productie, raad eens waar Ubuntu en dus ook Mint op gebaseert zijn. En wat mijn ervaring met Ubuntu ook niet denderend maakt, updates die systemen platgooien....

[Reactie gewijzigd door batjes op 1 april 2015 15:28]

Je mag dit inderdaad niet vergelijken. Bij Debian gaat men niet zozeer naar een nieuwe versie omdar er een belangrijk pakket (zoals een desktop environment) vernieuwd is. Debian brengt een stabiele versie uit en veranderd een pakket daarin nooit meer van versie. Een nieuwe point release is dan ook gewoon een mogelijkheid voor het OS om alle pakketten van een nieuwere versie te voorzien.
Niet helemaal waar. In Wheezy (de huidige stable) kwam al snel een nieuwere versie van Icedove en Iceweasel uit. Dit om meer inde pas te lopen met de snelle updates van Firefox en Thunderbird. Hoewel dus in principe 'niet veranderbaar' is dat voor deze twee programma's wel het geval.
Debian volgt the long-time releases van Firefox. Firefox ESR "Extended Support Release". Dat zijn versies die extra security/stabiliteits updates krijgen.

Dat betekend op dit moment Firefox 31 en daarvoor Firefox 24 en na 31 komt 38.

Terwijl de normale Firefox release cycle zit op dit moment op: 37

Edit: 37 was net uitgekomen, ik had per ongeluk 36 getyped.

[Reactie gewijzigd door Lennie op 1 april 2015 12:36]

Bepaald niet, nee. Ontwikkeling hiervan gaat veel meer incrementeel.
Klinkt voor een .0 versie nog niet heel spannend.. of moet ik dit niet vergelijken met MacOSX of Windows? :)
Alle packages zijn bijgewerkt. Het ligt er maar net aan wat je gebruikt. Wanneer je de Gnome desktop gebruikt dan wil je vast wel updaten, dat wordt langzaam wel beter.
Ook de mogelijkheid om voor Mate of Cinnamon te kiezen is natuurlijk goed. XFCE is nog altijd 4.10 ipv de net uitgekomen 4.12, maar dat is niet heel dringend. Ook KDE zal een nieuwe versie zijn met veel verbeteringen.

Gebruik je het als server, dan is er bijv. een nieuwere PHP 5.6, de huidige versie.
Ik moet zeggen dat de nieuwe crossbuild en multi-arch dingen toch best wel interresant zijn in Jessie, al kan ik ook begrijpen dat de gemiddelde gebruiker dat niet veel zal gebruiken. Maar voor embedded ontwikkeling is het wel erg welkom, je kunt bijna net zo makkelijk iets bouwen voor je eigen target (bij mij amd64) als voor een volledig andere processor (bijvoorbeeld arm).
IMO is Linux (helaas) ook niet echt spannend, zeker niet voor de desktop. Alle software is (natuurlijk) wel vernieuwd maar echt grote verbeteringen zijn er volgens mij niet.
IMO is Linux (helaas) ook niet echt spannend, zeker niet voor de desktop. Alle software is (natuurlijk) wel vernieuwd maar echt grote verbeteringen zijn er volgens mij niet.
Regelmatig gebeuren er toch nieuwe releases van softwarepakketten. Zo is bijv. KDE5 op komst of hadden we enkele jaren terug Gnome3.
Inderdaad, enkele jaren geleden. Ik heb het gevoel dat het allemaal gewoon een beetje traag gaat.
Traag in vergelijking met wat, Microsoft of Apple? Twee miljarden biz bedrijven tegenover iets wat gratis is en beter?

Microsoft heeft af ten toe een andere desktop omgeving al dan niet geslaagd, Apple is grotendeels hetzelfde gebleven met een wat andere look en per versie wat nieuwigheden onder de motorkap ed.

OSX had ik eerst op mijn eerste mac, dan als hackintoch maar wie wil OSX als je KDE gebruikt? Dat is een paar jaar terug in de tijd. Hackintosh eraf en KDE erop.

Linux bestaat uit gedeeltelijk betaalde en grotendeels vrijwilligers en dan brengen ze het er toch nog goed vanaf.

Debian draait zoals hierboven aangegeven alles om stabiliteit. Ik heb alles uitgeprobeerd tot en met meer dan 40 Distro’s in multiboot. Uiteindelijk gekozen voor gebruiksvriendelijke versies zoals PCBSD, Sabayon en Manjaro die rolling en bleeding edge zijn.

Nu wil ik nog alleen maar Debian. Het doet wat het moet doen, geen hoofdbrekens, crashes of een systeem dat niet meer opstart na een update .

Dan ben ik blij dat Debian om stabiliteit draait. Om de paar jaar een versie en ik heb een 2de partitie met debian testing als ik wat recentere software wil gebruiken.
Heel lang geleden (op 16 januari 2000, de dag dat Richard Braakman via de debian-devel-announce liet weten dat "Debian "potato" is frozen!" om precies te zijn) heb ik de eerste keer Debian geÔnstalleerd. Ik heb geen flauw idee hoeveel updates die installatie intussen gekregen heeft en ik weet ook niet meer juist hoe vaak ik de schijf waar hij op stond naar een nieuwe machine verplaatst heb of de inhoud naar een nieuwe schijf gekloond heb, maar hij draait nog steeds. Eerst volgde ik de stable releases en een jaar of twee nadat testing tussen unstable en stable gecreŽerd is, ben ik daarop overgeschakeld (voor regelmatigere en minder ingrijpende upgrades). Ik denk dat ik in al die jaren 2 of 3 keer een upgrade gehad heb die het systeem in een unbootable staat achterliet en de migratie van i386 naar amd64 en de kopie van de msdos partitietabel met bios naar gpt met uefi hebben ook wat moeite gekost. Voor de rest draait die installatie nog altijd op mijn desktop, laptop en mijn rescue-usb-schijf.

Vroeger had ik nog een lijstje met te proberen distributies als ik hem eens opnieuw moest installeren, maar dat is de afgelopen 15 jaar niet gebeurd, dus ik verwacht niet dat dat nog gaat gebeuren.

Als iemand mij vraagt of Debian moeilijk te installeren is, moet ik dus eerlijk antwoorden geen flauw idee te hebben hoewel ik dat al 15 jaar zo goed als uitsluitend gebruik. :)
Er zijn beslist installers die iets gebruiksvriendelijker zijn en makkerlijk ogen en met dezelfde install opties als die van Debian.

De installer met de meeste toeters en bellen is zonder twijfel die van openSUSE. Die van Ubuntu is de meeste makkelijke en anaconda (oa Fedora) daar heb ik goede en minder goede ervaringen mee.

Wat mij opvalt aan Debian is de enorme tijd die het nodige heeft om een desktop omgeving te installeren vergeleken met andere distro's. Vooral als je voor de optie kiest om de laatste updates erbij te installeren.

Een distro met rolling updates is leuk maar mijn ervaring nu is dat er toch telkens problemen opduiken waardoor je met een brak systeem zit.
Wat betreft de installers kan ik je dus alleen maar geloven. Ik installeer af en toe servertjes of embedded systemen, maar eigenlijk altijd door de schijf in een werkend systeem te steken, te partitioneren en er met debbootstrap een werkend basissysteem op te zetten.

Ik heb op de desktop geen problemen met de Debian testing (dat zijn de packages waar na 2 tot 10 dagen in unstable geen te zware bugs tegen gerapporteerd zijn). Naar mijn ervaring gaat dat vloeiender dan de grote updates van release tot release, waar altijd wel een paar pakketten die ik nodig had om wat voor reden dan ook door de apt-get dist-upgrade gedropt werden. Af en toe werkt er eens een package niet en dan zet ik de vorige versie even op hold in aptitude. Dat gebeurt denk ik 2 of 3 keer per jaar. Op servers en embedded systemen ga ik altijd voor stable.
Windows heeft sinds XP bij elke major release een andere desktop omgeving gekregen. Het meest in het oog springende waren de wijzigingen aan het menu en vanaf W8 natuurlijk de Modern UI (Metro) look. Dat stapje was te groot voor het merendeel van de Windows gebruikers, dus doet Microsoft nu een stapje terug met en soort 'hybride' omgeving waarbij je kunt kiezen uit het klassieke start menu (default in W10) of het start screen uit W8.

En de aanstaande Windows 10 pakt de user desktop opnieuw aan.

Daarbij houd ik normaal gewoon Debian stable aan, en bepaalde (zeer selectief) packages heb ik gepinned naar een andere repository (testing, backports, etc)..
xp/vista em win7 zijn verschillend in die zin dat ze allemaal een startmenu hebben en alles niet meer op dezelfde plek staan om het ruw uit te drukken.
Ik vind 8 als desktop interface eigenlijk een major release.

apt pinning heb ik eigenlijk alleen maar gebruikt op mijn ASRock met SteamOS dat ik als streaming device gebruikte en soms voor iets anders. Dat was handig totdat er een update uitkwam van Nvidia en het grafisch gedeelte niet meer ondersteund werd.
Nu draait er gewoon Xubuntu op.
Recentere software ? -> container
Daar staat tegenover dat hoe beter een product is, des te minder spectaculair de verbeteringen zullen zijn.
Een linux distributie is net als windows aan pakket dat bestaat uit: een kernel, grafische interface, systeem services, applicties, etc.

Aangezien echt vrijwel ieder stukje software is geupdate, mag je dit zeker wel als een "spannende" release zien.

Interessant feitje: SteamOS wat de laatste tijd wat meer in het nieuws is geweest gebruikt ook Debian.
Voor mijn gevoel is dit heel snel; zat er tussen voorgaande stables niet veel meer tijd? (niet dat het erg is, maar ik krijg er gewoon zo'n 'time flies' gevoel van :P )
De vorige stable release is bijna 2 jaar geleden. Die kwam 2 jaar na de vorige. Daarvoor zat er veel meer tijd tussen.
Vorige stable 2 jaar geleden alweer?! Darn.. time does fly :)

Trouwens ontopic, werk nu al weer een tijdje met jessie en hij voelt fijn aan :)

[Reactie gewijzigd door bazkie_botsauto op 1 april 2015 11:39]

Verder is er nu Debian LTS, dus Wheezy zal een LTS repo krijgen na deze release.
Same here, voelt bijna aan als gisteren.

2 jaar.... jeeeez :S
Vroeger stond Debian bekend om de lange tijd tussen release. Men werkte door tot een release perfect was en dat kon heel wat jaren duren. Mijn vriend heeft nog een t-shirt met de tekst "Debian: Good things come to those who.... wait."
De laatste jaren is het releasemanagement echter flink veranderd. Zo gaat men bijvoorbeeld sneller over tot het verwijderen van software die kritieke bugs bevat. Hierdoor lukt het ze om ongeveer eens per twee jaar een release uit te brengen.
Owncloud in de repositories wordt wel een goed argument om over te stappen naar Debian straks. :)
Waarom? Repositories lopen toch altijd achter voor dergelijke dingen. Web-software installeer ik eigenlijk altijd handmatig en niet via de repositories.

Verder werken de OwnCloud repositories (http://download.opensuse....ud:/community/Debian_7.0/) prima op Debian voor de desktop client en worden beter bijgehouden dan Debian ooit zou kunnen/willen. Dus wat mij betreft mogen ze die er wel uitlaten, levert hoogstens conflicten op.
Weet je zeker dat je dat wilt doen? Het sterke punt van repositories is juist dat al je software 100% gemanaged en up to date is. Zolang je een supported distributie draait krijg je dus ook alle security patches binnen. Juist met web-software is dat veel belangrijker dan mogelijk de nieuwste versie kunnen draaien.

Een andere optie is inderdaad om een ppa of iets dergelijks te gebruiken van de ontwikkelaars zelf, want dan ben je dus ook zeker van updates en patches.
Mja, in mijn ervaring zijn de maintainers van webpackages zoals phppgadmin, phpmyadmin, roundcube, owncloud server en dergelijke niet heel erg actief en lopen achter. Niet alleen op het gebied van nieuwe features, maar ook op het gebied van bugfixes en security patches.

Ik ben dolgelukkig met package management systemen die het grootste deel van mijn systeem inclusief alle system libraries up-to-date houden en security fixes uitrollen, maar voor dat handjevol software waarvoor ik het zelf moet doen draai ik mijn hand niet om. De voordelen wegen in die gevallen sterk op tegen de nadelen.

[Reactie gewijzigd door MadEgg op 1 april 2015 14:27]

Security wordt bij Debian door een apart team gedaan en die zitten overal op.
Vooral leuk voor servers, daar de stable packages van Wheezy soms echt wel iets te gedateerd zijn naar mijn goesting.
Dat heb je met een stabiele Debian release en voor een stuk is dat ook de kracht ervan. Je bent als beheerder 100% zeker dat een Debian release niet veranderd en dat updates/fixes nooit iets breken.
True, en dat is net de reden waarom wij voor Debian kiezen. Alleen is op het einde van een releasecycle toch een vrij grote sprong met wat er beschikbaar is op de markt (bv PHP 5.4 vs PHP 5.6).
Voor de medemens die OwnCloud nu al in z'n distro wilt - volg grofweg onderstaande;
> nano /etc/apt/sources.list.d/OwnCloud.list
voeg in je bestand "deb http://download.opensure....oud;community/Debian_6.0/ /" toe.
Save en exit.

Even de key ophalen;
> wget http://download.opensuse....ty/Debian_6.0/Release.key
Source list updaten;
> sudo apt-get update
en installeren maar;
> sudo apt-get install OwnCloud

Gebruik OwnCloud zelf ook, machtig mooi dropbox alternatief.
Je kan het veel beter uit de tar.gz source zelf pakken, of nog beter Git gebruiken.
ondersteuning voor Docker
Voor het draaien van Docker op jessie is men aangewezen op de packages uit jessie-backports, omdat Docker releases te snel itereren voor een Debian stable release.

Zie het betreffende bug report: RM: docker.io -- RoM; release cycle is too fast for stable

[Reactie gewijzigd door smoking2000 op 1 april 2015 13:04]

Ja, Docker is zo'n nieuwe ontwikkeling dat je waarschijnlijk de updates wilt volgen.

Dat hele 'ecosysteem' rond Docker is nog in sterk ontwikkeling.

Ik denk dat bij de volgende Debian release over een paar jaar dat de standaard Docker en kernel wel gaan voldoen.

Want er zitten wel een aantal leuke features aan te komen op de middel lange termijn voor Docker die om een nieuwere kernel vragen.

Zoals gebruik van user-namespaces voor betere beveiliging. Zou mij niks verbazen dat seccomp ook weer wordt toegevoegd op de korte tot middel lange termijn.

Met een up to date kernel en SELinux of AppArmor is het dan misschien wel mogelijk om 'multi-tenant' te draaien.

Maar dat duurt nog wel even voor dat het zo ver is en daar hebben ze nog even tijd voor want een nieuwe Debian release duurt een paar jaar.

Ik ben benieuwd of de nieuwe Debian release tegen dit tijd dan ook kernel live patching zal ondersteunen tegen die tijd.

Dan wordt het nog makkelijker om security updates te installeren. Dat lijkt me dan ook zeer welkom als je multi-tenant Docker of andere containers zou willen draaien.

Met LXC kun je nu al wel multi-tenant draaien vermoed ik. De ontwikkelaars van Canonical (Ubuntu) zijn er mee bezig om daar ook tooling voor te maken: LXD.
Hmm, ik denk dat het tijd wordt om op m'n mediacenter van Windows naar Linux te switchen... XBMC op de standard repo's is wel leuk. Hier ga ik me tijdens de zomervakantie eens mee bezig houden denk ik.
Toch altijd een beetje bang afwachten welke ongewilde zaken er zullen veranderen in een major release. Keuze uit vele pakketten voor hetzelfde maakt het er toch niet altijd makkelijker op.
En zoals velen van jullie waarschijnlijk al weten heet XBMC voortaan Kodi.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True