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: Sallin

Op de DebConf10-conferentie die vorige week in New York werd gehouden, is door de Debian-ontwikkelaars besloten tot een freeze van het in aanbouw zijnde Debian 6.0, ook bekend onder codenaam 'Squeeze'. Een releasedatum is nog onbekend.

Debian logoBij de status 'frozen' wordt er geen nieuwe software meer toegevoegd aan een Linux-distributie en gaat een fase in waarbij de nadruk ligt op het wegwerken van bugs en het 'polijsten' van de code. Bij de Debian-ontwikkelgemeenschap moet dit uitmonden in een stabiele Debian 6.0-release. Wanneer deze kan worden verwacht is nog niet duidelijk; in tegenstelling tot bijvoorbeeld Ubuntu werkt Debian niet met vaste release-cycli.

Met de freeze is nu duidelijk welke software in Squeeze te vinden zal zijn. Naast Gnome 2.30 zal ook de windowmanager KDE 4.4.5 beschikbaar komen, naast XFCE 4.6.2 en LXDE 0.5.0. Ook zal OpenOffice 3.2.1 beschikbaar zijn in de Linux-distributie. Debian 6.0 zal verder sneller moeten opstarten door het gebruik van insserv. Als standaardkernel is gekozen voor versie 2.6.32.

Moderatie-faq Wijzig weergave

Reacties (91)

Als standaardkernel is gekozen voor versie 2.6.32.
2.6.35 is al uit ...
Als je ook kijkt op Wikipedia is dit gebruikelijk bij Debian. Zo was bij lenny (5.0) 2.6.26 terwijl 2.6.28.5 al uit was. Bij etch (4.0) gebruikte ze 2.6.18 waar 2.6.20.6 al uit was.

Stabiliteit bij debian is belangrijker dan cutting edge. Daar hoort dus ook het kiezen van een recente, maar niet splinternieuwe onstabiele kernel bij :)

[Reactie gewijzigd door mithras op 8 augustus 2010 14:36]

De 2.6.32 kernelserie is er een die heel lang ondersteund wordt door de kernelontwikkelaars,in tegenstelling tot 2.6.33/34/35. Mijn eigen ervaring is ook dat spiksplinternieuwe kernelversies, zoals 2.6.35(.1), toch nog een hoop bugs bevatten als ze net uit zijn, terwijl de 2.6.32 serie die nu intussen al meer dan een half jaar enkel bugfixes krijgt, superstabiel is.
Red Hat 6 gaat ook 2.6.32 gebruiken en volgens mij de komende of huidige Suse versie ook. RHEL 6 gaat 7 jaar ondersteund worden, dus die gaan ongetwijfeld features en support backporten. Debian al features gebackport (volgens mij voor nouveau wat uit 2.6.33) en wordt er ongetwijfeld in minor releases zoals 6.0.1 weer meer support toegevoegd.

Debian stable is is imho toch vooral voor servers en daar heb je minder vaak problemen met cutting edge hardware en ga je liever voor tried&tested.
Bij debian ligt de nadruk op stabiliteit, niet op cutting edge. Gebruik van iets oudere maar bewezen versies hoort daar ook bij.
Bij ons is dat dan ook de reden geweest om over te stappen op Ubuntu. Debian update gewoonweg te traag waardoor je tegen veel problemen aan loopt als je nieuwe, cutting (of zelfs bleeding) edge apparatuur gebruikt, met name doordat de installers vaak oude kernels gebruiken die amper geupdate worden door hun release-schedule.

Ubuntu = alle voordelen van debian + compatible met nieuwe hardware.
@ Punica: Daar kun je zelf ook wat aan doen hoor! Bij Debian kun je gewoon backports of desnoods een mixed systeem draaien (Stable/Testing of Unstable). Dan kun je gewoon Stable blijven draaien en voor bepaalde pakketten als Openoffice.org de Backports (nu versie 2.6.32-5 van de kernel i.t.t. 2.6.26 standaard kernel) Testing of de Unstable versie draaien.
Dat gaat bij Debian vrijwel altijd zonder problemen. Bij Ubuntu moet je bij een nieuwe versie je hele systeem opwaarderen, bij Debian kun je dat stapsgewijs laten doen.
Ik heb voorheen ook met Ubuntu gewerkt, maar vond uiteindelijk de Debian manier makkelijker en beter voor mijn situatie door met een rolling release versie van Debian te gaan draaien.
Ik werk nu met Testing (Squeeze) maar kan als ik dat nodig vind en de nieuwere versies van OOo of de kernel wil gaan werken altijd nog tijdelijk met de Unstable (SID) versies gaan draaien. Blijf ik toch bij als ik moet.

En i.t.t. van wat de naam doet vermoeden is de Unstable tak van Debian (SID) niet behoorlijk stabiel.
Als je nu met Stable (Lenny) werkt en de nieuwere versie van OOo wilt hebben, dan kun je met de Backports ook met OOo 3.2.1 werken. De stabiele basis van Lenny en de nieuwere pakketten via de backports gaat heel goed samen.
Ik zou zeggen: probeer het eens.

[Reactie gewijzigd door WOteB2 op 9 augustus 2010 08:59]

Ubuntu = alle voordelen van debian + compatible met nieuwe hardware.
Wat de Ubuntu LTS versie betreft heb je wel gelijk, maar de stabiliteit van tussenliggende Ubuntu versies is duidelijk minder dan Debian. Daarnaast brengt Debian met enige regelmaat minor-versie updates uit, met o.a. verbeterde hardware support. Debian 5 zit nu bv op versie (5.0.5).
Dat valt wel mee. Juist de LTS versies hebben vaak genoeg bugs. Neem nu 10.04: Radeon+KMS (wat standaard aanstaat) is gewoon een garantie voor problemen. Een RS690 laat het beeld flikkeren en de computer loopt soms vast, een R200 laat fout contrast/brightness zien en op een R100 werkt XV niet. Al die bugs zijn al wel opgelost in Radeon, maar als je eenmaal op een LTS zit..

