mboost-dp1
Creative Commons
Først troede jeg at det var virkeligt, VIRKELIGT, vigtige værktøjer!
...så fandt jeg Ubuntu på plads nummer tre - og det vil jeg altså ikke beskylde for at være vigtigt, det er bare en god samling af pakker, IMO, som bare dukkede op på det rigtige tidspunkt med den rigtige mængde reklamepenge.
Jeg vil påstå at Blender er vigtigere, da det rent faktisk IKKE har reelt brugbare alternativer i modsætning til Ubuntu. Og så beviser Blender også hvad OpenSource kan
...så fandt jeg Ubuntu på plads nummer tre - og det vil jeg altså ikke beskylde for at være vigtigt, det er bare en god samling af pakker, IMO, som bare dukkede op på det rigtige tidspunkt med den rigtige mængde reklamepenge.
Jeg vil påstå at Blender er vigtigere, da det rent faktisk IKKE har reelt brugbare alternativer i modsætning til Ubuntu. Og så beviser Blender også hvad OpenSource kan
#6
Ubuntu har en meget stor rolle for udbredelsen af Linux, især på desktoppen. Godt nok ikke så teknisk interessant, men de har stor indflydelse.
Men jeg er enig i at Ubuntu ikke nødvendigvis er i top 10.
Blender er et meget interessant værktøj, men jeg synes nu ikke ligefrem det er top 10. Blender påvirker ret få mennesker.
Ubuntu har en meget stor rolle for udbredelsen af Linux, især på desktoppen. Godt nok ikke så teknisk interessant, men de har stor indflydelse.
Men jeg er enig i at Ubuntu ikke nødvendigvis er i top 10.
Axl (6) skrev:Jeg vil påstå at Blender er vigtigere
Blender er et meget interessant værktøj, men jeg synes nu ikke ligefrem det er top 10. Blender påvirker ret få mennesker.
GNU havde virkelig fortjent førstepladsen. Linux har altid fået meget af æren for hvad GNU har udrettet. Jeg synes personerne bag sådan en liste burde have sat sig nok ind i det, til at kunne se hvad GNU har udrettet.
Linux ville intet være uden GNU. GNU værktøjerne var allerede i brug før Linux startede.GNU værktøjerne kan bruges på andre operativsystemer inklusiv BSD og de fleste and Unix systemer.
Man kan så diskutere om et open source projekt stadigvæk fortjener en plads på listen, hvis de primært bruges på en ellers lukket platform. Samme spørgsmål kunne stilles omkring Firefox, som ikke kom med. Er Firefox ikke på listen, fordi det primært bliver brugt på Windows, eller er der en anden grund?
Jeg undrede mig også lidt over at finde Ubuntu på listen. Som andre har påpeget, det er stort set bare Debian pakket pænt ind og markedsført. På den anden side, hvis man mener markedsføring er et vigtigt projekt, så kunne man da godt sige at Ubuntu er vigtigt.
I sidste ende er det et subjektivt spørgsmål. Det mest objektive man kunne have gjort var en afstemning. Havde man lavet en afstemning, så ville de fleste stemmer nok komme fra personer, som ikke kender projekterne og ved hvorfor de er vigtige. F.eks. tror jeg GNU ville være endnu længere nede på trods af at det meste software på listen sikkert bliver kompileret med gcc.
Linux ville intet være uden GNU. GNU værktøjerne var allerede i brug før Linux startede.GNU værktøjerne kan bruges på andre operativsystemer inklusiv BSD og de fleste and Unix systemer.
Man kan så diskutere om et open source projekt stadigvæk fortjener en plads på listen, hvis de primært bruges på en ellers lukket platform. Samme spørgsmål kunne stilles omkring Firefox, som ikke kom med. Er Firefox ikke på listen, fordi det primært bliver brugt på Windows, eller er der en anden grund?
Jeg undrede mig også lidt over at finde Ubuntu på listen. Som andre har påpeget, det er stort set bare Debian pakket pænt ind og markedsført. På den anden side, hvis man mener markedsføring er et vigtigt projekt, så kunne man da godt sige at Ubuntu er vigtigt.
I sidste ende er det et subjektivt spørgsmål. Det mest objektive man kunne have gjort var en afstemning. Havde man lavet en afstemning, så ville de fleste stemmer nok komme fra personer, som ikke kender projekterne og ved hvorfor de er vigtige. F.eks. tror jeg GNU ville være endnu længere nede på trods af at det meste software på listen sikkert bliver kompileret med gcc.
#7 > Jeg vil godt indrømme at jeg muligvist er lidt biased, da jeg selv bruger Blender - men det er trods alt et af de få programmer som den store industri af 3Dfilm rent faktisk virker en smule villig til at tage til sig (med undtagelse af Linux der jo kan køre Maya).
Jeg synes ikke Ubuntu er vigtig. De har intet gjort som ikke kunne have været gjort af andre. Jeg mener slet ikke de hører til på en sådan top 10.
Men endnu mere undrende stiller jeg mig faktisk overfor sendmail - men det er muligvist fordi jeg er for ung.
Jeg synes ikke Ubuntu er vigtig. De har intet gjort som ikke kunne have været gjort af andre. Jeg mener slet ikke de hører til på en sådan top 10.
Men endnu mere undrende stiller jeg mig faktisk overfor sendmail - men det er muligvist fordi jeg er for ung.
#7 Mange nye studier bruger Blender istedet for de traditionelle 3D pakker til deres pipeline og når det er kommet så langt på 7 år som open source project så må man give projectet lidt respekt.
Kig på blendernation.com der ser du at der konstant popper nye forums, magaziner op over hele verden, udover at der er flere og flere reklamere der bliver lavet på meget højt professionelt niavue i Blender
At sige det ikke påvirker mange mennesker er lidt arrogant og ved siden af pointen som er at Blender begynder at blive brugt professionelt af professionelle. Det er nok det stærkest community jeg har oplevet på nettet efter Ubuntu.
Kig på blendernation.com der ser du at der konstant popper nye forums, magaziner op over hele verden, udover at der er flere og flere reklamere der bliver lavet på meget højt professionelt niavue i Blender
At sige det ikke påvirker mange mennesker er lidt arrogant og ved siden af pointen som er at Blender begynder at blive brugt professionelt af professionelle. Det er nok det stærkest community jeg har oplevet på nettet efter Ubuntu.
Det kommer an på hvad du tæller med.blaaoejet (11) skrev:er det bare mig eller er det 4 større BSD udgivelser..
OpenBSD
NetBSD
FreeBSD
Og DragonflyBSD
BSD licensen tillader at man kan tage sourcen, ændre den, compilere den, og udgive resultatet under et andet navn uden at levere source kode med. Hvis du tæller den slags med, så er der mange.
De mest kendte er nok Windows og Mac OS X, som begge indeholder BSD kode. I Windows tilfælde er der vist ikke voldsomt meget BSD kode, og det er sikkert ændret meget i forhold til originalen. På Mac OS X er systemet stadigvæk genkendeligt, og så vidt jeg husker er dele af det stadigvæk open source.
Men hvis man snakker om systemer, der stadigvæk har BSD i navnet, så kender jeg ikke andre end de fire du nævner.
Jeg har ikke source koden, så jeg kan ikke sige præcist hvor meget der er tilbage. Der er nogen som har brugt strings på diverse filer og fundet copyright tekster fra den originale BSD.XorpiZ (13) skrev:Af ren nysgerrighed - hvad indeholder Windows af BSD-kode efterhånden?
Så vidt jeg ved, så blev TCP/IP stacken lånt fra BSD i sin tid, men jeg synes at have læst et sted, at fra Vista og frem, er det deres egen stack, de bruger.Det er svært at vurdere. Jeg har læst at de startede med at tage stakken fra BSD og tilpasse til Windows. I næste version af Windows brugte de så deres egen stak, men den virkede så dårligt, at de gik tilbage til BSD stakken.
Selv hvis man så source koden til den nuværende version, så er jeg ikke sikker på at man kan se om den er skrevet fra bunden eller om de blot er blevet ved med at ændre på den de tog fra BSD.
Det er nok kun udviklerne af Windows, der kender det præcise svar på dit spørgsmål.
Den her liste er jo ikke så meget andet end deres holdning.
Det man som jeg ser det burde have gjort var at tage hovedinteressent grupperne og stillet spørgsmålet til dem, lavet en pointfordeling for de top 10 valg som de enkelte grupper lavede, og til sidst havde regnet et resultat ud.
Grupperne kunne være:
Desktop brugere
Open Source firmaer
Universitets professorer
System Administratorer
OSS Software udviklere
Det er sjældent en god løsning at lave et direkte ufokuseret spørgeskema, for så vælger folk bare det de tilfældigvis er interesserede i, du skal ind og have fat i dem der arbejder med det til dagligt og derfor som oftest har en gennemtænkt holdning til tingene, og så skal du vide fra hvilken gruppe folk er.
#18
Tja, hvilken LAMP?
Linux, Apache, MySQL, PHP?
Linux, Apache, MySQL, Perl?
Linux, Apache, MySQL, Python?
Og nu er der jo iøvrigt også mange der bruger Postgresql istedetfor mysql. LAMP som koncept er ved at falde sammen.
#19
Det er jo så en klient liste.
Det man som jeg ser det burde have gjort var at tage hovedinteressent grupperne og stillet spørgsmålet til dem, lavet en pointfordeling for de top 10 valg som de enkelte grupper lavede, og til sidst havde regnet et resultat ud.
Grupperne kunne være:
Desktop brugere
Open Source firmaer
Universitets professorer
System Administratorer
OSS Software udviklere
Det er sjældent en god løsning at lave et direkte ufokuseret spørgeskema, for så vælger folk bare det de tilfældigvis er interesserede i, du skal ind og have fat i dem der arbejder med det til dagligt og derfor som oftest har en gennemtænkt holdning til tingene, og så skal du vide fra hvilken gruppe folk er.
#18
Tja, hvilken LAMP?
Linux, Apache, MySQL, PHP?
Linux, Apache, MySQL, Perl?
Linux, Apache, MySQL, Python?
Og nu er der jo iøvrigt også mange der bruger Postgresql istedetfor mysql. LAMP som koncept er ved at falde sammen.
#19
Det er jo så en klient liste.
#21
MySQL er svær at konkurrere med i simple webapplikationer, primært fordi de ofte ikke bruger meget andet end inserts og selects og evt. et par joins.
Der hvor MySQL faldet helt sammen er når du har flere læsere og skrivere på den samme database, så begynder du at se læse tider på et par sekunder, primært fordi MySQL's locking er så langt bagefter alle andre moderne databaser.
Derudover er det heller ikke fair at sammenligne en standard MyISAM konfiguration med Postgresql, hvis du endelig vil sammenligne dem så sammenlign InnoDB med Postgresql. Sidst men ikke mindst så er PHP et elendigt basis sprog for sammenligning hvis du ikke bruger applikationsservere der kan håndtere database adgangen. Moderne applikationsservere bruger persistent database forbindelser, og der falder MySQL's fordel også kraftigt.
Når det så er sagt så er MySQL en ganske imponerende database til simple applikationer, den er bare featuremæssigt LANGT bagud.
MySQL er svær at konkurrere med i simple webapplikationer, primært fordi de ofte ikke bruger meget andet end inserts og selects og evt. et par joins.
Der hvor MySQL faldet helt sammen er når du har flere læsere og skrivere på den samme database, så begynder du at se læse tider på et par sekunder, primært fordi MySQL's locking er så langt bagefter alle andre moderne databaser.
Derudover er det heller ikke fair at sammenligne en standard MyISAM konfiguration med Postgresql, hvis du endelig vil sammenligne dem så sammenlign InnoDB med Postgresql. Sidst men ikke mindst så er PHP et elendigt basis sprog for sammenligning hvis du ikke bruger applikationsservere der kan håndtere database adgangen. Moderne applikationsservere bruger persistent database forbindelser, og der falder MySQL's fordel også kraftigt.
Når det så er sagt så er MySQL en ganske imponerende database til simple applikationer, den er bare featuremæssigt LANGT bagud.
blaaoejet (11) skrev:er det bare mig eller er det 4 større BSD udgivelser..
OpenBSD
NetBSD
FreeBSD
Og DragonflyBSD
Større er jo et lidt subjektivt udtryk.
DragonflyBSD er en fork af FreeBSD. Det samme er PC-BSD.
Hvor laver man cuttet?
Jeg ville nok have lavet det efter de 3 ligesom i artiklen.
kasperd (12) skrev:Men hvis man snakker om systemer, der stadigvæk har BSD i navnet, så kender jeg ikke andre end de fire du nævner.
Der klones skam på livet løs.
http://en.wikipedia.org/wiki/Comparison_of_BSD_ope...
har en ret lang liste liste med alle mulige kloninger af FreeBSD, OpenBSD og NetBSD.
Anders Feder (16) skrev:Men det omvendte er mindst ligeså sandt.
GNU var meget udbredt mange år førend Linux kom på banen.
Kasperd har brugt GNU 2 år han gik igang med Linux. Jeg startede med GNU 11 år før Linux.
Selv på Windows er der mange som har en stribe GNU programmer. Cygwin, MinGW etc..
Selvom Linux ikke havde eksisteret, så havde GNU stadig været brugt på de kommercielle Unix'er, *BSD'erne og tildels på Windows.
SmackedFly (20) skrev:
Tja, hvilken LAMP?
Linux, Apache, MySQL, PHP?
Linux, Apache, MySQL, Perl?
Linux, Apache, MySQL, Python?
Og nu er der jo iøvrigt også mange der bruger Postgresql istedetfor mysql. LAMP som koncept er ved at falde sammen.
PHP er langt mere udbredt end de andre P'er. Brug af Perl CGI er vel faldende og ganske vist er brugen af Python stigende, men stadig langt fra PHP niveauet.
MySQL er også (stadig) langt mere udbredt end PostgreSQL. Man kan diskutere om det er fortjent. Men sådan er det.
SmackedFly (23) skrev:Der hvor MySQL faldet helt sammen er når du har flere læsere og skrivere på den samme database, så begynder du at se læse tider på et par sekunder, primært fordi MySQL's locking er så langt bagefter alle andre moderne databaser.
MySQL MyISAM tillader fint concurrent INSERT og SELECT uden overflødig locking.
Det er muligt at du får performance problemer ved UPDATE og SELECT, men med et typisk mix vil der være langt flere INSERT end UPDATE, så jeg kan ikke helt se at det skulle være så slemt.
SmackedFly (23) skrev:Derudover er det heller ikke fair at sammenligne en standard MyISAM konfiguration med Postgresql, hvis du endelig vil sammenligne dem så sammenlign InnoDB med Postgresql.
Det er jeg så enig i. ACID !
SmackedFly (23) skrev:Sidst men ikke mindst så er PHP et elendigt basis sprog for sammenligning hvis du ikke bruger applikationsservere der kan håndtere database adgangen. Moderne applikationsservere bruger persistent database forbindelser,
Jeg mener at de fleste database moduler til PHP understøtter persistent connections.
Der er så en del issues som skal overvejes inden man skifter til pconnect, men muligheden eksisterer.
SmackedFly (23) skrev:og der falder MySQL's fordel også kraftigt.
Det er vel et PHP problem som er helt uafhængig af MySQL vs PostgreSQL.
#31
Tjaah, Postgresql er lavet så skrivninger aldrig forhindrer læsning, hvilket MySQL ikke kan følge med til, men igen, til simple applikationer er det selvfølgelig som oftest irrelevant.
Postgresql connects er dyrere end MySQL connects, så det vil jeg ikke sige.
arne_v (31) skrev:MySQL MyISAM tillader fint concurrent INSERT og SELECT uden overflødig locking.
Det er muligt at du får performance problemer ved UPDATE og SELECT, men med et typisk mix vil der være langt flere INSERT end UPDATE, så jeg kan ikke helt se at det skulle være så slemt.
Tjaah, Postgresql er lavet så skrivninger aldrig forhindrer læsning, hvilket MySQL ikke kan følge med til, men igen, til simple applikationer er det selvfølgelig som oftest irrelevant.
arne_v (31) skrev:Det er vel et PHP problem som er helt uafhængig af MySQL vs PostgreSQL.
Postgresql connects er dyrere end MySQL connects, så det vil jeg ikke sige.
Det er da ikke i modstrid. En serializable transaktion skal bare returnere data som de så ud da den startede. At en anden transaktion ændrer data i mellemtiden forhindrer ikke læsningerne, det kræver blot at databasen skal opbevare begge kopier indtil den første transaktion er afsluttet.arne_v (39) skrev:Det er nemlig i modstrid med PostgreSQL dokumentationen som hævder at de understøtter transaction isolation level serializable.
Det er et implementationsspørgsmål. Det er fuldstændig legalt at lade en anden transaktion foretage SELECT selvom den første endnu ikke har udført COMMIT. Det betyder at den anden transaktion vil fejle, når den når til UPDATE.arne_v (41) skrev:#40
De er i modstrid.
BEGIN
x = SELECT felt FROM tabel WHERE id=y
UPDATE tabel SET felt = x + 77 WHERE id=y
COMMIT
Du kan ikke udføre den i to tråde med transaction isolation level serializable uden at SELECT i den ene tråd venter på at den anden tråd committer.
Det eneste der blev sagt, var at i Postgresql forhindrer skrivninger ikke læsninger. Naturligvis kan skrivninger forhindrer andre skrivninger, sådan vil det altid være i en database.
kasperd (42) skrev:Det eneste der blev sagt, var at i Postgresql forhindrer skrivninger ikke læsninger. Naturligvis kan skrivninger forhindrer andre skrivninger, sådan vil det altid være i en database.
Det er SELECT'en i tråd 2 som er problemet ikke UPDATE'en. Hvis tråd 2 kørte noget andet end tråd 1 med 2 SELECT ville der være samme problem.
kasperd (42) skrev:Det er et implementationsspørgsmål. Det er fuldstændig legalt at lade en anden transaktion foretage SELECT selvom den første endnu ikke har udført COMMIT. Det betyder at den anden transaktion vil fejle, når den når til UPDATE.
Nix.
SQL 92 siger:
The execution of concurrent SQL-transactions at isolation level
SERIALIZABLE is guaranteed to be serializable. A serializable exe-
cution is defined to be an execution of the operations of concur-
rently executing SQL-transactions that produces the same effect as
some serial execution of those same SQL-transactions. A serial exe-
cution is one in which each SQL-transaction executes to completion
before the next SQL-transaction begins.
Der vil ikke komme en fejl hvis de blev udført serielt.
Jeg er enig i de 9 vigtigste open-source projekter, dog synes jeg én ting burde fjernes og erstattes af noget andet: Ubuntu.
Jeg kan ikke tåle at man skal genstarte sin computer efter man har installeret "vigtige systemopdateringer". På enhver anden distro skal man ikke genstarte medmindre man har lavet kernel-opdateringer.
Et kæmpe, og latterligt tilbageskridt.
Billede
Smid hellere Debian ind. Den har, om nogen, været en stabil og banebrydende distro, som de andre stjæl... undskyld... låner fra!
Jeg kan ikke tåle at man skal genstarte sin computer efter man har installeret "vigtige systemopdateringer". På enhver anden distro skal man ikke genstarte medmindre man har lavet kernel-opdateringer.
Et kæmpe, og latterligt tilbageskridt.
Billede
Smid hellere Debian ind. Den har, om nogen, været en stabil og banebrydende distro, som de andre stjæl... undskyld... låner fra!
#44
Gælder det ikke kun kerne opdateringer på ubuntu?
Jo, der er da måder at loade den nye kerne på, hvis den gamle understøtter det, men som jeg forstår det er det ikke helt trivielt.
Nu undgår jeg helst ubuntu selv, men sidste jeg brugte kubuntu kom der blot et lille ikon ved uret som fortalte mig at kernen var blevet opdateret og jeg burde genstarte min computer, men den blev ikke ved med at spørge om det som visse andre systemer.
EDIT:
Jeg kan i øvrigt ikke se ret meget på dit screenshot, opløsningen er simpelhen for ringe til mine øjne.
Gælder det ikke kun kerne opdateringer på ubuntu?
Jo, der er da måder at loade den nye kerne på, hvis den gamle understøtter det, men som jeg forstår det er det ikke helt trivielt.
Nu undgår jeg helst ubuntu selv, men sidste jeg brugte kubuntu kom der blot et lille ikon ved uret som fortalte mig at kernen var blevet opdateret og jeg burde genstarte min computer, men den blev ikke ved med at spørge om det som visse andre systemer.
EDIT:
Jeg kan i øvrigt ikke se ret meget på dit screenshot, opløsningen er simpelhen for ringe til mine øjne.
#43
Nu er transaction isolation level serializable en optional feature. Du skal specifikt angive at din transaktion skal bruge det. Men sandt nok, hvis du bruger den bliver dine reads nødt til at vente på dine writes.
Men altså, min påstand var at postgresql ikke lader writes blokere reads, din helt rigtige modpåstand er at hvis du essentielt beder databasen om at serialisere alle transaktioner så gør den det, og så kan den selvfølgelig ikke undgå det... Fair nok, ingen diskution der.
Min pointe var egentligt bare at MySQL mangler locking features, og at postgresql kan være en løsning i de situationer.
Nu er transaction isolation level serializable en optional feature. Du skal specifikt angive at din transaktion skal bruge det. Men sandt nok, hvis du bruger den bliver dine reads nødt til at vente på dine writes.
Men altså, min påstand var at postgresql ikke lader writes blokere reads, din helt rigtige modpåstand er at hvis du essentielt beder databasen om at serialisere alle transaktioner så gør den det, og så kan den selvfølgelig ikke undgå det... Fair nok, ingen diskution der.
Min pointe var egentligt bare at MySQL mangler locking features, og at postgresql kan være en løsning i de situationer.
Vis os det sted i standarden der siger, at sådan en transaktion aldrig kan fejle. Eftersom det er umuligt at implementere transaktioner på en måde, hvor de aldrig fejler, så tror jeg ikke standarden siger det. (Hvis netforbindelsen mellem klient og server forsvinder eller serveren genstarter vil transaktioner fejle, med mindre koden på klientsiden kan genoprette forbindelsen. Og hvis databasen faktisk gemmer nok data til at klienten kan reconnecte efter det, så har du et andet problem, hvis en klient går ned. Serveren kan ikke vide, om det bare er en midlertidig netværksglitch, og derfor er den nødt til at bevare den tilstand for evigt).arne_v (43) skrev:Der vil ikke komme en fejl hvis de blev udført serielt.
Den semantik du påstår serializable transaktioner har betyder at det aldrig kan lade sig gøre for serveren at udføre to parallelt, uanset hvad de foretager sig.
Hvis den første transaktion har læst noget fra tabel A og den anden transaktion har læst noget fra tabel B, så kan serveren ikke garantere, at de aldrig kan nå i en situation, hvor den ene transaktion vil fejl. Den kan ikke vide, om de en gang senere i transaktionerne beslutter sig for at ændre de værdier hinanden har læst.
Man kan selvfølgelig implementere det, så man aldrig kører mere end en af den slags transaktioner ad gangen. Men hvis man implementerer det på den måde, så gør man jo hver eneste serializable transaktion til et DoS angreb på sin database. Og hvis nu en klient går ned uden at lukke sin transaktion, så kan man aldrig mere udføre opdateringer på sin database, for det kunne jo være klienten engang kom tilbage, og i så fald må transaktionen ikke fejle.
Kort sagt. Databaseklienter er nødt til at kunne håndtere at en transaktion fejler, og prøve igen. Du kan forsøge at reducere hyppigheden af fejlende transaktioner, men du kan aldrig forhindre dem helt.
#45
Her er et større billede
Jeg kan i øvrigt ikke se ret meget på dit screenshot, opløsningen er simpelhen for ringe til mine øjne.
Her er et større billede
m_abs (45) skrev:Gælder det ikke kun kerne opdateringer på ubuntu?
Det gælder også opdateringer til X, fx. ny driver til grafikkort. I så fald kan man nøjes med at logge ud og så ind igen, men forskellen er irrelevant for den typiske Ubuntu-bruger.
Til gengæld er det noget man blot kan lade være med. Man bliver ikke plaget med det indtil man gør det. Og det sker ikke af sig selv hvis man forlader computeren i 10 minutter.
Udfra det kan jeg ikke se, hvad der blev opdateret. Men jeg kan da se, at du får lov til at selv bestemme, om du vil genstarte med det samme. Det er langt bedre end f.eks. Mac OS X, hvor du ikke får noget valg. Og Mac OS X siger at de mest latterlige ting kræver en genstart, f.eks. kræves der vist en genstart bare fordi man har installeret nye video codex.squad2nd (48) skrev:#45Jeg kan i øvrigt ikke se ret meget på dit screenshot, opløsningen er simpelhen for ringe til mine øjne.
Her er et større billede
Hvad der kræver genstart på Linux afviger nok ikke ret meget mellem distributioner. Der er nok større forskel på, hvor omhyggelige de er til at fortælle dig, at en genstart er krævet.
Hvis f.eks. glibc er blevet opdateret skal alle processer genstartes for at det får effekt. Det kan gøres uden at genstarte maskinen, men det kræver en genstart af alle services, hvilket kan gøres én ad gangen i baggrunden. Jeg ved ikke, hvordan Ubuntu håndterer det. På Fedora bliver sshd automatisk genstartet ved opdatering af glibc, alt andet må du selv tage dig af.
En genstart er den nemmeste måde at garantere at opdateringen er i brug til alt. Det er forholdsvist nemt at undersøge hvilke processer, der bruger den gamle udgave af et program eller et library, men det er mere besværligt at finde ud af, hvilke af dem, der udgør et sikkerhedsproblem, og hvordan de kan genstartes uden en genstart af computeren.
Posix burde have et reexec signal man bare kunne sende til alle processer for at fortælle dem, at de skal reexec sig selv for at opdateringer tager effekt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund