Linus válaszolt a Slashdot olvasóinak kérdéseire

Címkék

Hétfőn a Slashdot olvasóinak lehetősége nyílt arra, hogy bármit kérdezzenek Linustól. A szerkesztők elküldték a legmagasabbra értékelt, legérdekesebb kérdéseket a Linux atyjának, aki válaszolt. Egy kis kedvcsináló :)

Quite frankly, there are a lot of f*cking morons on the internet.

[...]

I still love the GPLv2, and absolutely think that making Linux open source was the greatest thing ever.

[...]

I think microkernels are stupid.

[...]

So I'm very proud of git.

Az esti szórakozás garantált. Erre tessék...

Hozzászólások

Btw, it's not just microkernels. Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. Microkernels had one such ideology, there have been others. It's all BS. The fact is, reality is complicated, and not amenable to the "one large idea" model of problem solving. The only way that problems get solved in real life is with a lot of hard work on getting the details right. Not by some over-arching ideology that somehow magically makes things work.

--
Live free, or I f'ing kill you.

azért linusnak csak részeben van igaza. ha megnézzük a természet tudományt ott is mindig vannak ilyen átfogó "ideológiák"/elméleti keretek/paradigmák, amit aztán össze vissza barkácsolnak, hogy lefedje a sokféle rész jelenséget és amikor elmegy a barkácsolástól a kedvük(részben pont azért, mert aránytalanul bonyolult kezd lenni a dolog) és rendelkezésre áll egy másik alternatíva akkor jön a paradigma váltás.

Csak átfutottam, de semmi meglepő nincs benne, sikerült elkerülni a balfasz énjét.
----
India delenda est.
Hülye pelikán

Aki jól tud angolul, ugyan kérdezze már meg Linust lécci, hogy

1. Kipróbálta-e már a GoboLinuxot?
2. Ha nem, akkor hallott-e már róla egyáltalán?
3. Ha kipróbálta, mi a véleménye róla? (legalábbis az alapötletről, mert azt tudom hogy az aktuális release nagyon régi).
4. Ha nem próbálta ki de hallott már róla, tervezi-e kipróbálni? Ha nem, akkor miért nem?

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Ha már itt tartunk, akkor Hungarian Unix Portal. Ebből melyik szó magyar? És ha egy számítástechnikai, szakmai portálon valaki arra büszke, hogy nem ismer és nem képes megkeresni a szótárban egy angol szót, az véleményem szerint úgy szégyellje össze magát ebben a szent minutumban - ez sincs magyarul, percet jelent - ahogy eddig még soha! Bár manapság dicsőség butának lenni, szeretném azt hinni, itt még nem!

Ave, Saabi.

Rendes arc ez a Linus gyerek, már válaszolt is a levelemre:

1. Sokáig nem is hallott róla, de aztán egy magyarországi ismerőse lefordította neki a Gobolinux könyvedet ekkor kedvet kapott a kipróbálásához. Azóta ez az elsődleges desktopja, a Win 7-et már le is törölte.
2. ld. fent
3. Belátta hogy ez az egyetlen járható út, már dolgoznak rajta, hogy a Gobo könyvtárstruktúrája legyen az alapértelmezett. Jelenleg a Redhat-al folyik az egyeztetés egy Enterprise Gobolinux-ról.
4. ld. fent

--
Sent from my ezeréves Nokia.

Az általad írt első pontra nincs szükség, nem kell hogy lefordítsák Linusnak a gobolinuxos könyvemet, mert a GoboLinux weboldalán minden cikk angolul van, tökéletesen megértené. Csak el kéne olvasnia...

És igen, hiszek benne hogy ha Linus hallana egyáltalán a GoboLinuxról, akkor belátná hogy valóban haladó és jövőbemutató lépés lenne a gobolinuxos könyvtárstruktúrát vagy valami ahhoz nagyon hasonlót bevezetni ha nem is alapértelmezettnek, mert hát ilyesmit nem lehet kötelezően előírni egy FOSS környezetben, de legalábbis ezt ajánlani, afféle "kvázi-szabványként"! Linus szerintem elég értelmes fickó ahhoz, hogy belássa ennek előnyeit. Csak fel kéne hívni rá a figyelmét. És igen, ha a RedHat bevezetné e struktúrát, talán követné ezt idővel a többi disztró is, pláne ha Linus is ajánlaná.

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Nem tudom, visszanéz-e valaki ide, de itt egy idézet:

"I don't think they're equally flawed - I think Leopard is a much better system," he said. "(But) OS X in some ways is actually worse than Windows to program for. Their file system is complete and utter crap, which is scary."

forrás: http://www.theage.com.au/news/technology/torvalds-pans-apples-os-x/2008…

Úgyhogy Zoli, szerintem különösebben nem hatná meg a gobo.

--------------------------------------
Unix isn't dead. It just smells funny.

