Nästa version av Debian stöder ZFS

Permalänk
Avstängd

Nästa version av Debian stöder ZFS

Permalänk
Medlem

Så nu kan vi skrota Solaris för gått

Permalänk
Medlem
Skrivet av Meto:

Så nu kan vi skrota Solaris för gått

Och inte tala om ubuntu

Permalänk
Medlem

Även om Debian är den dist som ligger mig varmast om mitt hjärta så får man inte glömma bort Debian GNU/kFreeBSD.

Permalänk
Medlem

Detta gäller väl däremot enbart Debian GNU/kFreeBSD? I artikelen verkar källan vara felciterad. Från artikeln:

Citat:

This means that Debian will become one of the first GNU/Linux distributions to support the filesystem, according to developer Robert Millan.

Från bloggen:

Citat:

Debian Squeeze will be one of the first GNU distributions to support ZFS.

I vilket fall som hellst, trevliga nyheter.

Permalänk
Medlem

Inte för att jag orkar "googla" på det men jag undrar då iallafall vilka de andra distarna är som får stöd för ZFS så tidigt.
"... will be one of the first..."

Jaja, det ger sig väl med tiden.

Permalänk
Medlem

Inga linux distar får stöd för ZFS. Inte ens debian med linux kärnan. Däremot finns debian med bsd kärnan och det är DEN som får zfs snart

Permalänk
Medlem

Frågan man ställer sig är varför man skulle vilja använda Debian GNU/kFreeBSD istället för FreeBSD eller Debian GNU/Linux?
Debians eget svar på frågan: Debian_GNU/kFreeBSD_why - Debian Wiki

Personligen föredrar jag att köra FreeBSD "på riktigt". Men Debian ser ut att vara ett intressant alternativ. Inte ens FreeBSD har ju stöd för ZFS i installationsprogrammet så det är välkommet om Debian gör så att man kan installera direkt på ZFS med hjälp av installationsprogrammet.

Undrar om man kan köra Debian GNU/kFreeBSD i ett jail på FreeBSD? Eller tvärtom, FreeBSD i ett jail på Debian GNU/kFreeBSD?
EDIT: Någon tänkte på detta redan år 2007: phaq Blog Archive Debian GNU/kFreeBSD inside native FreeBSD jail

Permalänk
Medlem
Skrivet av =JoNaZ=:

Inga linux distar får stöd för ZFS. Inte ens debian med linux kärnan. Däremot finns debian med bsd kärnan och det är DEN som får zfs snart

Det finns en ZFS-modul till linux-kärnan som är under utveckling (läs mer). Hur debian kommer implementera ZFS vet jag inte, men det finns redan nu möjlighet att använda ZFS i t.ex. Ubuntu 10.4 eller Fedora 12. Däremot så är det väl bara i något slags beta-stadie än så länge, även om det verkar fullt användbart.

Permalänk
Avstängd
Skrivet av Meto:

Så nu kan vi skrota Solaris för gått

Solaris har ju andra fördelar än bara ZFS, över Linux som har erkänt dåligt kod.

Ett axplock.

T.ex. lider Solaris inte av sånt här:
milek's blog: Linux, O_SYNC and Write Barriers
"This is really scary. I wonder how many developers knew about it especially when coding for Linux when data safety was paramount. Sometimes it feels that some Linux developers are coding to win benchmarks and do not necessarily care about data safety, correctness and standards like POSIX. What is even worse is that some of them don't even bother to tell you about it in official documentation (at least the O_SYNC/O_DSYNC issue is documented in the man page now)."

Eller sånt som overcommit av RAM. Linux ger ut mer RAM än som finns, till alla processer. När RAM börjar ta slut, så dödar Linux processer på måfå. Tänk om du kört ett jobb länge och så dödas det? Solaris ger inte ut mer RAM än vad som finns, så Solaris lider inte av detta problem att helt plötsligt kan processer dödas vilt. Vilket får folk att tro att det är buggar i olika program.

Permalänk
Medlem
Skrivet av saddam:

Eller sånt som overcommit av RAM. Linux ger ut mer RAM än som finns, till alla processer. När RAM börjar ta slut, så dödar Linux processer på måfå. Tänk om du kört ett jobb länge och så dödas det? Solaris ger inte ut mer RAM än vad som finns, så Solaris lider inte av detta problem att helt plötsligt kan processer dödas vilt. Vilket får folk att tro att det är buggar i olika program.