Het zou wel kunnen dat je de fixes via de backports kan verkrijgen, maar dan offer je ook weer enige "stabiliteit" op. Al is mijn ervaring dat bleeding-edge (afhankelijk van het softwareproject) redelijk vaak gewoon stabieler is dan "stable" omdat er meer bugs in gefixt zijn.
Dan heb je de goede keuze gemaakt want debian is gewoon bedoeld voor mensen die een 100% uptime nastreven. Overigens zou je zeker eens naar Linux Mint moeten kijken. Dat is Debian + Ubuntu + Mint en geeft net nog wat meer in bepaalde omgevingen.
Keerzijde van dit verhaal is wel dat nieuwe hardware amper ondersteund worden. Zo wilde ik een machine opzetten met Debian. De computer had een onboard ATi 4200 serie videochip en deze werd in Debian via de drivers niet ondersteund. Gebruik dus Debian alleen als er andere succesverhalen zijn met jouw hardware. Anders mag je zelf gaan compileren (wat de betrouwbaarheid van het systeem weer niet ten goede kan komen) of lang wachten op de volgende stable release.
Klopt niet wat je zegt. Je kan gewoon een experimentele installer downloaden waarvan de software 100% overeenkomt met de standaard Debian versie maar de kernel extra drivers aan boord heeft zodat je niet hoeft te klooien tijdens een installatie als de driver van je HD controller ontbreekt.

En drivers zelf compileren komt de stabilietit van je systeem juist wel ten goede omdat je alleen de features/flags aanzet die je echt nodig hebt en de driver is geoptimaliseerd voor de features van je CPU.

Maar wil jij een ATI videokaart met een 3D driver ipv enkel Vesa gebruiken, dan zul je naar alle waarschijnlijkheid Linux op de desktop willen draaien en dan is Ubuntu inderdaad de betere keuze door de toevoeging van vele multimedia drivers die op een server nooit gebruikt worden.

[Reactie gewijzigd door mstam op 8 augustus 2010 15:34]

Huh? Waarom heb je een videodriver nodig op een server? Althans, leek me dat Ubuntu is voor desktops en Debian voor services (jaja, er is ook Ubuntu server, maar die start dus ook zonder GUI ;-)
Ik heb jarenlang Debian Unstable op mijn desktop gedraaid. Werkte prima, maar je moest wat meer moeite doen om sommige zaken aan de praat te krijgen.
Om Oracle te installeren? Dat gaat via een GUI ;)
maar die GIU kun je redirecten naar een andere desktop :+

zo heb ik wel eens een oracle installatie gedaan via cygwin op mijn windows werkstation (het betere mcgyver-installeerwerk)
Je kunt natuurlijk ook Debian Linux als distro gebruiken en alsnog zelf de laatste kernel compilen van kernel.org.
2.6.35 is geen long term support kernel en 2.6.32 is dat wel. De vorige was 2.6.27. Linus wijst om de zoveel kernels een long term support kernel aan waar de komende tijd fixes in worden aangebracht.

Bij Lenny was helaas voor 2.6.26 gekozen en daar zaten redelijk wat consequenties aanvast. Je ziet bij andere distributies trouwens dezelfde keuze worden gemaakt en het heeft voornamelijk te maken met het volwassen worden van het platform. Daarbij zijn er wat dingen vanuit 2.6.33 zoals DRDB gebackport naar 2.6.32 in Squeeze om deze release wel commercieel aantrekkelijk te maken.

Het besef van long term support kernels is nog heel groot en je ziet sommige leveranciers gewoon 2.6.33 eisen. Deze bewustwording zal vanzelf komen zoals het eigenlijk altijd gebeurt. En misschien wel het belangrijkste is dat als je tegen zulke dingen aanloopt, dat je ook daadwerkelijk een bugreport instuurt om te kijken of het verholpen kan worden.
Dat betekent dat ze eerst gaan afwachten wat de 2.6.35 in praktijk voortbrengt en daarna zelf pas implementeren. De fouten komen pas boven als 2.6.35 een tijd in gebruik is door het grote publiek.
Wanneer stapt Debian over naar een FreeBSD kernel? Ze zouden dacht ik FreeBSD als standaard kernel kiezen en dan linux als optie...

[Reactie gewijzigd door Jack Flushell op 8 augustus 2010 14:54]

Er zijn meerdere subprojecten onder de Debian vlag en dit gaat over de Debian GNU/Linux versie. Er is bijvoorbeeld ook een Debian GNU/kFreeBSD (http://www.debian.org/ports/kfreebsd-gnu/) versie.

De linux versie zullen ze voorlopig echt niet zomaar opdoeken gezien de andere ports verre van af en bruikbaar zijn. Persoonlijk betwijfel ik of de andere ports ooit echt levensvatbare projecten worden.
Zelfs als ze bruikbaar zijn en levensvatbaar, zal voorlopig toch de Linux-versie de populairste Debian blijven. Naamsbekendheid speelt daarin een belangrijke rol.
Wel is het zo dat als bv de Hurd klaar zou zijn men zou kunnen profiteren van het niet hebben van het imago moeilijk te zijn.

Zelf hoop ik ook dat er meer mensen belangstelling krijgen voor ReactOS. In principe zou je daar vele voordelen kunnen hebben welke van de Linux en GNU-wereld af komen en toch de compatibiliteit hebben met de Windows applicaties die veel mensen wensen en waarom ze (meestal onterecht) niet op Linux willen overschakelen.

Wat mij betreft horen Windows, Mac, Linux, ReactOs, Haiku en xBSD (FreeBSD, OpenBSD en NetBSD, evt DragonflyBSD maar die mist dan weer de standaard GUI) gelijke marktaandelen op de desktop te hebben. (OpenSolaris is pasgeleden door Oracle hiervoor gediskwalificeerd) Elk heeft zijn eigen sterke en zwakke punten, al denk ik, dat als ReactOs zijn doel bereikt, Windows zelf geen bestaansrecht meer heeft. Die zouden dus mogen evolueren naar een vrije en een betaalde variant van hetzelfde OS, net zoals OO.o en StarOffice feitelijk bijna gelijk zijn, en WP8 linux ook in een gratis en een betaalde variant bestond.

[Reactie gewijzigd door BeosBeing op 12 augustus 2010 09:52]

http://www.debian.org/ports/kfreebsd-gnu/

Ik denk niet dat het de bedoeling is om Debian volledig te porten naar FreeBSD, maar gewoon een tweede versie van Debian op de FreeBSD kernel.

Kan zijn dat ik fout ben hoor.
Debian is een universeel besturing systeem. Daardoor is de Linux kernel Niet noodzakelijk. Het is de Debian userland op de kfreebsd kernel (de kernel van FreeBSD).
Waarom dan niet gelijk FreeBSD gebruiken?
Voor desktop-gebruik loop je tegen problemen aan zoals zeer slechte support voor Flash. Maar voor mijn servers gebruik ik het nog steeds.
Voordeel: Zit gestructureerder in elkaar dan Linux. Altijd de allernieuwste stable-versies, maar wel met de mogelijkheid om een oudere meer doorontwikkelde versie te kiezen (bijv. PHP 5.2 ipv. 5.3).
Flash support is redelijk goed in de laatste releases. Ik heb ik iig al een tijdje flash werkend in firefox op FreeBSD 8.1/i386 en amd64. ICM flashblock werkt dit prima.
Daar schijnen ze al tien jaar mee bezig te zijn. Maar je kan het al downloaden, in unstable. zie hier voor de voordelen.

Meer info hier
Linux en FreeBSD zijn 2 totaal verschillende besturingssystemen, ook al zijn ze beide unix-gebaseerd (4.2BSD en Minix uit m'n hoofd).

Je kan dus niet zomaar even een andere kernel kiezen. Hoewel software vaak compatible is.

-edit
ZIe net boven me dat er toch Debian FreeBSD projecten zijn, weer wat nieuws geleerd :)

[Reactie gewijzigd door Punica- op 8 augustus 2010 15:06]

Zie ook http://www.freebsd.org/do...paring-bsd-and-linux.html met uitleg over het verschil tussen Linux en BSD.
Debian Stable is servergrade. Ik denk dat alleen Slackware conservatiever is. Dat soort stabiliteit heeft geen enkele hobbyist nodig. Upgrade naar Testing en je hebt je modern OS. Upgrade naar Unstable en je het bleeding edge.
hangt er van af waar je als hobbyist mee bezig bent. Zelf heb ik op men servertje hier thuis ook gewoon de stable draaien, op men testsysteem draait op dit moment testing (omdat sommige software nieuwere versies van wat libs nodig had)
Ik heb juist als hobbyist debian stable draaien zodat ik daar in ieder geval niet naar om hoef te kijken. Af en toe updaten is genoeg om mijn homeserver draaiend en secure te houden. Zo kan ik lekker hobbyen met de services die erop draaien (LAMP) :)