Gondolni való volt, hogy nem barlangban él és ha ugyan a Gobo-t nem is látta, azért látott már hozzá fogható fájlszerkezetet. Mindenesetre most már Zoli is megnyugodhat egy kicsit. Egyébként minden tiszteletem az övé, mert annak idején sok mindent tanultam a könyvéből. Igaz nem Gobo alatt.

"És igen, hiszek benne hogy ha Linus hallana egyáltalán a GoboLinuxról, akkor belátná hogy valóban haladó és jövőbemutató lépés lenne a gobolinuxos könyvtárstruktúrát vagy valami ahhoz nagyon hasonlót bevezetni"
Miért? A mostani teljesen logikus, ha neked egy Linuxosított Windows kell, akkor egyszerűbb magát a Windowst választani, vagy akár OS X-t, bár ott is jelen vannak a "csúnya" könyvtárak.
Biztosra veheted, hogy Linus ismeri az efféle könyvtárstruktúrát.

Egyébként, ha nem csinálsz semmi speciálisat, akkor Ubuntun rá sem kell nézned a home-on kívül másra.

=Λ=

de az még jobb lenne gondolom, ha a usereknek is egyből egyértelmű lenne mi micsoda, mi hol van, ha ránéznek. kérdés a kettő előnyei egyszerre megvalósíthatóak e. meg eleve a hagyomány itt nagyon erős. ha kicsit jobb is lenne valami az nem érne meg egy ennyire jelentős váltást, csak ha valami erős OK van.
mondjuk lehet ha ma adnák a könyvtárak neveit akkor lehet hosszabb beszédesebb neveket adnának, ha a szerkezet nem is változna.

Troll szövegként azt szoktam mondani, hogy a C++ az a nyelv, ahol több a mellékhatás, mint a normális viselkedés.
Azt tapasztaltam, hogy ahhoz, hogy kulturált programot lehessen írni, sok pótcselekvés helyett (tipikusan az ajánlott másolókonstruktorról meg egyebekről beszélek), kb. az egész nyelvet ismerned kell. Ami meg nagy falat.
Illetve a gcc idétlen hibaüzenetei sem sokat segítenek, szerencsére a clang ebben sokkal fejlettebb.

Ettől függetlenül nem egy olyan C kódot láttam már, ahol OOP szerű működést próbálnak utánozni. Ilyenkor azért elgondolkozok, hogy nem lenne-e sokkal szebb és tisztább megoldás egy OOP nyelvet alkalmazni és annak a megfelelő nyelvi elemeit (pl. interface-k), ahelyett, hogy függvénypointereket tutujgatunk ész nélkül, amivel már fordítási időben el lehetne kerülni egy csomó hibalehetőséget.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem tudom, hogy a GC és az OOP hol függ össze egymással, vagy hogy egyáltalán hol említett bárki is GC-t most.

Csupán arról volt szó, hogy ha C-ben _is_ sokszor OO paradigma szerint hoznak létre objektumszerű képződményeket, akkor miért nem egyből valami OOP-t közvetlenül támogató nyelven fejlesztenek?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