Linux dödar inte processer på måfå, utan använder en algoritm (läs mer) som rangordnar processer och försöker döda de processer som är minst viktiga och som använder mest minne. Detta görs när allt virtuellt minne är slut och det inte finns något annat att göra. Ett jobb som kört länge är alltså mer sannolikt att kunna fortsätta om minnet tar slut i Linux än i Solaris, eftersom jobb som kört länge är mer sannolika att vara viktiga än jobb som precis startat. Det går också att göra processer immuna mot att dödas när minnet tar slut om man vill.

Vad som händer i Solaris när allt minne tar slut vet jag inte, men av erfarenhet så vet jag att få program faktiskt kontrollerar om det går att allokera mer minne eller inte, och helt enkelt kraschar om de inte får mer minne när de ber om det. Vilket sätt som är bäst beror nog på situationen, så jag skulle inte säga att Solaris sätt att hantera det på är bättre än Linux, eller tvärtom.

Permalänk
Medlem

Fast Debian med ZFS använder ju inte Linuxkärnan, det är FreeBSD-kärnan som används.

Problemet som nämndes i bloggen verkade ju vara löst i nyare Linuxkärnor (2.31 är ganska gammal). Det där med RAM overcommit var nytt för mig. Borde inte detta ha märkts av mera om det var ett problem?
Är det detta: Linux Kernel Documentation :: vm : overcommit-accounting
I så fall verkar det gå att stänga av om man så önskar.

1 The Linux kernel supports the following overcommit handling modes 2 3 0 - Heuristic overcommit handling. Obvious overcommits of 4 address space are refused. Used for a typical system. It 5 ensures a seriously wild allocation fails while allowing 6 overcommit to reduce swap usage. root is allowed to 7 allocate slighly more memory in this mode. This is the 8 default. 9 10 1 - Always overcommit. Appropriate for some scientific 11 applications. 12 13 2 - Don't overcommit. The total address space commit 14 for the system is not permitted to exceed swap + a 15 configurable percentage (default is 50) of physical RAM. 16 Depending on the percentage you use, in most situations 17 this means a process will not be killed while accessing 18 pages but will receive errors on memory allocation as 19 appropriate.

Permalänk
Avstängd
Skrivet av perost:

Linux dödar inte processer på måfå, utan använder en algoritm (läs mer) som rangordnar processer och försöker döda de processer som är minst viktiga och som använder mest minne. Detta görs när allt virtuellt minne är slut och det inte finns något annat att göra. Ett jobb som kört länge är alltså mer sannolikt att kunna fortsätta om minnet tar slut i Linux än i Solaris, eftersom jobb som kört länge är mer sannolika att vara viktiga än jobb som precis startat. Det går också att göra processer immuna mot att dödas när minnet tar slut om man vill.

Vad som händer i Solaris när allt minne tar slut vet jag inte, men av erfarenhet så vet jag att få program faktiskt kontrollerar om det går att allokera mer minne eller inte, och helt enkelt kraschar om de inte får mer minne när de ber om det. Vilket sätt som är bäst beror nog på situationen, så jag skulle inte säga att Solaris sätt att hantera det på är bättre än Linux, eller tvärtom.

Här finns mera information och länkar om Linux RAM overcommit. Han pratar även om OpenSolaris och att det inte overcommittar RAM, istället failar OpenSolaris - delar inte ut mer RAM.
Ops Monkey: Linux memory overcommit

Det kanske verkar som att man kan slå av Linux RAM overcommit, enligt era länkar. Men är det inte per default att Linux alltid overcommitar? Och, i Linux v2.4 så verkar det alltid vara RAM overcommit, det går inte att slå av. RedHat kör väl bara v2.4 har jag förstått - så RedHat overcommitar RAM alltid (ifall de inte ändrat i v2.4 kärnan).

I vilket fall som helst, det finns en hel del brister i Linux, andra än att det saknar ett vettigt filsystem. Visst finns det brister i Solaris också, men Solaris har andra fördelar än att bara ha ZFS.

Permalänk
Medlem
Skrivet av saddam:

Eller sånt som overcommit av RAM. Linux ger ut mer RAM än som finns, till alla processer. När RAM börjar ta slut, så dödar Linux processer på måfå. Tänk om du kört ett jobb länge och så dödas det? Solaris ger inte ut mer RAM än vad som finns, så Solaris lider inte av detta problem att helt plötsligt kan processer dödas vilt. Vilket får folk att tro att det är buggar i olika program.