Als je met het OS zelf wil hobbyen, gebruik je inderdaad een andere uitvoering ;)
Ik draai nu al meer dan een jaar Squeeze (Niet verwarren met SqueezeServer voor de SqueezeBoxen ...) op mijn QNAP NAS. Zie ook: Stille Zuinige Server topic

Ik ben uitermate tevreden met deze distro. Zijn er nu ook specifieke nadelen voor het gebruik van Debian als server OS? Ik kan, behalve dat de stable tak wat achter loopt, er zo geen een bedenken.
Ik ben uitermate tevreden met deze distro. Zijn er nu ook specifieke nadelen voor het gebruik van Debian als server OS? Ik kan, behalve dat de stable tak wat achter loopt, er zo geen een bedenken.
Daarom draait t.net ook op Debian...
En t-net draait ook op PHP, MySQL en nog wat andere dingen. t-net is absoluut geen goede referentie van een goed doordacht systeem. Het is iets wat gegroeid is en wat als mensen de keus (lees: veel geld) zouden hebben en opnieuw zouden bouwen waarschijnlijk compleet anders wordt neergezet.

Het draait op Debian omdat het draait op Debian. Net zoals het op MySql draait en PHP gebruikt. Maakt dat Windows met een .Net applicatie en MS SQL Server een slechte keuze voor een grote website?
Maakt dat Windows met een .Net applicatie en MS SQL Server een slechte keuze voor een grote website?
Ja vanwege de enorme overhead en beperkingen van het Microsoft OS. Een Linux machine kent simpelweg duizenden malen meer configuratieopties (vergelijk Apache bijv. maar met IIS, Bind met de brakke Microsoft DNS implementatie, etc), Linux is gratis en heeft een sloot aan beschikbare apps (Debian zelfs 18.000) die allemaal binnen handbereik liggen terwijl je je bij Windows vaak rotzoekt, Linux laat zich beter schalen in grote netwerken, Linux en UNIX hebben een veel hogere uptime dan Windows (99.98% is niet ongebruikelijk op onze servers) terwijl Linux breder wordt ingezet (meer functionaliteit) en Linux en UNIX behoeven heel weinig onderhoud. Onze FreeBSD mail server is maar 1 uur in het jaar down voor upgrades en wordt in z'n life-cycle van 3-4 jaar nooit gereboot.

Daarnaast biedt Linux gewoon praktische apps die je op Windows nooit terug zal vinden door het ontbreken van standaarden en tevens zijn er weinig goede gratis apps te vinden. Neem bijv een mixed network van Linux, UNIX en Windows. Hoe ga je daar FTP toegang voor je klanten voor verlenen zonder dat je met verschillende FTP servers en access databases moet gaan werken? Simpel, bijv. een *nix server waar Proftpd-mysql op draait en deze server kan op elk soort network share gemount worden. Onder Windows is dit een ramp. Tevens kunnen de Windows machines beheerd worden vanaf de Linux box. En zo kan ik nog wel 100 voorbeelden noemen waarom Windows ondergeschikt is voor web servers. Denk aan software en services zoals DNS, FTP, Radius, NTP, mail incl Spamassassin en anti virus (het gratis ClamAV), Asterisk PBX, Perl, Hylafax, etc.

Het is niet geheel zonder reden dat het absolute merendeel van de grote sites en alle belangrijke internet-gerelateerde services op Linux en UNIX draaien. Amerikaanse defensie draait op Debian, de Nederlandse belastingdienst op FreeBSD, XS4ALL draait op FreeBSD, etc.

Zou t.net op Windows en MS SQL draaien betekent dat ze veel meer hardware nodig hebben en dat ze een vermogen aan licenties kwijt zijn terwijl ze daar meer onderhoud en minder functionaliteit voor terug krijgen. Misschien kan een t.net techie dit toelichten?
Het draait op Debian omdat het draait op Debian.
Op zich een goede observatie, maar niet correct. Tweakers draaide vroeger namelijk Slackware en is overgestapt op Debian. Blijkbaar is dus ooit de keuze gevallen dat ze ergens anders heen wilden, en dat Debian voor hen de beste keuze leek :)
Ik werd een beetje gek van de Squeeze installer, op een gegeven moment krijg je een vraag (weet niet meer wat), en bevestiging daarvan geeft als resultaat installatie van Exim, omdat het een dependency blijkt te zijn van die vraag. Terwijl ik altijd niets installeer, dus ook geen Base system (waarmee dus ook ongevraagd Exim erop gezet wordt).

Dan wil je dus Postfix installeren maar moet je eerst Exim purgen, wat nooit helemaal lukt. Zal nog eens testen in VB met frozen Squeeze.

Verder gebruik ik al jaren Debian. Alleen stable, blijkt elke keer weer dat testing nog niet goed draait, of echt af is.

