Gå til innhold

Omstart? Aldri mer


Anbefalte innlegg

Jepp, jeg er kjent med dine tolkninger og spissformuleringer. Kanskje du også med det samme bør gjøre det klart i en nabotråd her hva din tolkning av dll-hell er, siden den avviker fra alle andres, og slett ikke trenger bety en konflikt mellom dll'er. Samtidig kan du jo bare gi dem link til disse grusomme fanboys som våger å fortsatt berøre begrepet dll-hell. Her har folket lenken:

https://www.diskusjon.no/index.php?session=...&p=10943393

Litt mindre slitsomt enn å nok en gang ta tak i de løsrevne utsagnene dine.

Lenke til kommentar
Videoannonse
Annonse
Jeg tar det tilsvaret ditt med en bøtte salt. Du fremstiller deg selv som en hardbarket fanboy. Det er høyst uklart om du svarer på mine innlegg for mye av det du sier er da helt basiskunnskap og noe alle vet (håper jeg da) og som ikke bestrider noe som helst i mitt innlegg.

 

Heteslaget tror jeg nok kom på en annen kant når jeg ser hvordan du veiver med armene i teksten. Ingenting av det Lime kom med svei, det må du ikke tro, det virket derimot som en oppramsing av selvfølgeligheter med ymse unøyaktigheter i beste fall. Men jeg ser at du og flere ønsker en opphetet debatt rundt Windows vs. Linux.

 

Når begynte du å jobbe med PC siden du forsøker å minne meg på hva den ble brukt til på 80 tallet og tidlig 90 tall? Så du hva de ble brukt til på skoler ol. i disse årtiene? Vet du også hva PCer kostet på 80 tallet siden du sier den var kun rettet mot hjemmebrukere?

 

Uansett en tåpelig diskusjon du har begitt deg innpå her. Lime hadde noe relevant helt i slutten av sitt innlegg som fenderebest kommenterte.

Jeg er ingen fanboy, og det vet du godt. Jeg bruker Windows mye, spesielt til spilling, og har til og med kjøpt Vista.

 

Det er vel du som ble satt på plass, men det har ingen betydning for meg. Når folk sprer usannheter i slike diskusjoner så griper jeg inn, uavhengig hvem det måtte være. Av mangel på argumenter så må du altså tøye i mine utsagn, jeg sa at PCen var rettet mot hjemmebrukere. Jeg kjenner til flere lokale bedrifter som brukte slike PCer som "arbeidsstasjoner" tidlig på 80-tallet, selv om det fantest bedre løsninger som var spesialisert på bruksområdet. PCen ble i stor grad benyttet av hjemmebrukere, til tross for prisen som var nær en grei bruktbil.

Lenke til kommentar
Akkurat det har jeg faktisk aldri noensinne opplevd (på GNU/Linux selvsagt). Aldri et problem som ikke lar seg løse av å restarte X og/eller drepe noen prosesser. Nærmeste jeg har kommet var da jeg kortsluttet en USB-enhet jeg drev og bygde noe som resulterte i totalfrys (måtte bruke av/på-knappen på strømforsyninga) for å løst floka.

 

Jeg har opplevd det mange ganger. Det er akkurat Intel driveren som sug, den har fungert på de tidligere versjonene av Ubuntu, men nå ser det ut som at det er gjort en større endring. Når driveren krasjer fungerer ingenting. Det eneste som funker er svenskeknappen. :D Det er en post i ubuntuforums.org som sier hvordan man fikser intel drivere, men jeg har enda ikke giddet å teste det ut.

Lenke til kommentar
En åpen fil i minnet er knyttet i Windows gjennom et Handle. Så lenge prosessen har en åpen handle til filen kan den ikke skrives til. Om du stenger handelen til filen - feks via Process Explorer kan filen overskrives. (Så lenge det ikke eksisterer data i minnet som ikke er blitt skrevet til disk.)

 

Der er dermed ikke nødvendig å starte hverken prosessen eller Windows på nytt for å gjøre dette.

 

Grunnen til at Windows startes på nytt er rett og slett at det fører til mindre problemer. Som regel er det ingenting teknisk sett som forhindrer dette men bare at det generelt sett fungerer bedre.

 

Jeg ser at mange forsøker å debunke innlegget mitt, men alle motinnleggene har akkurat dette argumentet til Fendererbest som aksiom, så jeg skal forsøke å tilbakevise dette.

 

Jeg forsøkte å forklare ting med et forståelig og lett språk, men det er jo litt mer teknisk enn den lettere populistiske forklaringen jeg kom med.

 