Fast det gör väl alla moderna OS med stöd för virtuellt minne? Det är ju det som är hela poängen. Under Windows har ju t.ex. alla 32bit-program som standard 2GB workspace, har du då 30 processer igång så har programmen i teorin tillgång till 60GB RAM. Att sen detta virtuella minne ligger på disk, i delade bibliotek, RAM eller inte används alls har ju egentligen mindre betydelse. Eller är det något annat du syftar på?

Permalänk
Medlem
Skrivet av saddam:

Här finns mera information och länkar om Linux RAM overcommit. Han pratar även om OpenSolaris och att det inte overcommittar RAM, istället failar OpenSolaris - delar inte ut mer RAM.
Ops Monkey: Linux memory overcommit

Det kanske verkar som att man kan slå av Linux RAM overcommit, enligt era länkar. Men är det inte per default att Linux alltid overcommitar? Och, i Linux v2.4 så verkar det alltid vara RAM overcommit, det går inte att slå av. RedHat kör väl bara v2.4 har jag förstått - så RedHat overcommitar RAM alltid (ifall de inte ändrat i v2.4 kärnan).

Red Hat delades upp i Red Hat Enterprise Linux (RHEL) och Fedora 2003, och både RHEL och Fedora har använt Linux v2.6 i över 5 år nu. Det finns säkert någon obskyr distro som fortfarande använder v2.4, men t.om. Slackware har ju kört v2.6 i flera år nu.

Och som sagt, det är inte uppenbart vilken strategi som är bäst. I Solaris så kommer förmodligen en slumpmässig process att krascha när minnet tar slut, eftersom programmerare nästan aldrig kontrollerar att t.ex. malloc inte returnerar en NULL-pekare. I Linux så dödas istället en process som kärnan tycker är "oviktig", och "viktiga" processer har en chans att klara sig.

Om du t.ex. har någon process som kört länge och plötsligt startar en process som allokerar allt kvarvarande minne så är sannolikheten stor att den nya processen dödas i Linux. I Solaris så blir det istället den första processen som försöker allokera mer minne och inte kontrollerar att den faktiskt fick mer minne eller inte som kraschar, alternativt stänger av sig själv om processen faktiskt kontrollerade om minnet var slut eller inte. I Solaris så har en process iofs. möjligheten att försöka allokera minne tills det lyckas, men som du säkert kan föreställa dig så kommer det inte fungera så bra om alla processer gör så.

Skrivet av dr slizer:

Fast det gör väl alla moderna OS med stöd för virtuellt minne? Det är ju det som är hela poängen. Under Windows har ju t.ex. alla 32bit-program som standard 2GB workspace, har du då 30 processer igång så har programmen i teorin tillgång till 60GB RAM. Att sen detta virtuella minne ligger på disk, i delade bibliotek, RAM eller inte används alls har ju egentligen mindre betydelse. Eller är det något annat du syftar på?

Poängen är att Linux delar ut mer virtuellt minne än som finns, och med virtuellt minne menar jag då fysiskt minne + swap. När det minnet tar slut så finns det helt enkelt inget minne kvar att lagra på, och det är skillnaden i hur Linux och Solaris hanterar den situationen som diskuteras i denna tråd (jag tror att någon nämnde något om ZFS också ).

Permalänk
Avstängd
Skrivet av perost:

Red Hat delades upp i Red Hat Enterprise Linux (RHEL) och Fedora 2003, och både RHEL och Fedora har använt Linux v2.6 i över 5 år nu. Det finns säkert någon obskyr distro som fortfarande använder v2.4, men t.om. Slackware har ju kört v2.6 i flera år nu.

Ok, jag hörde nånstans att RedHat kör v2.4 än idag. Men det stämmer alltså inte. Ok, då vet jag det. Tack.

Skrivet av perost:

Och som sagt, det är inte uppenbart vilken strategi som är bäst. I Solaris så kommer förmodligen en slumpmässig process att krascha när minnet tar slut, eftersom programmerare nästan aldrig kontrollerar att t.ex. malloc inte returnerar en NULL-pekare. I Linux så dödas istället en process som kärnan tycker är "oviktig", och "viktiga" processer har en chans att klara sig.