[Reactie gewijzigd door Vinzz op 8 augustus 2010 15:16]

Vinzz schreef:
Ik werd een beetje gek van de Squeeze installer, op een gegeven moment krijg je een vraag (weet niet meer wat), en bevestiging daarvan geeft als resultaat installatie van Exim, omdat het een dependency blijkt te zijn van die vraag. Terwijl ik altijd niets installeer, dus ook geen Base system (waarmee dus ook ongevraagd Exim erop gezet wordt).

Dan wil je dus Postfix installeren maar moet je eerst Exim purgen, wat nooit helemaal lukt. Zal nog eens testen in VB met frozen Squeeze.
Hmm, als ik een kale install doe met de squeeze installer, dan wordt idd exim geinstalleerd, maar ik kan exim (packages exim4, exim4-base, exim4-config, en exim4-daemon-light) zonder problemen verwijderen.

Overigens hoef je exim niet te verwijderen vrdat je postfix installeert; als ik aptitude install postfix doe, dan krijg ik de volgende melding:
The following packages have unmet dependencies:
exim4-config: Conflicts: postfix but 2.7.1-1 is to be installed.
postfix: Conflicts: mail-transport-agent which is a virtual package.
exim4-daemon-light: Conflicts: mail-transport-agent which is a virtual package.
The following actions will resolve these dependencies:

Remove the following packages:
1) exim4
2) exim4-base
3) exim4-config
4) exim4-daemon-light

Accept this solution? [Y/n/q/?]
Als ik daar Y antwoordt wordt exim verwijderd en postfix geinstalleerd. Je kunt dit ook expliciet maken door in het commando al aan te geven dat de exim4 packages weg moeten met aptitude install postfix+ exim4- exim4-base- exim4-config- exim4-daemon-light-.

Ook in de interactive mode van aptitude zijn die dingen aan te geven.
Alleen stable, blijkt elke keer weer dat testing nog niet goed draait, of echt af is.
Mja, goed, daar is het testing voor :)

[Reactie gewijzigd door deadinspace op 8 augustus 2010 19:25]

Het purgen van veel packages gaat bijna nooit perfect. Maw de toestand van voor installeren is zeker niet hersteld na purgen. Hier bied je dus geen oplossing voor.

Je laatste terloopse opmerking is een beetje in strijd met hetgeen hier beweerd wordt over hoe stabiel 'bleeding edge' en betrouwbaar Testing wel niet is.
Dan heb je een bug te pakken in de installer. Volgens de documentatie is purge: "this removes every file that is part of the package". Dus waar blijft die rommel dan staan? Hooguit in de debconf db en die is niet relevant voor het draaien van software.
Ben benieuwd waar je op doelt want ik gebruik Debian al meer dan 10 jaar en heb, buiten unstable om, nog nooit een probleem gehad met packages die 'rommel' achterlieten.
Heb je wel eens goed gezocht met locate (en elke keer na purgen updatedb gedraaid)?
Een dpkg --purge laat over het algemeen alleen staan wat gewijzigd is, in 99% van de gevallen dus wat er in /etc staat.

