mboost-dp1
Larry Ewing
Jeg glæder mig i kæmpe grad til at se hvad alle linux-fans'ne siger til det her - det kræver bare de lige er færdige med at flame Windows i en anden tråd :D
Men for fa'en, de er bare mennesker... Jeg får jo ikke en nyhed på Newz hvis jeg er uenig med kæresten en dag, om f.eks. den rackserver jeg har til at stå og skrige? :P
Men for fa'en, de er bare mennesker... Jeg får jo ikke en nyhed på Newz hvis jeg er uenig med kæresten en dag, om f.eks. den rackserver jeg har til at stå og skrige? :P
puttitat (5) skrev:Jeg får jo ikke en nyhed på Newz hvis jeg er uenig med kæresten en dag, om f.eks. den rackserver jeg har til at stå og skrige? :P
<offtopic>Har du en rackserver hjemme privat? Nu ved jeg ikke hvad du laver, men det lyder godt nok lidt vildt.</offtopic>
Kan da godt se Torvalds pointe i, at det er problematisk, hvis et enkelt program gør mange andre programmer ubrugelige.
Synes omvendt at det er barnligt at skændes om hvor fejlen ligger. Uden at have undersøgt noget, kan kodefejlen ligge hos begge parter. Hvis Cox mener, at den ligger i kernen, så hvis hvorhenne eller hvis hvorfor tty ikke er fejlbehæftet. At flame hinanden bærer sjældent noget konstruktivt med sig.
Synes omvendt at det er barnligt at skændes om hvor fejlen ligger. Uden at have undersøgt noget, kan kodefejlen ligge hos begge parter. Hvis Cox mener, at den ligger i kernen, så hvis hvorhenne eller hvis hvorfor tty ikke er fejlbehæftet. At flame hinanden bærer sjældent noget konstruktivt med sig.
#9 er ikke så vant til at mailingslisters opbygning, men nu fandt jeg det, og efter at have læst videre, så tror jeg at Cox kommer til at fortsætte arbejdet med tty.
Han virker for interesseret i det til at kunne lægge det fra sig. Han tager nok en lille pause, men så får han en masse idéer og begynder at lege lidt med noget kode og pludselig er han i gang igen.
Han virker for interesseret i det til at kunne lægge det fra sig. Han tager nok en lille pause, men så får han en masse idéer og begynder at lege lidt med noget kode og pludselig er han i gang igen.
Forskellen er vel at kun community-projekter som Linux tillader sådanne fejl.arne_v (16) skrev:Der er jo ikke noget nyt i at udviklere har forskellige opfattelser af hvor et problem skal fixes og hvordan det skal fixes.
Jeg kan ikke lige se at 2 udviklere der bliver sure på hinanden hos Microsoft, publisher en Windows Update patch, som ødelægger "Log På Som" funktionaliten.
Og jeg kan slet ikke se hvordan det på noget punkt kan være rigtigt at ødelægger user-software, bare fordi man mener der er fejl i Kernel.
windcape (17) skrev:Forskellen er vel at kun community-projekter som Linux tillader sådanne fejl.
De tillader det jo heller ikke. De er bare uenige om hvordan det skal fixes.
JensOle (18) skrev:De tillader det jo heller ikke. De er bare uenige om hvordan det skal fixes.
Alan Crox skrev:I don't know where you got that idea from. Avoiding breaking user space unneccessarily is good but if its buggy you often can't do anything about it.
Sådan en holdning er ikke tilladt på kommercielle platforme, svjv.
windcape (17) skrev:Forskellen er vel at kun community-projekter som Linux tillader sådanne fejl.
Alle projekt typer resulterer i forskellige former for fejl.
windcape (17) skrev:Jeg kan ikke lige se at 2 udviklere der bliver sure på hinanden hos Microsoft, publisher en Windows Update patch, som ødelægger "Log På Som" funktionaliten.
Måske ikke lige den, men lignende ting er set.
MS C/C++ 7.0 (ikke at forveksle med MSVC++ 7.0) ændrede offset for time_t fra 1-JAN-1970 til 31-DEC-1899.
Der var gode grunde til det - det var fra Unix standard til OLE standard.
Men begejstringen hos udviklerne var behersket, da det breakede alt kode som havde lavet antagelser om offset.
Edit: og den blev ændret tilbage i næste version.
windcape (17) skrev:Og jeg kan slet ikke se hvordan det på noget punkt kan være rigtigt at ødelægger user-software, bare fordi man mener der er fejl i Kernel.
Det er jo så også et af de vægtige argumenter i debatten.
Men nogen gange kan det være meget svært at fixe en fejl uden at breake kode som er lavet der forudsætter tilstedeværelsen af fejlen.
windcape (19) skrev:Sådan en holdning er ikke tilladt på kommencielle platforme, svjv.
Det kan også ske på kommercielle platforme.
Men bliver business side spurgt om de vil have århundredets værste hack der er transparent for brugerne eller have det fixet rigtigt men hvor brugerne skal gøre et eller andet, så er der 99.9999% sikkert at de foretrækker det første.
#19, Linus svarer jo saa ogsaa med:
Hvilket kommer lidt som en overraskelse for mig. Jeg ville da umiddelbart tro at man kunne gradboeje det spoergsmaalet om hvorvidt det bliver brugt. Hvis den eneste applikation der afhaenger af noget u-intuitiv funktionalitet er kdesu, som ifg. Alan Cox er grimt kodet, saa synes jeg da man skal aendre det i kernen og kdesu.
Saa vidt jeg forstaar er dette en del af Linux som er Linux-specifik, dvs. dens funktionalitet bliver ikke udpenslet i en standard (ala POSIX). Saa lige meget hvad man goer har man altsaa ikke brudt nogen loefter.
SVJV er Linux-API'et til drivere ustabilt (dvs. det kan aendres ved hvert eneste release), og saa kunne man formode at det ogsaa galt udadtil. Men saadan er det aabenbart ikke (ifg. Linus).
We don't do regressions. If user space depended on old behavior, we don't
change behavior.
Hvilket kommer lidt som en overraskelse for mig. Jeg ville da umiddelbart tro at man kunne gradboeje det spoergsmaalet om hvorvidt det bliver brugt. Hvis den eneste applikation der afhaenger af noget u-intuitiv funktionalitet er kdesu, som ifg. Alan Cox er grimt kodet, saa synes jeg da man skal aendre det i kernen og kdesu.
Saa vidt jeg forstaar er dette en del af Linux som er Linux-specifik, dvs. dens funktionalitet bliver ikke udpenslet i en standard (ala POSIX). Saa lige meget hvad man goer har man altsaa ikke brudt nogen loefter.
SVJV er Linux-API'et til drivere ustabilt (dvs. det kan aendres ved hvert eneste release), og saa kunne man formode at det ogsaa galt udadtil. Men saadan er det aabenbart ikke (ifg. Linus).
Brugerne er nok uenige.ysangkok (22) skrev:Hvis den eneste applikation der afhaenger af noget u-intuitiv funktionalitet er kdesu, som ifg. Alan Cox er grimt kodet, saa synes jeg da man skal aendre det i kernen og kdesu.
Løsningen er at skrive en form for adapter eller proxy funktionalitet, som så kan deprecates om en 2-3 versioner.
windcape (23) skrev:Løsningen er at skrive en form for adapter eller proxy funktionalitet, som så kan deprecates om en 2-3 versioner.
Det er ofte lettere sagt end gjordt i den her slags sager.
De har brug for at:
- korrekt kodede apps kalder den nye kode
- apps kodet til fejlen kalder adapter som kalder den nye kode
- der ikke skal rettes i hverken korrekt kodede apps eller i apps kodet til fejlen
ysangkok (22) skrev:Saa vidt jeg forstaar er dette en del af Linux som er Linux-specifik, dvs. dens funktionalitet bliver ikke udpenslet i en standard (ala POSIX). Saa lige meget hvad man goer har man altsaa ikke brudt nogen loefter.
Stabile API'er (inkl. semantik) er generelt en god ting uamset om det er standardiseret eller ej.
Linux udviklere slås, råber og skriger.
Microsoft udviklere hader hinanden.
Apple udviklere får bare pisk.
Microsoft udviklere hader hinanden.
Apple udviklere får bare pisk.
@29 & 30
Fuldstændigt off-topic, men kommer til at tænke på en joke fra Robin Williams - Live on Broadway:
"So Mr. Gates. When did you realise that you had monopoly.
-Sir, monopoly is just a game, i'm trying to rule the fucking world.
And soon its not just gonna be Information Technology, but Total Information Technology. Or TIT.
And when your sucking on the TIT, we've got you by the motherboard...
;-)
Fuldstændigt off-topic, men kommer til at tænke på en joke fra Robin Williams - Live on Broadway:
"So Mr. Gates. When did you realise that you had monopoly.
-Sir, monopoly is just a game, i'm trying to rule the fucking world.
And soon its not just gonna be Information Technology, but Total Information Technology. Or TIT.
And when your sucking on the TIT, we've got you by the motherboard...
;-)
I don't know where you got that idea from. Avoiding breaking user space unneccessarily is good but if its buggy you often can't do anything about it.
-----------------------
Sådan en holdning er ikke tilladt på kommercielle platforme, svjv.
Nej, den er nok ikke tilladt, men det ændrer jo ikke folk i at have den og argumentere for den (holdningen, altså!). Kommercielle udviklere udtaler sig til deres chef om det på lukkede mailinglister, bliver sat på plads og gør det ikke igen - men tænker nok stadig sådan og bliver depressiv. Community udviklere poster det på officielle mailinglister og bliver pishamrende sure på hverandre, på omtalte mailingliste, får råbt et øre af og falder derefter (ofte) ned igen - også fortsætter arbejdet.
Jeg ved godt hvad jeg vil foretrække.
Forskellen er vel at community-udviklere rent faktisk kan publisere en patch til kørende systemer, uden at have en chef der kigger dem tungt i nakken!ZiN (32) skrev:Community udviklere poster det på officielle mailinglister og bliver pishamrende sure på hverandre, på omtalte mailingliste, får råbt et øre af og falder derefter (ofte) ned igen - også fortsætter arbejdet.
I en sag som denne her savner jeg lidt et centralt sted at placeret ansvaret.
@windscape og andre der sammenligner dette med at publicere en patch der ødelægger windows-funktionalitet på 'et kørende system':
Der er for pokker da ikke tale om at patchen er blevet rullet ud i distributionerne endnu. Det er ikke som at hente en patch fra Windows Update der har uheldig effekt på enkelte applikationer (den slags sker desværre, både i Windows og i Linux, men dette er ikke tilfældet her). Det der sker er at en patch i *udviklingsfasen* har denne effekt.
Nu ser vi hvad der sker, og om det ikke kan blive løst på en måde der både forhindrer regressions, og sørger for at koden kan blive 'pæn'.
Men skulle det ske at Alan Cox skulle have ret, så kan man ikke andet end bifalde den åbne udviklingsproces, der rent faktisk giver kdesu's udviklere mulighed for at opdage denne slags problemer i god tid, og arbejde sammen med kernel-folkene om en fornuftig løsning.
Der er for pokker da ikke tale om at patchen er blevet rullet ud i distributionerne endnu. Det er ikke som at hente en patch fra Windows Update der har uheldig effekt på enkelte applikationer (den slags sker desværre, både i Windows og i Linux, men dette er ikke tilfældet her). Det der sker er at en patch i *udviklingsfasen* har denne effekt.
Nu ser vi hvad der sker, og om det ikke kan blive løst på en måde der både forhindrer regressions, og sørger for at koden kan blive 'pæn'.
Men skulle det ske at Alan Cox skulle have ret, så kan man ikke andet end bifalde den åbne udviklingsproces, der rent faktisk giver kdesu's udviklere mulighed for at opdage denne slags problemer i god tid, og arbejde sammen med kernel-folkene om en fornuftig løsning.
#33:
Jah, som så. De eneste der bliver møg sure på dem er deres brugere, som fungerer som deres "chefer". :)
Det kan jeg godt forstå. I dette tilfælde vil løsningen placere ansvaret; Enten er det Linus' ansvar og kernel'en bliver ændret eller også er det Cox' ansvar og TTY bliver fikset (mest sandsynlig, vil jeg mene).
Det er ikke fordi der ikke er struktur; Her er det bare mere den enkelte udvikler der er ansvarlig for sit eget arbejde; Han har jo heller ikke udgivet patchen som har lagt ALLE Linux distroer ned (alt Linux har jo TTY); Den er blevet sat til unstable/testing o.l., og blevet vurderet ustabil pga. dette, så, eh, det skal fikses.
What I'm trying to say is:
Strukturen testing, preprod, prod osv. er der - den eneste forskel er at du tager ansvar for dit arbejde - HELE VEJEN igennem, hvorimod kommerciel udvikling (og support m.v.) er langt mere firkantede og beskyttede. At tage ansvar fra en udvikler får ham til at føle sig mindre betydelig, og det går ud over arbejdsmoralen.
Forskellen er vel at community-udviklere rent faktisk kan publisere en patch til kørende systemer, uden at have en chef der kigger dem tungt i nakken!
Jah, som så. De eneste der bliver møg sure på dem er deres brugere, som fungerer som deres "chefer". :)
I en sag som denne her savner jeg lidt et centralt sted at placeret ansvaret.
Det kan jeg godt forstå. I dette tilfælde vil løsningen placere ansvaret; Enten er det Linus' ansvar og kernel'en bliver ændret eller også er det Cox' ansvar og TTY bliver fikset (mest sandsynlig, vil jeg mene).
Det er ikke fordi der ikke er struktur; Her er det bare mere den enkelte udvikler der er ansvarlig for sit eget arbejde; Han har jo heller ikke udgivet patchen som har lagt ALLE Linux distroer ned (alt Linux har jo TTY); Den er blevet sat til unstable/testing o.l., og blevet vurderet ustabil pga. dette, så, eh, det skal fikses.
What I'm trying to say is:
Strukturen testing, preprod, prod osv. er der - den eneste forskel er at du tager ansvar for dit arbejde - HELE VEJEN igennem, hvorimod kommerciel udvikling (og support m.v.) er langt mere firkantede og beskyttede. At tage ansvar fra en udvikler får ham til at føle sig mindre betydelig, og det går ud over arbejdsmoralen.
Når man bare kan fralægge sig ansvaret fra den ene dag til den anden, uden nogen indvirkning på ens position, er jo så ret skræmmende.ZiN (35) skrev:eller også er det Cox' ansvar og TTY bliver fikset (mest sandsynlig, vil jeg mene).
Det er ikke fordi der ikke er struktur; Her er det bare mere den enkelte udvikler der er ansvarlig for sit eget arbejde; Han har jo heller ikke udgivet patchen som har lagt ALLE Linux distroer ned (alt Linux har jo TTY);
Cox bør aldrig tildeles ansvar igen, overhovedet.
#33
Alle open source projektet kører ikke ens.
Nogle er mere centraliserede and andre.
Linux er et af de mere decentraliserede. Bl.a. fordi Linus foretrækker det på den måde.
RMS foretrækker en lidt mere centraliseret model.
Og så er der de projekter som har en BDFL.
Bredt spektrum.
Alle open source projektet kører ikke ens.
Nogle er mere centraliserede and andre.
Linux er et af de mere decentraliserede. Bl.a. fordi Linus foretrækker det på den måde.
RMS foretrækker en lidt mere centraliseret model.
Og så er der de projekter som har en BDFL.
Bredt spektrum.
#36: Så, og nu antager jeg at vi bare snakker om denne ene incident, hvis man er en skide god programmør (som jeg er rimelig overbevist om at Cox er), og man laver en "fejl" som denne, i et kommercielt projekt, så bliver man fyret?
Han har ikke aflagt sig ansvaret; Tværtimod har han stadig ansvaret - han skrev til mailinglisten at han mener det er en fejl i kernen - som Linus så er uenig i - de udarbejder det og løser problemet, på en eller anden vis. Hvis han havde fralagt sig ansvaret havde han jo bare stoppet al kommunikation og bare ingenting gjort.
Personligt synes jeg, at det er fint at han tør (og nok vigtigst af alt KAN) sige, at der er noget galt med kernelen, og at det bør ændres. At han så går ud og laver et så dristigt træk som at ligge patchen ud til "offentligheden" er så lidt mindre smart... Men det betyder ikke at han bør fratages alt ansvar for evigt. Det er for dumt.
#37: Gå i seng. :-P
Han har ikke aflagt sig ansvaret; Tværtimod har han stadig ansvaret - han skrev til mailinglisten at han mener det er en fejl i kernen - som Linus så er uenig i - de udarbejder det og løser problemet, på en eller anden vis. Hvis han havde fralagt sig ansvaret havde han jo bare stoppet al kommunikation og bare ingenting gjort.
Personligt synes jeg, at det er fint at han tør (og nok vigtigst af alt KAN) sige, at der er noget galt med kernelen, og at det bør ændres. At han så går ud og laver et så dristigt træk som at ligge patchen ud til "offentligheden" er så lidt mindre smart... Men det betyder ikke at han bør fratages alt ansvar for evigt. Det er for dumt.
#37: Gå i seng. :-P
windcape (36) skrev:Når man bare kan fralægge sig ansvaret fra den ene dag til den anden, uden nogen indvirkning på ens position, er jo så ret skræmmende.
Cox bør aldrig tildeles ansvar igen, overhovedet.
Hvis han virkelig vælger at gøre dette, er der sikkert en masse der gerne vil overtage hans ansvarsområde. "Systemet" er jo i bund og grund lavet sådan, at enhver kan komme med en løsning.
Du kan jo se om du kan løse problemet og få din løsning godkendt.
Det kan være du er den nye TTY udvikler.
De andre udviklere vil sikkert blive sure over at jeg ikke benytter hungarian notation og underlige forkortelser ;)arne_v (41) skrev:Det ville faktisk være interessant. Windcape arbejde på noget hvor C formentligt er det optimale sprog.
F.eks. "filePointer" eller "filePtr" istedet for "filp". Open-source elsker at lave obscur kode.
Han HAR fralagt sig ansvaret, så vidt jeg kan se er der ingen TTY maintainer lige for tiden.ZiN (38) skrev:Hvis han havde fralagt sig ansvaret havde han jo bare stoppet al kommunikation og bare ingenting gjort.
Men så igen, vi snakker om ~3300 linjers kode, med nice catches som:
#define TTY_PARANOIA_CHECK 1
Og så 1600 linjer senere:
#ifdef TTY_PARANOIA_CHECK
Kvalitetskode, eh? ;)
windcape (42) skrev:De andre udviklere vil sikkert blive sure over at jeg ikke benytter hungarian notation og underlige forkortelser ;)
Hungarian notation er så vidt jeg ved strengt forbudt i Linux kernel.
Den har iøvrigt aldrig været brugt meget udenfor MS verdenen.
windcape (42) skrev:
med nice catches som:
#define TTY_PARANOIA_CHECK 1
Og så 1600 linjer senere:
#ifdef TTY_PARANOIA_CHECK
Kvalitetskode, eh? ;)
Det ser da ganske nydeligt ud !
windcape (42) skrev:De andre udviklere vil sikkert blive sure over at jeg ikke benytter hungarian notation og underlige forkortelser ;)
Meget sjovt.
windcape (42) skrev:
#define TTY_PARANOIA_CHECK 1
Og så 1600 linjer senere:
#ifdef TTY_PARANOIA_CHECK
Kvalitetskode, eh? ;)
Det kommer vel an på hvad der står på de 1600 linjer.
Det kunne jo være, der ver noget #undef TTY_PARANOIA_CHECK
windcape (42) skrev:Han HAR fralagt sig ansvaret, så vidt jeg kan se er der ingen TTY maintainer lige for tiden.
Kom så Windcape - du er jo allerede igang gået i gang.
Men sørg nu for at lave det ordentligt, så det ikke bliver sådan noget Windows agtigt noget.
#23, brugerne er mig selv :D.
Buggen blev afaik introduceret med denne patch: patchwork.kernel.org.
Saa det vil sige den har kun vaeret der for alle de brugere der bruger KDE 4.2 og har en kerne der helt up-to-date (fra efter den 7. i denne maaned).
Jeg tror de brugere kan leve med gksu eller sudo eller lignende i mellemtiden. :D
Nu kan man argumentere for at alle de mennesker som ikke kender til problemet vil faa problemer. Men jeg er overbevist om at det er meget faa mennesker som lider under dette problem.
Buggen blev afaik introduceret med denne patch: patchwork.kernel.org.
Saa det vil sige den har kun vaeret der for alle de brugere der bruger KDE 4.2 og har en kerne der helt up-to-date (fra efter den 7. i denne maaned).
Jeg tror de brugere kan leve med gksu eller sudo eller lignende i mellemtiden. :D
Nu kan man argumentere for at alle de mennesker som ikke kender til problemet vil faa problemer. Men jeg er overbevist om at det er meget faa mennesker som lider under dette problem.
Personligt synes jeg at definitionscheck er en afskyeligt måde at kode på.arne_v (43) skrev:Det ser da ganske nydeligt ud !
Statements ala.
IF true (but might not be true for unknown reason at design-time) THEN
END
virker så forkert i normal logik og tankegang.
At det så måske er den mest *effiktive* måde at løse det på, gør det på ingen måde god kode imo. Burde funktionalitet som TTY netop ikke kunne skrives i C++, og derfor benytte namespaces og en mere OO tankegang til at løse sådanne problemstillinger.
At basere funktionalitet på en global boolean (som så slet ikke er en boolean, men en integer)... Det minder om at kode PHP.
windcape (48) skrev:Personligt synes jeg at definitionscheck er en afskyeligt måde at kode på.
Statements ala.
IF true (but might not be true for unknown reason at design-time) THEN
END
virker så forkert i normal logik og tankegang.
windcape (48) skrev:At basere funktionalitet på en global boolean (som så slet ikke er en boolean, men en integer)... Det minder om at kode PHP.
Det du oprindeligt citerede er ikke en if som testes runtime men noget kode som enten tages med eller ikke tages med på compile time.
To forskellige ting.
windcape (48) skrev:Burde funktionalitet som TTY netop ikke kunne skrives i C++, og derfor benytte namespaces og en mere OO tankegang til at løse sådanne problemstillinger.
Der er skrevet styresystems kerner i andre sprog end C. Men de fleste af dem har brugt low level sprog.
Eksempel: OpenVMS hvor de to mest brugte sprog er Bliss og Macro-32.
Jeg kender ikke noget til programmering af Linux kernel. Men jeg har engang leget med kernel mode kode på OpenVMS.
Og en af de små detaljer der er, at når man hæver IPL over 2 så crasher systemet hvis man forårsager en page fault. Man skal sikre sig at alt det virtuelle memory man skal bruges er loadet ind i fysisk memory. Med noget avanceret høj niveau OO kode, så kan det godt være svært at gennemskue hvilke memory adresser noget kode vil tilgå. I assembler eller super-primitiv C kode kan man nogenlunde gennemskue det.
Jeg er ikke i tvivl om at fremtidens styre systemer vil have en meget lille kerne i C og en masse højniveau uden om.
Det kan lade sig gøre. MULTICS var lavet i PL/I. MS har vist med Singularity at det kan gøres med C#.
Men for en eksisterende kerne i C er man nødt til at fortsætte med at bruge C, fordi kernen er designed til C.
Og der er ikke opfundet et mainstream OS i mere end 15 år, så det er svært at sige, hvornår det næste OS dukker op.
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