Jag har svårt att tro att programmerare inte kollar om malloc inte returnerar en NULL pekare. Jag har aldrig någon gång sett sådan kod. Det låter mycket märkligt att man inte kollar efter NULL, och jag är starkt tveksam till att såna nybörjarfel förekommer alls, du verkar tycka att det är "typiskt" att såna fel är vanliga?

Att Linux lovar bort mer RAM än som finns, är ju illa. Speciellt kanske när Linux börjar döda processer som kernel tycker är oviktiga. Kernel har ju inte en aning om vad som är viktigt eller inte. Ett företag kör två program, ett viktigt och ett oviktigt. Hur ska Linux veta vilken den ska döda? Svar: den dödar lite på måfå. Eller menar du att OOM väljer det mindre viktiga programmet? Det är ju omöjligt att veta för OOM.

Solaris lovar inte bort mer RAM än vad som finns. Om RAM är slut, så kommer Solaris säga till programmet att "minnet är slut" så malloc failar med en NULL pekare så programmet kommer att agera därefter på detta fel. Detta är självklart att göra i Enterprise Unix världen med dess stora servrar som kör kritisk mjukvara.

Det är många gamla sysadmins som klagar på Linux utvecklarna och deras dåliga vanor. Om Linux utvecklarna inte kollar om malloc ger en NULL pekare så kanske detta är vanligt för Linux. Men gamla Unix rävar gör aldrig så. T.ex. så klagar sysadmins på att förr i tiden, så program var portabla mellan olika Unix OS. Nu, när Linux kommit, så börjar programmen bli icke-portabla mellan olika Unix OS. Linux källkod skrivs inte snyggt och portabelt. Och man kan inte längre bara kompilera källkod för olika OS, utan att göra massa ändringar. Linux utvecklarna har massa dåliga vanor, säger sysadmins. T.ex. hade ju Kernighan och andra gamla Unix rävar tittat på Linux koden och sagt att den var av dålig kvalitet.

Vad är att föredra? Att programmen får själv ta hand om felet och spara ned allting och sen avsluta, eller att Linux helt plötsligt går bärsärk och dödar processer hej vilt utan att de hinner spara arbetet? Linux kan ju faktiskt krascha om OOM väljer att döda fel process. Det låter inte vidare stabilt? Detta processdödande kan ju leda till mycket svåra fel att debugga. En kund ringer in och säger att mjukvaran kraschade, och vi sätter igång att debugga. Efter lång tid, så upptäcker vi att kundens RAM tog slut - mao vi hade inget fel. Felet låg i Linux OOM som gick bärsärk. Detta fel låter inte så kul.

Kanske är detta ett av skälen till att Linux anses instabilt av gamla Unix rävar?

Permalänk
Medlem
Skrivet av saddam:

Jag har svårt att tro att programmerare inte kollar om malloc inte returnerar en NULL pekare. Jag har aldrig någon gång sett sådan kod. Det låter mycket märkligt att man inte kollar efter NULL, och jag är starkt tveksam till att såna nybörjarfel förekommer alls, du verkar tycka att det är "typiskt" att såna fel är vanliga?

Visst, jag anser att det är rätt så vanligt att programmerare inte kollar vad malloc returnerar. Jag jobbar själv som programmerare, och vet av erfarenhet att de flesta programmerare är långt ifrån perfekta när det gäller sånt. Wikipedias sida om OOM nämner t.om. det som ett problem:

Citat:

A process that exceeds its per-process limit will have attempts to allocate further memory, for example with malloc(), return failure. A well-behaved application should handle this situation gracefully; however, many do not.

Skrivet av saddam:

Att Linux lovar bort mer RAM än som finns, är ju illa. Speciellt kanske när Linux börjar döda processer som kernel tycker är oviktiga. Kernel har ju inte en aning om vad som är viktigt eller inte. Ett företag kör två program, ett viktigt och ett oviktigt. Hur ska Linux veta vilken den ska döda? Svar: den dödar lite på måfå. Eller menar du att OOM väljer det mindre viktiga programmet? Det är ju omöjligt att veta för OOM.

Jag har själv råkat ut för flera gånger när någon process gått bärsärka-gång och börjar allokera allt minne. Linux har då dödat processen, och jag har sluppit förlora arbete. Om man hanterar det som Solaris så får man istället en race condition, och den första processen som försöker allokera minne får som svar att minnet är slut. Detta är vad jag förstår en av orsakerna till att linux använder OOM killer. För vad skulle annars hända om t.ex. en viktig systemprocess försöker allokera mer minne när minnet är slut? Då är det i alla fall i mitt tycke bättre att någon användarprocess dödas än att hela systemet går ned bara för att en viktig systemprocess var lov att stänga ner sig själv p.g.a. slut på minne.