GC úgy jön képbe, hogy ha OO paradigma kell, akkor általában érdemes egy a C++-nál magasabb szintű nyelvet használni (Go, Java, C#, ...).

Ha a GC gáz, akkor jöhet ismét képbe a C++...

Az, hogy vannak sokan, akik a C-t csúnyán használják, még önmagában nem mond semmit a C-ről vagy bármelyik másik nyelvről.

Úgy érted: rengeteget gyorsít a nyelven.
Amúgy úgy szokták mondani, a C++ paraméterátadása nem érték vagy referencia, hanem inicializálás alapú, és ebben nagy igazság vagyon. Szerintem nem rossz, hogy megmondhatod, hogy adódjon át paramétered, és nem akar okosabb lenni a fordító. Ha egy intet is mutatón keresztül kell átadjak, az lassabb lesz, mint egyébként.
----
India delenda est.
Hülye pelikán

A RAII is csak egy tipikus C++-os félmegoldás: a leggyakrabban használt esetet leegyszerűsítjük, majd ezzel olyan hamis illúziót keltünk, amiért többszörösen megfizetünk a ritkán használt esetben, amikor az illúzió összeomlik.

RAII a leggyakrabban használt erőforrás-menedzselési mintát valósítja meg: scope-based lefoglalás és felszabadítás. De egyéb minták is vannak, olyankor pedig a C++-ban be kell vezetni egy újabb indirekciót, és unique/shared pointerbe csomagolhatunk egy pointert. Az egész végső soron annyi kérdést és problémát vet fel, hogy jobban tenné az ember, ha C-t használna és explicit megmondaná, hogy ez az objektum most kell, mostantól pedig már nem kell.

Maga a konstruktor is egy hasonló illúzió: általában gondoskodik róla, hogy az objektum érvényes állapotban legyen, ha már egyszer létrejött, de bizony vannak esetek, amikor az ember előbb hozzáfér egy objektumhoz, mint ahogy a konstruktora lefutott volna. A C-ben éppen az explicitség miatt sokkal könnyebben felismerhetők az ilyen hibák.

Ehhez csak annyit tudok hozzátenni, hogy ha nem értesz hozzá, ne kritizáld. Használd, és tanulj még. A RAII semmit nem mond a scopeokról. Egy RAII objektum, ha úgy és jól írták meg (és tegyük fel, hogy az alaposztályainket jól írják meg, különben minden szar), simán passzolgatható körbe (az általad is említett unique és shared pointer), de ha neked a RAII kimerül a smart pointerben, akkor tedd fel magadnak a kérdést, érdemes-e okosítani a témában.
----
India delenda est.
Hülye pelikán

Már hogyne mondana a RAII a scopre-ról valamit. A RAII alapján egy resource élettartama (scope) pontosan egy objektum (a bennfoglaló) élettartamának felel meg, nem lehet mondjuk egy resource-ot metódus futás scope-jához kötni, és mindezt azért, mert exception dobása esetén csak a destruktor lefutása garantált.

Szerintem nem érted.

A pointer egy indirekciót visz be a játékba, innentől kezdve már két szintről lehet beszélni: a hivatkozás élettartamáról, és a hivatkozott objektum élettartamáról.

Normál esetben az erőforrás-menedzsment csak az objektummal foglalkozik, és a hivatkozás pusztán egy érték. De a túlbonyolított C++-nál más a helyzet, ott maga a hivatkozás is lehet egy objektum, innentől értelmet nyer a hivatkozás keletkezésével és megszűnésével külön foglalkozni.

Ettől még áll, hogy RAII a scope-based erőforrás-menedzsmentre jó, másra viszont (közvetlenül) alkalmatlan.

Nem is az a baj a C++-szal, hogy engedi a RAII-t, hanem az, hogy kvázi kötelezővé teszi, mert máshogy nem lehet exception-safe code-ot írni.

Látom, nem csak a C/C++ téma nem megy, a magyar nyelv is problémás. Nem állítottam, hogy az általam hozott példa a te problémádra van. Azt állítottam, hogy a C++-ban vannak olyan megoldások, amik akár gyorsabbá is teszik a C-nél. C++ sokkal kifejezőbb a paraméterátadásnál, lásd inicializáció alapú paraméterátadás. A fordító erre könnyebben optimalizál, mint a szigorú érték szerinti átadásra.
----
India delenda est.
Hülye pelikán

Az OOP-szerű C kód ugye arra enged következtetni, hogy milyen jó is az OOP. De attól még nem a C++ az egyetlen OOP nyelv :). Azaz nem úgy kéne a C++-ra gondolni, mint objektumorientált C. Mert nem az. Egy teljesen más nyelv, amely jóval-jóval bővebb mint a C+objektumorientáltság, baromira nehéz szemantikájú elemekkel. Másrészt ami szép és jó C kód, az egyáltalán nem szép és jó C++ kód. Az egy dolog, hogy lefordul, de a C++ lényege nem jön át benne.

Egy szóval nem érveltem itt se a C++ mellett se a C++ ellen. Csupán annyit mondtam, hogy ha úgy is "objektumokban" gondolkodik valaki, akkor már célszerűbb lenne egy OOP-t közvetlenebbül támogató nyelvet használni.

(A C++ meg tényleg nem tisztán OOP nyelv, mint ahogy pl. a Delphi sem tisztán OOP nyelv, hiába támogatja az OOP paradigmát.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha csak fejlettebb C-ként kezeled a C++-t, már előrébb vagyunk (nagyobb típusbiztonság, szigorúbb konverziós szabályok). De a C++-nak számtalan olyan fícsöre van, ami amúgy is hasznos, kivételeket, virtális függvényeket persze ki kell hagyni.
De igazad van, a C++-t ismerni kell, de nem igaz ez BÁRMILYEN nyelvre, ha (hatékony) kernelt akarsz benne írni?
----
India delenda est.
Hülye pelikán

Van amit megértek angolul, van amit nem. Angoltudásom messze nem anyanyelvi...

Ami meg e konkrét szót illeti, rákereshettem volna a szótárban, de bevallom eszembe sem jutott, hogy ez angol szó - latinra tippeltem, mert "us"-szal végződik...
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Épp fent idézték a hozzászólásban, hogy Linus nem idealista. A mikrokernel is egy szép ideológia, és még több gyakorlati jelentősége is van, mint a tiédnek. De a történet hasonló, így alakult ki, ez a hagyomány. Pont.

Még abban is hasonlít a kettő, hogy ott a kernelt akarják darabolni, te meg a bin könyvtárat. :)

I think microkernels are stupid.
Mintahogy az altalanositasok is azok ...