Fendererbest har helt rett når han sier at det bare er å lukke filehandelen ved hjelp av en tredjepartsapplikasjon som kan kontrollere kjernen, slik som Sysinternals Process Explorer, og på den måten kunne overskrive en prosess' åpne filer.

 

Jeg har heller aldri påstått at det ikke går. Påstanden min var: "at man alltid kan stole på at når en prosess har åpnet en fil, så er det eksklusivt. Ingen andre kan endre på denne filen. Prosessen har full kontroll.". Dette er et grunnleggende premiss i Windows-verdenen. Det betyr at tusenvis, om ikke millioner av programmer er avhengige av at operativsystemet fungerer slik. Alltid. Tukler du med det, så brekker du potensielt alle programmer som forventer at det skal være sånn.

 

Fendererbest: Prøv å dra vekk filhandler fra prosesser som f.eks. System, svchost.exe, smss.exe og lignende og se hvor stabilt systemet ditt er etterpå.

 

Men jeg kan til dels ta til meg litt av kritikken siden det var en ting jeg ikke tok opp i det hele tatt i det forrige innlegget mitt. Nemlig hvordan Windows takler at man skriver over en executable fil som er mappet til minne. Forsøk: Prøv å overskrive explorer.exe. Windows vil ikke la deg gjøre det. Du kan hacke litt for å få det til, men det vil garantert få explorer.exe til å krasje.

 

Microsoft har flere workarounds til dette. Du kan avslutte prosessen, overskrive, og starte den igjen. Du kan også bruke noen va microsofts verktøy, for eksempel http://support.microsoft.com/default.aspx?...kb;en-us;228930 som lar deg markere filer for overskriving ved neste omstart (ja her har vi omstartsproblematikken), eller APIet Restart Manager: http://msdn.microsoft.com/en-us/library/aa...28VS.85%29.aspx som Microsoft Installer har støtte for.

 

Så igjen, problemet er designet til Windows:

 

1) Programmer forventer at åpne filhandler ikke endres, noe som leder til:

a) Operativsystemet beskytter åpne filhandler, ved å ikke la deg overskrive åpne filer

b) Programmer som forventer at filhandelen er åpnet eksklusivt av det får problemer om a) ignoreres (f.eks. ved at man leter opp filhandelen og stenger den manuelt).

2) Eksekverbare filer som er mappet til userspace minne, kan ikke overskrives.

Lenke til kommentar

Huff, jeg burde holde meg for god for dette, men :/

La oss ta dette innlegget bit for bit.
Jeg vil gjerne komme med litt teknisk informasjon til alle dere som diskuterer om Windows eller Linux er best når det gjelder omstarter.
Som jeg sa tidligere, ingen har diskutert dette så en slik uttalelse minner om forsøk på trolling eller oppvigleri.

Du kan heller ikke lest mange av innleggene siden du tror vi mangler såpass teknisk innsikt?

Se innlegg #12-17 og #23.

 

La oss først slå fast fakta: Det er et teknisk problem. Plattformen Windows er årsaken.
Jøss, sier du det? Ja for det er vel windows man snakker om i den sammenhengen?

Ja, rett og slett, og det tar innlegget mitt grundig for seg.

 

Og så får jeg forklare litt.
Og her kommer mer av det opplagte regner jeg med.

Hva forsøker du å si her?

 

Windows startet den gangen en PC var en enbrukerting.
Hm, sikker på at du tar helt feil her. Kan du dokumentere at ingen PCer kjørte noen form for flerbruker OS på denne tiden? Forøvrig startet Windows mye senere enn PC.

 

Personal Computer er det visst en forkortelse for.
Jeg som alltid har trodd det stod for Personal Calculator. Hvem er målgruppen din her, for det kan jo ikke være denne tråden. :nei: Forøvrig er det ingen knytning mellom navnet PC og hvorvidt OSet som puttes på den er enbruker eller flerbruker.

Jeg tok dette med fordi jeg gikk ut ifra at folk forstod sammenhengen mellom ordet "Personal" og "Enbruker". En datamaskin per bruker. En stor kontrast til flerbrukersystemer med flere terminaler koblet til, som var det store før pcen kom.

 

Unix fra bunnen av en flerbrukerplattform. Den arven har Linux også.
Du vet tilfeldigvis ikke hva Unix stammer fra. Om du googler det vil du se at det er opplagt at den har et flerbrukerfokus. Noe som ikke er like opplagt om du ser på hva Linux ofte brukes til i dag.