Men som ronnylov nämnde så går det att stänga av overcommit av minne, så om det är ett så stort problem så är det bara att stänga av.

Permalänk
Avstängd
Skrivet av perost:

Visst, jag anser att det är rätt så vanligt att programmerare inte kollar vad malloc returnerar. Jag jobbar själv som programmerare, och vet av erfarenhet att de flesta programmerare är långt ifrån perfekta när det gäller sånt.

Jag förstår att man kan glömma att kolla vad malloc returnerar i något enstaka fall. Alla kan göra buggar. Men jag har svårt att tro att man glömmer att kolla malloc, pga okunskap. Visst, enstaka buggar finns ju alltid, det är ju självklart. Det är kanske det du menar - att man glömmer det ibland?

Skrivet av perost:

Jag har själv råkat ut för flera gånger när någon process gått bärsärka-gång och börjar allokera allt minne. Linux har då dödat processen, och jag har sluppit förlora arbete.

Linux dödar väl processer i stort sett, på måfå? Det är väl inte säkert att Linux dödar processen som håller på att gå bärsärkagång? Så om Linux börjar döda processer till höger och vänster, men låter bärsärkagången fortsätta - så är det väl inte bra? Visst, det finns väl nån heurustik, en algoritm, hur OOM dödar processer. Men om du läste min länk så går till Linux utvecklare som diskuterar, så funkar inte OOM felfritt: "ibland dödas den lättaste passageraren (dvs processen), ibland dödas den tyngsta, ibland dödas piloten som styr flygplanet, etc". Enligt länken finns det bland Linux utvecklare, många funderingar om vilken process man ska döda, och man är inte överens alls hur man ska göra. Linux dödar alltså i praktiken, på måfå. Den dödar inte alltid processen som går bärsärkagång den kan få fortsätta gå bärsärkagång.

Skrivet av perost:

Om man hanterar det som Solaris så får man istället en race condition, och den första processen som försöker allokera minne får som svar att minnet är slut.

Om en process som försöker allokera mer minne, får veta att minnet är slut så borde processen hantera situationen (om det inte finns en bugg som hindrar processen att hantera situationen). Och då borde det inte vara något problem. Men visst, om det finns en bugg så det uppstår en race condition
1) Användarprogram A allokerar minne.
2) Minnet tar slut
3) En systemprocess behöver mer minne - det går inte
Vad händer då i Solaris? Det är en intressant fråga, som jag inte tänkt på. Jag ska fråga och återkommer. Jag vill också veta vad Solaris gör i detta fall. Kanske gör Solaris något med SMF (som automatiskt återstartar viktiga systemprocesser om de strular)? En annan fråga: Vad gör FreeBSD i detta fall?

Men jag är inte alls övertygad om att man bör döda processer till höger och vänster i detta fall. I värsta fall så fortsätter Linux att köra, men pga nån process saknas, så blir det kanske felaktiga utdata som programmen producerar.

Då föredrar jag personligen att man försöker reparera felet om möjligt, och varnar och låter användaren bestämma.

Skrivet av perost:

Men som ronnylov nämnde så går det att stänga av overcommit av minne, så om det är ett så stort problem så är det bara att stänga av.

Men det är påslaget, per default? Men inte på Solaris. Ett skäl till att det är påslaget per default, kanske är att Linux ofta råkar ut för minnesläckor pga slarvig programmering, men det gör inte Solaris pga Unix programmerare är gamla skäggiga utvecklare (det finns en teori om att ju större skägg, desto mer guru. Kolla bara på Bjarne Stroustrup, Kernighan, Gosling och alla gamla rävar). Ja, vi får se. Jag vill veta vad Solaris gör, så jag frågar och återkommer.

Permalänk
Medlem
Skrivet av saddam:

Men det är påslaget, per default? Men inte på Solaris. Ett skäl till att det är påslaget per default, kanske är att Linux ofta råkar ut för minnesläckor pga slarvig programmering, men det gör inte Solaris pga Unix programmerare är gamla skäggiga utvecklare (det finns en teori om att ju större skägg, desto mer guru. Kolla bara på Bjarne Stroustrup, Kernighan, Gosling och alla gamla rävar). Ja, vi får se. Jag vill veta vad Solaris gör, så jag frågar och återkommer.