Een simpele rm -rf /etc/exim doet wonderen na een purge.
make that rm -rf /etc/*exim*
Zo heb ik een keertje rm -rf /etc <enter> gedaan op een Debian productiemachine toen ik aan de tel hing... ;)
Het sneller opstarten via insserv is eigenlijk redelijk simpel.
The insserv program is used to update the order of symlinks in /etc/rc?.d/ with sysv-rc based on dependencies specified in the scripts themselves using LSB init.d script headers.

This allow each package maintainer to specify their init.d script relation to other scripts and make it possible to detect and reject script dependency loops as well as making sure all scripts start in their intended order.

The program insserv in this package should be used with care and together with the sysv-rc package, as using it incorrectly can lead to an unbootable system.
Oftewel alle daemons geven keurig aan welke libraries/etc ze gebruiken en de relatie tot andere daemons, zodat deze in een snellere volgorde gestart kunnen worden, waarbij dus zoveel mogelijk dubbel werk voorkomen wordt.

[Reactie gewijzigd door Ron.IT op 8 augustus 2010 14:44]

Ht grote voordeel van Debian is dat je de apt-config zo kunt instellen dat je van bepaalde paketten "Stable" gebruikt, terwijl je andere pakketten uit de "Testing" of de "Unstable" repositories kunt halen.
Het kost even tijd, maar op die manier kun je je Debian helemaal naar eigen smaak en behoefte inrichten. Ubuntu is leuk voor de desktop, maar op mijn server komt toch echt niets anders dan Debian!
Ubuntu Server draait hier ook heerlijk. En da's niet voor de desktop. 10.04 LTS, zeer tevreden over.
Ik gebruik nu al ongeveer een jaar arch linux,, maar het is misschien wel weer een goed idee om debian te checken! Ik heb debian ook zo een 3 maanden gebruikt en ongeveer een jaar Ubuntu. Ik ga dan wel voor de unstable versie, is naar mijn ervaring stabiel genoeg :) of was squeeze unstable..
Alleen testing en stable veranderen van naam, Sid is de benaming van unstable en dat zal zo blijven. De huidige stable is Lenny en deze wordt opgevolgd door de huidige testing, Squeeze. Als je unstable draait moet je wel opletten bij updates, maar ik vermoed dat je dat wel gewend bent van Arch :).
ik zou unstable eens in een vm moeten proberen, benieuwd vraag me al lang af hoe onstabiel het eigenlijk is.
ik zou unstable eens in een vm moeten proberen, benieuwd vraag me al lang af hoe onstabiel het eigenlijk is.
Ik draai zelf al een jaar of 9-10 unstable op een handvol desktops, dus misschien dat ik daar wat over kan vertellen :)

Unstable is niet per se onstabiel in de zin van het crasht, maar meer in de zin van het verandert. "Turbulent" is misschien wel een mooie omschrijving.

Unstable is waar de nieuwe versies van packages (doorgaans) direct terecht komen; Een Debian maintainer maakt een nieuwe versie van een package, en upload dit naar unstable. Als in unstable blijkt dat er geen ernstige dingen mis zijn met het package, dan gaat het door naar testing.

Dit gaat aan de lopende band zo door, dus als je unstable wil volgen betekent dat regelmatig updaten (bijvoorbeeld elke dag). Het aantal updates is meestal ook vrij groot, op een uitgebreide desktop installatie kan het rustig rond de 100 per dag zijn.

Omdat unstable veel splinternieuwe software bevat kun je dus ook te maken krijgen met bugs in die software, zoals bijvoorbeeld de rhythmbox muziekspeler die crasht als je hem pauzeert met de ctrl-spatie shortcut (501944), de nautilus file manager die geen emblemen meer weergeeft op files (548143), of MySQL die een niet-getal returnt op een COUNT query (505179).

Waar je ook regelmatig mee te maken kunt krijgen zijn niet-werkende dependencies. Zo kan het wel eens voorkomen dat een nieuwe versie van een applicatie een nieuwe versie van een library nodig heeft, maar dat die nieuwe applicatie eerder in unstable zit dan die nieuwe library, zodat de applicatie niet te installeren is. Om die reden is het dan ook aan te raden om ook testing in je sources.list op te nemen als je unstable draait, zodat je de testing packages als fallback kunt gebruiken.

Maar unstable draaien is ook leuk :)
Als je regelmatig update, dan zie je nieuwe versies van programma's, je ziet nieuwe features, je ziet veranderingen waar je blij mee bent, en veranderingen waar je minder blij mee bent. Bugs die geintroduceerd worden en weer opgelost worden.

Nu squeeze frozen is zal unstable trouwens wel achter gaan lopen. Unstable is dan wel testgebied voor nieuwe packages, maar het is testgebied voor packages die (uiteindelijk) in stable moeten komen. En met een release in zicht ligt de nadruk op het klaarkrijgen van packages voor de volgende release, niet op nieuw speelgoed.

Dat betekent ook dat unstable overspoeld zal worden met nieuwe packages na de release van squeeze (eindelijk mogen ze weer!), dat is altijd een leuk (zowel leuk! als "leuk..." ;)) moment om unstable te draaien :P

Maar unstable kan soms ook ernstigere bugs met zich meebrengen. Zo was pam een keer stuk (204711), waardoor je niet meer kon inloggen. Als je dat wil repareren (en je bent niet meer ingelogd) moet je rebooten in single user mode.
Ook kan ik me nog een incident herinneren waar libc6 kapot was waardoor vrijwel niks meer werkte (inclusief booten). Om dat te repareren moest je booten in single user mode met een statically linked shell (als je die had) of van een CD-ROM oid. Verder moet je dan ook weten hoe je de juiste libc6 bestanden repareert, want zonder werkende dpkg is het installeren van een wel-werkende libc6 ook nog een uitdaging.

Vanwege dat soort dingen is het sterk af te raden om unstable te gebruiken voor belangrijke taken. De kans dat op een gegeven moment iets niet lekker werkt is groot. De kans dat je systeem ernstig de soep in draait is klein, maar wel aanwezig.

Zie ook deze Debian sid FAQ :)

[Reactie gewijzigd door deadinspace op 9 augustus 2010 23:24]

Thanx. Een van de zeer, zeer weinige posts die +3 krijgt van mij.
Informatief, toevoegend , on-topic en leuk geschreven. Een must-read.
Zelfs een post wijd ik eraan, vrij onzinnig, maar ik wilde je even bedanken :*)

[Reactie gewijzigd door Jack Flushell op 9 augustus 2010 22:38]

ik draai Debian Unstable en het werkt best als desktop. Het komt echter wel eens voor dat er een update komt die iets niet laat werken, wat frustrerend kan zijn.
SID staat voor Still in Development ;)
SID staat voor Still in Development ;)
Tikje off-topic, maar dat klopt niet helemaal.

Alle Debian codenames zijn namen van karakters uit de Toy Story film. In die film was Sid de vervelende buurjongen die het leuk vindt speelgoed te martelen en slopen, wat natuurlijk symbolisch is voor Debian unstable :)

Dat de eerste letters van "still in development" ook "sid" zijn is extra leuk, maar het is vooral toeval, want dat is niet waar de letters voor staan. Het is hooguit een backronym.

Zie ook deze Debian sid FAQ.

[Reactie gewijzigd door deadinspace op 9 augustus 2010 00:15]

kan daar maar 1 ding op zeggen:

I was frozen today!!

http://www.youtube.com/watch?v=nC8zz95rm8s
Leg eens uit, ik ben benieuwd waarom dat het geval zou zijn.

Ps. Ik ben geen kenner, mij kun je een hoop wijsmaken. Kom dus met argumenten, daar kan ik wat mee.
Ik ben het niet eens met Jeffer. Ubuntu is inderdaad gebaseerd op debian, maar is, zoals gezegd, veel meer bleeding edge. Bij beveiliging is het vaak wenselijk om een systeem te gebruiken wat zichzelf al heeft bewezen, en juist niet met de latest and greatest aan de slag te slaan. Daarin zitten immers vaak meer bugs.

Uiteraard is Ubuntu server een stuk minder kwetsbaarder dan Ubuntu desktop simpelweg omdat het minder pakketten heeft.
Precies. Bleeding edge betekent niet dat het veiliger is. Er is veel meer kans dat er bugs in zitten die nog niemand heeft gevonden en die te gebruiken om te exploiten.
was niet bedoelt om te stangen hoor...

bedenk dit:
debian stable heeft up to date security fixes.
maar wel oude software...

als je dus de oude software compiled of update....heb je geen goeie security fixes...ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.

tada probleem uitgelegd.
of dit in de praktijk onveiliger is ligt aan je systeembeheerder natuurlijk.

google maar eens naar ditsoort problemen.
dit is de reden dat ik op mijn servers ubuntu draai en niet meer debain.
Jeffer schreef:
bedenk dit:
debian stable heeft up to date security fixes.
maar wel oude software...

als je dus de oude software compiled of update....heb je geen goeie security fixes...
Ik denk dat je het een en ander verkeerd begrijpt (al is me niet helemaal duidelijk hoe jij het ziet), dus ik zal uitleggen hoe Debian security updates doet.

Als een security issue gevonden wordt in een stuk software, dan brengt Debian daar een security update voor uit. Wat bij een groot aantal andere OSen gebeurt is dat dan de nieuwste versie van die software (waarin ook het security probleem gefixt is) geinstalleerd wordt als security update. Maar die nieuwste versie brengt over het algemeen ook andere veranderingen met zich mee; nieuwe features misschien, subtiel veranderd gedrag misschien, andere performance, nieuwe bugs, etc.

Dat is onwenselijk. Debian stable is stable, wat naast "niet crashen" ook inhoudt "niet veranderen". Mensen die Debian stable geinstalleerd hebben hebben een werkend systeem en willen dat graag zo houden, ook na een security update. Daarom worden security fixes door het Debian security team gebackport naar de software-versie in Debian.

Zie ook deze vraag uit de Debian security FAQ:
Q: Why are you fiddling with an old version of that package?

The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. This is especially true in case of libraries: make sure you never change the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is.

This means that moving to a new upstream version is not a good solution, instead the relevant changes should be backported. Generally upstream maintainers are willing to help if needed, if not the Debian security team might be able to help.

In some cases it is not possible to backport a security fix, for example when large amounts of source code need to be modified or rewritten. If that happens it might be necessary to move to a new upstream version, but this has to be coordinated with the security team beforehand.
--
ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.
Debian brengt voor ieder probleem afzonderlijk een security update uit.

Als voorbeeld, in februari dit jaar werd een denial of service vulnerability in lighttpd gevonden. Debian bracht daarvoor Debian Security Advisory 1987 uit.

Vr deze DSA was de lighttpd versie in Debian 1.4.19 (Debian version 1.4.19-4), en na de DSA was de lighttpd versie in Debian nog steeds 1.4.19, maar dan met de security fix (Debian version 1.4.19-5+lenny1). Het lighttpd project zelf bracht versie 1.4.26 uit voor deze security fix, maar Debian heeft de fix gebackport naar 1.4.19.

Zie http://www.debian.org/security/ voor meer informatie (inclusief links naar de Debian security FAQ, en naar lijsten met DSAs).

Overigens zei je ook nog wat over zelf software compilen:
als je dus de oude software compiled of update....heb je geen goeie security fixes...
Als je zelf software compiled, dan ben jij zelf verantwoordelijk voor het updaten daarvan als security problemen worden gevonden. Dat geldt als je Debian draait, dat geldt als je Ubuntu draait, en dat geldt als je welk ander OS dan ook draait.
google maar eens naar ditsoort problemen.
Eh, nee. Geef jij maar eens een concrete link.

Met de vage beweringen die jij doet, gevolgd door "google maar eens" kunnen wij niks. Je zegt heel weinig concreets, dus mensen kunnen ook niet uitleggen waarom ze het niet met je eens zijn. Dus google zelf maar, en post dan hier de links naar concrete voorbeelden die je vindt.
dit is de reden dat ik op mijn servers ubuntu draai en niet meer debain.
En die reden vindt dus geen aarding in de realiteit. Realiseer je je dat Ubuntu dezelfde aanpak hanteert voor security updates als Debian? :Y)

[Reactie gewijzigd door deadinspace op 8 augustus 2010 18:20]

Het grote probleem van backports is natuurlijk dat ze pas na de originele fix gemaakt kunnen worden. Ook is het niet altijd zo dat de fix voor een current versie 1 op 1 te gebruiken is in een oudere versie. Tot slot zijn de mensen die bij Debian de backports doen niet automatisch de mensen die voor de originele packages verantwoordelijk zijn. Er is dus een reel gevaar dat bij de backport iets gemist wordt waardoor er een kwetsbaarheid blijft in de backport die niet (meer) aanwezig is in de current release.

Het is qua veiligheid (wat niet hetzelfde is als stabiliteit) dus aan te raden een versie te gebruiken die actief beheerd wordt door de developers van een software project.
Oude software zit overal en boeit totaal niet. Het gaat erom of de software wordt onderhouden en getest is. Sommige onderdelen van bepaalde besturingssystemen gaan 30 a 40 jaar terug en het maakt ze totaal niet onveiliger. Een developer brengt misschien een a twee updates per jaar uit vanwege een vertaling of een verzoek tot een nieuwe optie.

Dit is ook een van de klachten van bedrijven tov FOSS en ook een terechte klacht imho. Want pak nu eens Solaris 8 bv wat in 2000 uitkwam en nog steeds veilig en goed te gebruiken is. Veel bedrijven zeggen het vaarwel met veel moeite, omdat de leverancier de ondersteuning officieel sluit in 2012.

De strategie van het laatste is het beste komt misschien wel bij Solaris 10 het beste naar voren. Het OS is zo innovatief als het maar zijn kan, maar betaalt daar ook een prijs voor en als je naar de patches en updates kijkt dan zie je ook bewust waar. In de gebieden waar veel veranderingen zijn geweest of die relatief nieuw zijn. Veel code is gewoon te vroeg los gelaten of te vroeg gemporteerd in de distributie.

Als je het breder trekt dan zie je een redelijke relatie tussen de volwassenheid van het project, de developers, de codebase en de hoeveelheid updates. Met misschien wel Postfix en PostgreSQL als uitschieters in hoe kan worden omgegaan software development. Homeland Security doet veel onderzoek naar dit en de lijst met "veilige" software is kort, maar de relatie tussen leeftijd van het project en het development proces is opmerkelijk.

Dit is trouwens ook waar de Linux Standard Base een beetje in beeld kwam jaren geleden. Bepaalde curciale componenten vast pinnen dat die er zijn en welke functionaliteit je mocht verwachten. En je ziet dit ook nu komen in oa GNOME waarbij ze elke vijf jaar de mogelijkheid willen creeeren om de API en basis dependencies aan te passen.

Het geeft een bepaalde rust voor developers en gebruikers dan niet alles elke keer stuk gaat. Je ziet dit ook terugkomen in waarom Ubuntu LTS best populair kan zijn bij sommige gebruikersgroepen, zoals de gene die gewoon een computer willen gebruiken als waar dat ding voor bedoelt is. Zeker omdat een keer in de twee jaar een herinstallatie te doen best goed te verkopen is ipv elke 6 maanden upgraden. Je ziet hier distributies ook langzaam op inspelen, want sommige releases worden langzaam opgerekt naar acht maanden en het is wachten totdat ze langzaam aan op een jaar zitten. Iets wat heel goed te verkopen is aan normale gebruikers met een AMD Fusion, Intel Atom of Ion machine.

Hier zie je ook langzaam het probleem komen waar Microsoft jaren geleden tegenaan liep. Je bent opeens door de functionaliteit heen die je kan implementeren en ga je beginnen met het optimaliseren. En wees nu eerlijk, wat is er nu zo belangrijk geweest wat je direct op je machine moest hebben sinds zeg 2001? Zelfs de laatste belofte van HTML5 mis je de komende 18 tot 24 maanden nog niets aan.

Het allerlaatste op je machine is misschien leuk, maar vaak niets meer dan een plaswedstrijd van kleine kinderen in de sneeuw. Tijd kan beter wordt besteed aan bv het automatisch testen van software en beheersbare incrementele wijzigingen aan te brengen of grote wijzigingen goed voor te bereiden zoals GNOME nu al sinds 2007 doet voor GNOME 3. Dit geldt ook voor mensen die software inzetten, want elke keer een testcircus is niet grappig en kost veel geld en tijd.

Is de laatste software daadwerkelijk veiliger dan de vorige versie? Ik durf het te betwijfelen en hier zie je dat sommige marketing machines goed hun werk hebben gedaan. Het is misschien verstandiger om te gaan focussen op het daadwerkelijke development proces, want dat kan je vertellen wat je mag gaan verwachten en niet wat je hoopt te gaan aantreffen.
bedenk dit:
debian stable heeft up to date security fixes.
maar wel oude software...
Dat is dus veilig, waarom zou Debian dan onveiliger zijn dan Ubuntu?
als je dus de oude software compiled of update....heb je geen goeie security fixes...ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.
Je zegt net "debian stable heeft up to date security fixes." waarom is het dan nu ineens niet goed? Daarnaast heeft Ubuntu geen wekelijkse updates, dat zou het beheren van Ubuntu servers ook veel te kostbaar maken: Iedere week opnieuw updates installeren? Die is gek, dat doet geen enkele beheerder.
tada probleem uitgelegd.
Het zal aan mij liggen, maar volgens mij leg je helemaal niets uit.
of dit in de praktijk onveiliger is ligt aan je systeembeheerder natuurlijk.
Het is altijd de beheerder die het beleid bepaalt voor zijn servers.
google maar eens naar ditsoort problemen.
Klinkt mij in de oren alsof jij het eigenlijk ook niet weet, je legt hier al niets uit.
dit is de reden dat ik op mijn servers ubuntu draai en niet meer debain.
Wat is nu de reden? Ik zie geen uitleg, alleen wat aannames van jouw kant.

En nogmaals, ik gebruik Ubuntu maar ik zou niet weten waarom dit veiliger zou zijn dan Debian.
als je dus de oude software compiled of update....heb je geen goeie security fixes...ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.

Je zegt net "debian stable heeft up to date security fixes." waarom is het dan nu ineens niet goed?


lees dit dan nog eens 4x, misschien dat je het dan snapt.
Je redenatie "ze hebben meer security updates, dus is het veiliger" lijkt me niet volledig valide. Je beantwoordt de vraag waarom ze meer security updates hebben niet. Je neemt aan, dat ze dat doen omdat ze er meer op zitten. Voor hetzelfde geld moet ubuntu meer security releases doen omdat er meer bugs in de "releases" zit, die er bij Debian uitgehaald worden, omdat Debian stable af is als het af is.

Verder heeft Debian volgens mij een vrij goede reputatie op security gebied, en vrij proactieve securitymensen. Lees hier wat ze er zelf over zeggen: http://www.debian.org/security/. Verder neem ik aan dat, als beheerder, je natuurlijk geabonneerd bent op http://lists.debian.org/debian-security-announce/.
Debian speelt op gebied van veiligheid net heel kort op de bal. Stabiliteit en veiligheid zijn voor Debian topprioriteiten en dat maakt van Debian net n van de meest gelievde distros bij sysadmins.

En in Debian 6 word het zelfs nog eenvoudiger om up to date te blijven. Telkens je inlogt krijg je mooi een melding van het aantal updates dat beschikbaar is voor je systeem.

Op de mailing list zie je trouwens dat Debian dit jaar reeds 136 security updates heeft uitgebracht. Dat is meer dan 1 om de 2 dagen. Vorig jaar waren het er 290.
Juist de debian bugfixes zijn veel veiliger dan de laatste releases. Bij Debian krijg je alleen de bugfixes, terwijl je bij Ubuntu ook nieuwe functionaliteit kunt krijgen.

Daarbij vind ik software juist instabiel als ze zeer regelmatig updates krijgen, met uitzondering van anti-virus en anti-spam software. Dat zijn dan ook de enigste pakketten waarvan ik via backports.org de 'laatste' versies draai.

Daarbij heb ik liever een distributie welke pas een stable release doet als testing als stabiel kan worden beschouwd, dan dat men een bepaalde datum in gedachte moet houden. De volgende Ubuntu update is 10.10. En wat doet Ubuntu als men in oktober nog steeds dagelijks bugs krijgt aangemeld voor 10.10? Stellen zij dan de release uit?

Bij Suse hebben we zelfs een keer een PHP update (ruim 8 jaar geleden) gekregen welke voor breaking change zorgde en ineens werken 30 websites dan niet meer.Men had toen besloten register_globals standaard op off te zetten. Ik weet het, niet netjes van de devvers. Iedereen in paniek, mensen verkondigen het einde van de wereld, de paus roept dat het een straf van god is en Murhpy ligt dubbel van het lachen..
Overigens ging het ook fout bij Slackware. Alleen de websites welke op Debian draaide bleven zonder problemen werken.

Na deze issue zijn we servers gaan standaardiseren op Debian. Daarvoor had elke beheerder zijn eigen 'favoriet'.
Ik heb het geprobeerd 4x te lezen, maar debian backport security fixes als dat nodig is en ik krijg eens in de zoveel dagen netjes een mailtje als er weer een update is voor een lek.

Overigens kun je met iets oudere software met security patches ook een zeer veilig systeem hebben. Geen enkele reden dat je daarvoor bleeding edge nodig hebt.
Kortom, je weet het zelf ook niet, je kunt het in elk geval niet uitleggen.
Ik hoef niet te googlen hoor ;) heb zelf ervaring met Ubuntu en debian en in mijn ervaring is debian toch net wat stabieler dan ubuntu. Bij ubuntu had ik nog weleens bugs en driver problemen :).

En het ligt natuurlijk geheel aan de situatie waarin je de OS hebt draaien of het veilig is of niet :D
als je dus de oude software compiled of update....heb je geen goeie security fixes...ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.

tada probleem uitgelegd.
Niet echt. Als jij de deb sources van de Debian site download omdat je bijv. een stukje software met custom flags wilt compileren, zitten de Debian patches en security fixes daar al in verwerkt.

En dan is er natuurlijk nog de security repository van Debian met de laatste updates:
deb http://security.debian.org/ stable/updates main contrib non-free
ubuntu brent bijna wekelijks een nieuwe security update uit...debian doet dit niet.
Aperte nonsens. Als er noodzaak is voor een fix dan komt 'ie er.
Bij beveiliging wil je dat de security patches up to date zijn. Wat gebeurd er als een probleem gevonden wordt. Er wordt een nieuwe versie gemaakt die het probleem verhelpt. Die oplossing wordt daarna ook in oudere pakketen verwerkt. Qua beveiliging maakt het dus vrij weinig uit. Het oudere pakket (met backports) is dus net zo veilig als de nieuwste versie en problemen met de beveiligingsupdates komen dus zowel in de nieuwe release als de backports terecht. Het draaien van een versie zonder backports is principieel onveilig.

Het grote verschil tussen "the latest and greatest" versie en oudere versies is dat er functionaliteit ontbreekt die misschien in nieuwere versies voor bugs kan zorgen. Functionaliteit die je niet hebt kan natuurlijk niet misbruikt worden. Tegelijkertijd is moderne software beter bestand tegen misbruik dan oudere pakketen en wordt er veel meer nadruk gelegd op beveiliging dan zeg 10 jaar terug. Uiteindelijk moet je een keuze maken tussen features, stabiliteit, prijs en snelheid. Maar oud is (net als nieuw) niet altijd de beste keus.
Hier ben ik ook wel eens benieuwd naar... zeker omdat ubuntu gebasseerd is op Debian.
Iedere Ubuntu release begint met de export van de status van Debian Unstable op dat moment waarbij bepaalde pakketten vervangen of toegevoegd worden door het ubuntu team. Maar de onderliggende basis is gewoon een snapshot van Debian Unstable van een aantal maanden voor de release.
Maar de onderliggende basis is gewoon een snapshot van Debian Unstable van een aantal maanden voor de release.
Niet voor de 'stable' serverversie. Die is zelfs nog conservatiever dan Debian stable en lastiger te upgraden als de support wegvalt.
Niet voor de 'stable' serverversie. Die is zelfs nog conservatiever dan Debian stable en lastiger te upgraden als de support wegvalt.
Voorzover ik weet is elke Ubuntu release gebaseerd op een snapshot van Debian Unstable, ook de LTS versies.

Niet dat dat erg hoeft te zijn; in feite zijn de Debian releases ook gebaseerd op een snapshot van Debian Unstable (ok, via Debian Testing, maar toch). ;)

edit:
Ik kwam nog deze aardige blog post tegen over waarom Ubuntu op Debian unstable gebaseerd is.

edit2:
Hmm, je hebt gelijk WOteB2, dat wist ik niet. Het was trouwens leuk als je een bron gegeven had (ik heb de bevestiging gevonden op https://wiki.ubuntu.com/LTS) ;)

[Reactie gewijzigd door deadinspace op 9 augustus 2010 09:33]

Voorzover ik weet is elke Ubuntu release gebaseerd op een snapshot van Debian Unstable, ook de LTS versies.
Dat geldt voor de tussenliggende versies. De LTS versies starten vanaf de dan werkende Testing versie van Debian, dus stabieler dan de tussenversies.
Hoe kom je hierbij? Ubuntu heeft een LTS, maar dat is long time support en niet long time stable (http://en.wikipedia.org/w...rating_system%29#Releases). Die wordt gebaseerd op Debian testing en staat onder dezelfde releasecycledruk als andere Ubuntu releases. Ik ben dan ook benieuwd waar jij op baseert dat deze conservatiever is dan Debian stable?
Dat vind ik een hele interessante statement :) Leg ons eens uit SVP.

Debian is voor m.n. het gebruik op servers een veel betere keuze vanwege juist minder bugs, meer mirrors, meer mirrors met nightly builds en meer experimentele installers als net die ene driver/module voor die nieuwe controller niet bij de standaard kernel zit.

Vorig jaar nog ruim 80 VMs en 18 hosts van een klant uit New Mexico/US voorzien van Debian ipv Ubuntu en enkele CentOS installaties omdat we veel problemen hadden met SCSI drivers en voor een update van die drivers ook een update van de kernel en een laag van het OS waaronder udev nodig was. Ook de iSCSI implementatie van Ubuntu zat vol met bugs en was onbruikbaar.

Ubuntu is het perfecte binary OS voor desktops, Debian en CentOS voor servers, Gentoo is het beste Linux source OS, ideaal voor bijv. Asterisk of een dedicated mail server.
nightly builds en servers in 1 zin.... :X

Wat je op een server wilt is iets stabiels, wat ondersteund wordt en geen experimenten vereist. Dat zijn precies de kenmerken waarom Red Hat en Suse populair zijn ondanks dat het geld kost. Debian stable gebruikt in mijn ogen gewoon te oude pakketen.
nightly builds en servers in 1 zin.... :X

Wat je op een server wilt is iets stabiels, wat ondersteund wordt en geen experimenten vereist.
Waarom gaat volgens jou een nightly build gepaard met experimenteren? Debian biedt ook nightly builds aan waar alleen de installatieprocedure current is of waar extra drivers aan de kernel zijn toegevoegd zodat je zonder problemen bijv. de allernieuwste SCSI controller kunt gebruiken. Userland is gewoon hetzelfde dus niks instabiels aan en experimenteren is niet nodig tenzij je niet weet waar je mee bezig bent.

Is toch alleen maar mooi dat Debian de gebruiker zoveel vrijheid geeft?
draai hier bijna 80vm's onder ubuntu met kvm...zonder problemen.
Want jij hebt Debian 'gehackt', en jouw bevindingen daar is het dev team reeds van op de hoogte.

Maw, doe je eerste stelling nog even uit de doeken.
Omdat je eisen lager liggen. Wij draaien 80 VMs op enkele HP blades en Dell servers met databases van meer dan 8 miljard records per tabel, met in-house ontwikkelde software geschreven in JAVA voor een hotel-reserveringssysteem dat wereldwijd gebruikt wordt. http://www.innpointsworldwide.com/

Als je het maximale uit je serverpark moet halen, loop je al snel tegen beperkingen en bugs aan.
Altijd handig om te stellen dat "eisen lager liggen" zonder te weten wat die eisen zijn. 8 miljard records klikt heel veel maar dat is alleen maar opslag. Zegt niets over het aantal transacties per seconde... En het geeft al helemaal niets aan over het OS. Jou applicatie kan ik zo op Windows, OSX Solaris of elke ander OS draaien. Het is JAVA en leest uit een database....

Een Java database applicatie vereist niet echt veel van het OS en zegt al helemaal niets over de veiligheid van dat OS.
En het geeft al helemaal niets aan over het OS. Jou applicatie kan ik zo op Windows, OSX Solaris of elke ander OS draaien. Het is JAVA en leest uit een database....
Windows draait voor geen meter op een VM met 1 beschikbare CPU core van 2-2,5GHZ en 1,5GB geheugen terwijl een Linux VM client hier genoeg aan heeft voor het draaien van een grote MySQL database met 1,5 miljoen transacties/dag.

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