Dette tok jeg med for å illustrere hvorfor det er et problem på Windows, og ikke på Linux. Enbrukerfokuset Windows springer ut fra gir direkte utslag i mange omstarter i dag. Flerbrukerfokuset til Unix, og også Linux gjør at man ikke kunne forvente at f.eks. filer var åpnet eksklusivt, eller at koden til en prosess aldri ble endret etter at prosessen var startet. Dermed sitter man i dag og kan overskrive programmer som er i bruk, og filer som er åpne. Dette har jeg forklart mer utfyllende i et svar til fenererbest.

 

Windows har blitt utvidet til å ha støtte for flere brukere, men arven som et enbrukersystem er der den dag i dag.
Noe sier meg at du ikke har jobbet mye teknisk med Windows. Du har fått med deg NT? Hva tror du fokuset var med NT?

Resten følger litt i samme stil selv om det forsøker seg med en teknisk vinkling. Fenderbest svarer også godt på akkurat det.

Jeg har jobbet ganske mye med Windows, Unix og Linux de siste 10 årene. Jeg er godt kjent med problematikken med åpne filer både fra Unix-siden og Windows-siden. Fokuset med NT var å lage et flerbrukersystem som var binærkompatibelt med Microsofts tidligere operativsystemer. Inkludert alle tidligere "snarveier" og problemer.

 

I tillegg mistenker jeg, men det får stå for min egen kappe, så var fokuset å gjøre det ukompatibelt med andre operativsystemer, slik at ISVer som utviklet programvare til Windows ville få det veldig vanskelig å porte applikasjonene til andre plattformer. Men det er en helt annen diskusjon.

Lenke til kommentar
Er du Ubuntu 9.04-bruker trenger du aldri mer omstarte maskinen din.

 

Tja, slår nå av PCen hver dag jeg da... Ser ikke poenget med å la den stå på når den starter opp på 15 sekunder.

 

Men, kan se behovet for servere...

Lenke til kommentar
Installerte dette, og for litt siden så poppet beskjeden "venligst restart maskinen". :p .

Mitt spørsmål må da være, hvordan får man slettet Ksplice fra ubuntu?

Med din favoritt pakkebehandler naturligvis. Du finner den fort i Add/Remove Programs eksempelvis.
Lenke til kommentar
Misvisende navn på tråden, jeg har flere ganger fått beskjed om å restarte ubuntu 9.04 pga oppdateringer.

Du burde lese artikkelen!.

Jeg har det. Og som jeg sa, artikkelnavnet er misvisende. Teksten du får på RRS-feeden også. "er du ubuntu 9.04 bruker trenger du aldri omstarte maskinen". Det stemmer langt ifra.

 

 

Når jeg tidligere har vært innom Ubuntu, 8.10 var siste versjon jeg brukte, så fikk jeg beskjed om omstart etter oppdateringer, hvor andre distroer kun har bedt meg logge ut og inn igjen eller ikke sagt noe. Har stusset litt på hvorfor dette forekom oftere i ubuntu enn de andre distroene jeg har testet (over litt lengre tid, men får vel ta ett lite forbehold om dårlig huskommelse ;)). En mulighet er at det er enklere å be brukeren om en omstart (kanskje dette gjelder i noe grad windows også, etter diskusjonen over å dømme), selv om det strengt tatt ikke er helt nødvendig. En omstart er vel enklere å forstå, enn f. eks å bli bedt om å restarte X.

Lenke til kommentar

Normalt sett bør ikke å lukke en handle til et filobjekt føre til stabilitetsproblemer. Det som skjer når prossessen vil ha tilgang til et filobjekt er bare at det sjekker i objektmanageren om den har et handle og om ikke lager et nytt.

 

Grunnen til at du skal stenge handlet til filobjektet er slik at prosessen ikke får tilgang til filen idet den oppdateres.

 

Videre er det problem med å overskrive åpne filer i minnet jeg lurer litt på hvordan Linux håndterer:

 

1.Prosess A åpner Fil A. (Bare en liten del av den)

2.Fil A blir endret i minnet.

3.Prosess B overskriver formatet i Fil A fysisk på disk.

4.Dermed kan ikke endringene i Fil A bli skrevet tilbake til disk når formatet ikke lenger passer.

Endret av fenderebest
Lenke til kommentar

Sjekket du Perl dokumentasjonen for full beskrivelse av funksjonene slik den første man-siden tipset deg om? Jeg tenkte kanskje dette var en lettere vei, siden du er i MS-verden hvor terminologien er annerledes. Jeg er også litt usikker på hvilket nivå du ønsker informasjonen, men la meg forsøke.

 

Det første punktet er å forstå at GNU/Linux er POSIX compliant, hvilket gir en god del føringer for hvordan filer håndteres. Blant annet er det du tenker på som handle erstattet med descriptor:

http://en.wikipedia.org/wiki/File_descriptor

 

Dernest bruker GNU/Linux fra og med 2.6 kjernen RCU, som er meget godt forklart her:

http://en.wikipedia.org/wiki/Read-copy-update

 

I tillegg er alle endringer, og forklaringer på hvordan dette håndtere i siste 2.6.30 kjerne beskrevet her:

http://www.mjmwired.net/kernel/Documentati...stems/files.txt

 

Hvis du fortsatt synes det er vanskelig å få tak på hvordan filer håndteres kan du jo bare teste litt. med lsof går det som en lek, og du kan selv kjapt sjekke ut hvordan det funker med eksempelvis Perl.

Lenke til kommentar

Jeg er ikke egentlig ute etter hvordan det gjøres programmeringsmessig osv men mere på generelt grunnlag. Jeg skal prøve å forklare litt grundigere:

 

1.Prosess A har da som sagt en fil åpen i minnet med data som har blitt endret men ikke enda skrevet til disk.

1.Prosess B ser at Prosess A har en fil åpen i minnet men pga at filen er kritisk for Prosess A kan den ikke stenges.

3.Prosess B må da finne en mekanisme som garanterer at Prosess A skriver uendrede data til disk FØR Prosess B skriver over filen.

 

Med mindre Prosess B og Prosess A er spesfikt programert for å kommunisere med hverandre ser jeg ikke noen praktisk måte å gjøre dette på.

 

Det måtte isåfall finnes en felles funksjon for alle prosesser som kan aktiveres for å garantere at prosesser med åpne filer skriver endret data til disk før filene endres. Dette ser jeg som litt innviklet å gjennføre i praksis.

 

Lurte litt mere på om lime feks kunne forklare dette.

Endret av fenderebest
Lenke til kommentar

Jeg er ikke egentlig ute etter hvordan det gjøres programmeringsmessig osv men mere på generelt grunnlag. Jeg skal prøve å forklare litt grundigere:

 

1.Prosess A har da som sagt en fil åpen i minnet med data som har blitt endret men ikke enda skrevet til disk.

1.Prosess B ser at Prosess A har en fil åpen i minnet men pga at filen er kritisk for Prosess A kan den ikke stenges.

3.Prosess B må da finne en mekanisme som garanterer at Prosess A skriver uendrede data til disk FØR Prosess B skriver over filen.

 

Med mindre Prosess B og Prosess A er spesfikt programert for å kommunisere med hverandre ser jeg ikke noen praktisk måte å gjøre dette på.

 

Det måtte isåfall finnes en felles funksjon for alle prosesser som kan aktiveres for å garantere at prosesser med åpne filer skriver endret data til disk før filene endres. Dette ser jeg som litt innviklet å gjennføre i praksis.

 

Lurte litt mere på om lime feks kunne forklare dette.

 

Det er ingen vits å gjøre det vanskeligere enn det er. Det som skjer er at sistemann som skriver til filen, har skrevet til filen.

 

Skriver prosess a til filen, og så prosess b, og så a igjen. Så er det a sine data som er lagret.

 

Når dette er sagt, så er det mulig å få til fil låsing i Unix-verdenen også, men det gjøres ikke på samme måte som i Windows. Litt mer info finnes her: http://en.wikipedia.org/wiki/File_locking

Lenke til kommentar
Jeg er ikke egentlig ute etter hvordan det gjøres programmeringsmessig osv men mere på generelt grunnlag.
Det gjøres programmeringsmessig, hver applikasjon bestemmer selv.

 

Eksempelvis Firefox liker å bruke MS-måten, den legger lock på filene slik at du ikke får åpnet en annen instans av Firefox. Det er mitt største ankepunkt mot Firefox.

 

Ofte vil den siste prosessen som skriver til filen overskrive endringer gjort av andre prosesser siden den åpnet filen, enkelt og greit. Det er likevel ingenting i veien for å la applikasjonen sjekke om filen har endret seg siden den ble åpnet, og tilby brukeren diverse alternativ.

 

Gir dette svar på det du lurer på?

Lenke til kommentar
Den løsningen går ikke. Prosess B skriver over filen i en oppdatert versjon av filen. Siden dataene lagret i minnet i Prosess A er formatert etter en eldre versjon vil du ende opp med å gjøre filen korrupt.

 

I realiteten blir ram og disk separert.

Pros A fil ha sin kopi av dette

Pros B har også sin kopi av dette

Den siste som lagerer blir det endelige.

 

Et spørsmål: Hvorfor blir A korrupt?

Har ikke alt for mye peiling, men at den blir korrupt virker ikke logisk.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...