De flesta gamla rävar som jag pratat med sitter på mac , linux eller windows (Ritchie har uteslutande windows på sin desktop idag) och Bjarne... Han är ju bara galen. Kvaliteten på koden i solaris är inte speciellt mycket högre än i Linux imo, visst att gnu's stdlib är lite värre och att mycket legacykod i linux borde städat ut.

Angående att linux inte följer POSIX så är det väl jättebra? Det gör ju att systemen utvecklas och att vi kanske slipper de buggar som UNIX har dragits med i massa år. För att inte tala om crap_ctl, som är en av orsakerna till att jag inte gillar freebsd och de skapar ju bara fler och fler sådan.

Utan Linux skulle nog stora delar av *nix vara dött idag. Är ingen jättefan av Linux heller tbh men som Rob Pike sa: Det coola med Linux är inte koden, det är modellen och att hur bra det funkar.

And Yes, I have kissed a girl.

Permalänk
Avstängd

Ok, här pratas det precis om det vi har diskuterat, hur Solaris funkar med overcommit av minne:
Re: overcommit Memory on Solaris

>>>b) what happens to the kernel, when all virtuell memory is filled and
>>>e.g. a kernel module must be loaded, maybe a driver, or a cronjob
>>>starts or a daemon forks. Does it panic, or just dont start new memory eaters?

>In the kernel one of two things can happen: the memory allocation fails
>or the system will wait until memory becomes available.

Before we got to that point, there's some active purging such as
unloading kernel modules which are not currently in use.

>System calls like fork() will fail with an appropriate error code.
>The system should not panic.

Detta tycker jag låter bättre än att processer dödas till höger och vänster. Systemet börjar rensa upp minne (slänger ut kernel modules, etc) och om det inte räcker så väntar systemet tills det frigörs minne. Systemet börjar inte krascha eller nåt sånt.

Skrivet av dagle:

De flesta gamla rävar som jag pratat med sitter på mac , linux eller windows (Ritchie har uteslutande windows på sin desktop idag)

Jo, men vad rävarna har för OS på sitt desktop, betyder ju inte att de kör det OSet. T.ex. har jag för mig att det fanns ZFS och DTrace utvecklare som satt på Mac. Men de utvecklade knappast Solaris ZFS på en Mac, utan körde väl ssh in på de Solaris servrarna de utvecklade på. Samma sak med Gosling som var involverad i Java, jag har för mig att han körde Mac. Mac versionen av Java laggade ju efter den officiella Java versionen - jag har svårt att tro att Gosling utvecklade den gamla Java versionen till Mac, medan alla andra Sun utvecklare utvecklade senaste Java på Solaris. Java är ju främst för servrar, och desktop i andra hand. Sun var ju ett Unix företag, jag har svårt att tro att all nyutveckling skedde på ett desktop OS som Windows, och sedan när allt var klart, så kollade man hur bra Unix servrarna funkade med senaste Java versionerna?

På samma sätt tror jag om Ritchie som bara har Windows idag (enligt din utsago). Han har ju varit med och skapat Unix och Plan9 och är än idag aktiv i utvecklandet. Jag misstänker att han ssh in på servrar med plan9 eller Unix, jag tror inte han har gått över t.ex. till MFC och Windows programmering, han gör ju unix liknande OS än idag.

Citat:

och Bjarne... Han är ju bara galen.

Hehe, han ser galen ut! Men jag har stor respekt för honom, även om jag själv inte gillar C++. Just större skägg, desto mer Guru?

Citat:

Kvaliteten på koden i solaris är inte speciellt mycket högre än i Linux imo

Om man läser intervjuer med ZFS utvecklare som Pawel(?) som portade ZFS till FreeBSD så säger han att ZFS koden är bra och tight. Samma med DTrace utvecklare. Jag har inte sett klagomål på att Solaris koden är dålig, men du får gärna visa länkar. Jag ska läsa dem med största intresse.

Angående Linux kodkvalitet, så har ju många Linux utvecklare själva klagat på koden. T.ex. Andrew Morton, som säger att koden är av låg kvalitet. Eller Linus Torvalds som säger att Linux börjar bli bloatad. Studier av Intel visar att Linux prestandan sjunker och sjunker, -12% de senaste releaserna. För att inte prata om vad Theo de raadt säger:
Is Linux For Losers? - Forbes.com

"[Linux] is terrible," De Raadt says. "Everyone is using it, and they don't realize how bad it is. And the Linux people will just stick with it and add to it rather than stepping back and saying, 'This is garbage and we should fix it.'"

"Linux has never been about quality. There are so many parts of the system that are just these cheap little hacks, and it happens to run." As for Linus Torvalds, who created Linux and oversees development, De Raadt says, "I don't know what his focus is at all anymore, but it isn't quality."

En VD säger:
"You know what I found? Right in the kernel, in the heart of the operating system, I found a developer's comment that said, 'Does this belong here?' "Lok says. "What kind of confidence does that inspire? Right then I knew it was time to switch."

Men som sagt, klistra gärna in lite länkar om Solaris koden, om den nu är så dålig. Jag läser gärna lite mera.

Citat:

Angående att linux inte följer POSIX så är det väl jättebra? Det gör ju att systemen utvecklas och att vi kanske slipper de buggar som UNIX har dragits med i massa år.

Skämtar du? Påstår du att Unix är buggigare än Linux? Du har inte läst om hur mycket problem folk har med Linux? Och tycker du det även är bra att Linux inte följer standarder? Är detta nedanstående bra, tycker du?

milek's blog: Linux, O_SYNC and Write Barriers

"This is really scary. I wonder how many developers knew about it especially when coding for Linux when data safety was paramount. Sometimes it feels that some Linux developers are coding to win benchmarks and do not necessarily care about data safety, correctness and standards like POSIX. What is even worse is that some of them don't even bother to tell you about it in official documentation (at least the O_SYNC/O_DSYNC issue is documented in the man page now)."

T.ex. ZFS kan få problem ibland. Om underliggande hårdvaran är billig och man fuskat, så kan hårdvaran säga till ZFS att det gjort en sak - men i själva verket ljuger hårdvaran. Kommer inte ihåg alla detaljer, men typ att disken säger att den flushat vilket inte skett. Så om man ljuger för ZFS så kan ZFS få problem. Det är för att man inte följer standarder.

Jag kan verkligen inte se varför det är bra att INTE följa standarder. Låter mycket märkligt i mina öron.

Citat:

Utan Linux skulle nog stora delar av *nix vara dött idag.

Det tror jag inte alls. Sun ville öppna upp Solaris för decennier sen, men AT&T krävde att om Sun skulle få Unix kod så måste det vara stängt. Många år senare köpte Suns VD rätten att öppna upp Unix för 90 miljoner USD. Och då skapades OpenSolaris. Sun själva tror att om de varit tidiga med att öppna upp Solaris så hade många kört det idag. Jag tror detsamma.

Poängen med Linux är inte att det är bra, eller nåt sånt. FreeBSD hade ju problem med sin stämning, därför kunde inte BSD öppnas upp. Linux slank in emellan och tog marknadsandelar som ett öppet OS. Om inte Linux funnits, så skulle FreeBSD eller Solaris eller nån annan tagit Linux roll. Tiden var mogen för ett öppet Unix liknande OS.

Så jag tror inte Linux räddat nånting. Hade inte Linux funnits så hade något annat OS klivit in. Tiden var mogen. Det bara råkade bli Linux.

Citat:

Är ingen jättefan av Linux heller tbh men som Rob Pike sa: Det coola med Linux är inte koden, det är modellen och att hur bra det funkar.

Ska man tolka detta som att Pike säger att Linux koden är dålig?

Citat:

And Yes, I have kissed a girl.

Jo, Adam Leventhals svar är roligt!

Permalänk
Medlem

När kommer nästa Debian-release då?

Permalänk
Medlem
Skrivet av GuTsaV:

När kommer nästa Debian-release då?

När den är klar, med andra ord när alla "Release Critical"-buggar är lösta. Verkar närma sig nu.

Permalänk
Medlem
Skrivet av saddam:

Ok, jag hörde nånstans att RedHat kör v2.4 än idag. Men det stämmer alltså inte. Ok, då vet jag det. Tack.

Den senaste Redhat version som körde på kernel 2.4 var RHEL 3, det släpptes 2003, dvs 7 år sedan, dock finns det nog en del som fortfarande kör det, EOL på det utökade support-avtalet utgår i slutet av 2013. Själv har jag under detta året jobbat mycket med att flytta system från RHEL 3 till RHEL 5.

Skrivet av saddam:

milek's blog: Linux, O_SYNC and Write Barriers

"This is really scary. I wonder how many developers knew about it especially when coding for Linux when data safety was paramount. Sometimes it feels that some Linux developers are coding to win benchmarks and do not necessarily care about data safety, correctness and standards like POSIX. What is even worse is that some of them don't even bother to tell you about it in official documentation (at least the O_SYNC/O_DSYNC issue is documented in the man page now)."

T.ex. ZFS kan få problem ibland. Om underliggande hårdvaran är billig och man fuskat, så kan hårdvaran säga till ZFS att det gjort en sak - men i själva verket ljuger hårdvaran. Kommer inte ihåg alla detaljer, men typ att disken säger att den flushat vilket inte skett. Så om man ljuger för ZFS så kan ZFS få problem. Det är för att man inte följer standarder.

ZFS har ju haft ordentliga problem med fsync() och O_DSYNC var ju bara ett halvår sedan det släpptes en patch för det (142900-09) , och hade fortfarande problem med fsync på skrivningar över 32kb. Tror de problemen är fixade nu, men det har gjort ZFS obrukbart för t.ex. databaser framtill i maj i år.

Permalänk
Skrivet av saddam:

......... vad Theo de raadt säger:
Is Linux For Losers? - Forbes.com
"[Linux] is terrible," De Raadt says. "Everyone .....

Den där artikeln var väldigt underhållande, nästan roligare än OpenBSD IPSEC anklagelserna

Mitt favoritcitat i artikeln:
"BSD guys make fun of Linux on message boards and Web sites, the gist being that BSD guys are a lot like Linux guys, except they have kissed girls. "

Permalänk
Medlem
Skrivet av GenuineDexxa:

Den där artikeln var väldigt underhållande, nästan roligare än OpenBSD IPSEC anklagelserna

Mitt favoritcitat i artikeln:
"BSD guys make fun of Linux on message boards and Web sites, the gist being that BSD guys are a lot like Linux guys, except they have kissed girls. "

Riktigt dålig artikel ja...

Permalänk
Avstängd
Skrivet av houze:

ZFS har ju haft ordentliga problem med fsync() och O_DSYNC var ju bara ett halvår sedan det släpptes en patch för det (142900-09) , och hade fortfarande problem med fsync på skrivningar över 32kb. Tror de problemen är fixade nu, men det har gjort ZFS obrukbart för t.ex. databaser framtill i maj i år.

Jo, men skillnaden är att Linux har dessa problem, by design. Linux är designat att HA de problemen. I ZFS handlar det om buggar, det är inte så att ZFS är designat att strunta i saker. Om ZFS struntar i saker, så är det en bugg. I Linux är det medvetet (för att få högre på benchmarks, antagligen).

Skrivet av GenuineDexxa:

Den där artikeln var väldigt underhållande, nästan roligare än OpenBSD IPSEC anklagelserna

Mitt favoritcitat i artikeln:
"BSD guys make fun of Linux on message boards and Web sites, the gist being that BSD guys are a lot like Linux guys, except they have kissed girls. "

Hehe, jag håller med. Den är rolig. Linux snubbarna verkar ju vara helt ute och cykla. Nu senast togs ju BKL bort, t.ex. Hur i hela friden kan Linux skala när BKL finns? Inte en chans. Om en cpu sätter ett lås, så måste alla andra cpuer vänta.

Solaris hade också BKL, men det togs bort för 30 år sen. Nu i Linux v2.6.37 tas BKL bort. Men det finns fortfarande delar av Linux som har kvar BKL än idag, det är inte helt borta. För att inte tala om minneshanteringen som tydligen har seriösa problem ännu.

Permalänk
Medlem

Ja, det är uppenbart att man inte kan använda Linux till något seriöst.

Permalänk
Avstängd
Skrivet av nillon:

Ja, det är uppenbart att man inte kan använda Linux till något seriöst.

Det har jag inte sagt. De flesta här torde vara överens om att Linux är bättre tekniskt och stabilare, än Windows, men många företag använder ju Windows till något seriöst. Bevisar det att Windows är bättre än Linux? Nej. Trots att Windows har många brister så används det till seriösa saker.

Det är inte vettigt att strunta i standarder och ta genvägar, för att få bättre prestanda. Stabilitet och skalbarhet är viktigare än prestanda, i många kretsar.