Hoofdcategorieën

Torvalds boos na kritiek op nieuw beveiligingssysteem

Door Dimitri Reijerman, woensdag 3 oktober 2007 16:22, views: 25.177

Linus Torvalds is boos op een aantal kritische ontwikkelaars, die bezwaar maken tegen het toevoegen van de Smack-beveiligingslaag aan de aankomende 2.6.24-versie van de Linux-kernel.

PinguïnsOntwikkelaars die bezig zijn met de beveiligingsarchitectuur van Linux, spraken hun ongenoegen uit over het feit dat Smack gebruik maakt van Linux Security Modules (LSM). Volgens hen kunnen deze modules gebruikt worden als hulpmiddel bij een aanval op de kernel. De onderzoekers zeggen meer te zien in de structuur van SE-Linux. Ontwikkelaar James Morris merkte op: 'Developers komen straks diverse beveiligingssystemen tegen. Ze zullen hun vingers er aan branden of, en dat is waarschijnlijker, ze zullen ze gewoon negeren.'

De aanmerkingen op het modulaire beveiligingssysteem waren duidelijk tegen het zere been van de Linux-goeroe. Torvalds liet weten dat de betreffende beveilingsexperts 'gestoord' zijn: 'Ik ben doodmoe van die alleen mijn versie is goed-onzin.' Volgens Torvalds is het juist de bedoeling van LSM om tot een standaardaanpak te komen. Hij besloot zijn emotionele betoog, waarin hij zelfs overvloedig hoofdlettergebruik niet uit de weg ging, met de mededeling dat het besluit om LSM in de kernel op te nemen een fait accompli is: 'LSM blijft. Geen mitsen en maren.'

Het is niet de eerste keer dat Torvalds in aanvaring komt met andere opensource-ontwikkelaars. Begin dit jaar kreeg hij het aan de stok met de Gnome-community. Ook zag de Linux-voorman weinig in de gplv3-licentie. De meeste zeggenschap heeft Torvalds echter nog bij het ontwikkelen van de Linux-kernel. Bij elke voorgestelde toevoeging of verandering heeft de 'uitvinder van Linux' het laatste woord.

Volgende 16:52
Vorige 15:43

Reacties

«  1  2  »

Ik vind het toch raar dat Linus zomaar kan zeggen 'LSM blijft. Geen mitsen en maren.' Ik weet dat hij de oppergod is van de kernel, maar als andere developers met argumenten komen dat dit nieuwe beveiliginssysteem helemaal niet zo veilig is, kan hij toch niet alleen maar zeggen: 'Ach het komt er gewoon'. En hij spreekt zichzelf ook wel een beetje tegen met de 'alleen mijn versie is goed-onzin'...

Niet helemaal, want zijn "versie" laat het kiezen voor een specifiek beveiligings systeem open. Dat terwijl SE-Linux een heel specifiek gedefinieerde set beveiligingsprotocollen is, en niet iedereen zit daar op te wachten.


Anders wordt de kernel wel gevorkt, op het moment dat er onder de kernel-onderhouders / ontwikkelaars meer tegenstanders van Linus zijn dan voorstanders.

Wat het artikel bijv. vergeet op te merken, is dat Linus hetzelfde deed met de CK patches: Nadat Con Kolivas een aantal jaren patches om de kernel 'sneller / reactiever' om desktopgebruik te maken had gemaakt, en blije gebruikers zeiden dat het hun ervaring verbeterde, wilde Linus deze patches niet in de hoofdlijn-kernel opnemen; omdat 'niet bewezen was' dat het echt sneller werkte, en de Linux-kernel niet alleen voor de desktop bedoeld was. Binnen een paar maanden zat er wel een andere patch in die ongveer hetzelfde deed, geschreven door een collega en bekende van Linus, Ingo Molnar. Deze mocht er zonder meer in.

[Reactie gewijzigd door kidde]


kidde,

zoals jij het beschrijft is het vriendjespolitiek. Dat is echter niet het geval.
De ervaringen van Linus met CK waren niet overal positief. Hij stoorde zich vooral aan de non-cooperatieve houding van Con naar andere ontwikkelaars. Ingo Molnar heeft wat dat betreft een heel andere reputatie.
Ik zeg niet dat Linus hier gelijk heeft, maar het ging uitdrukkelijk NIET om de code.

[Reactie gewijzigd door coolmos]


Dan was het toch inderdaad pure vriendjespolitiek?
Linus heeft jarenlang beweerd dat de Staircase scheduler geen meerwaarde gaf tov de oude scheduler. Maar nu dat Ingo hetzelfde idee heeft geimplementeerd blijkt het toch een meerwaarde te hebben aangezien het enorm snel in de kernel mag!
Daarna kwam Linus inderdaad af dat Con niet genoeg meewerkte met andere ontwikkelaars enz .. maar voorheen was het een totale andere reden hoor: dat staircase geen meerwaarde had.

Ik krijg meer en meer een afkeer van Linus' arrogante houding na de vele flamewars waar hij zich in moeit de laatste jaren... Daar bovenop laat hij enkel (grote stukken) code in de kernel toe van mensen die hij kent.

[Reactie gewijzigd door seppevs]


Kennelijk heeft een project een leider nodig. En als het echt zo erg is ontstaat er heus wel een fork of een reeks patches.

'Ik ben doodmoe van die alleen mijn versie is goed-onzin.'
Wat ik zo begrijp doet hij dat hier toch ook? Anders zou hij wel in discussie gegaan zijn, en zou hij niet zo bot zeggen dat het fait accompli is en dat het zo blijft.

En anders fork je? (of mag dat niet)

mag wel, maar dan moet er maar net iemand zijn die zin heeft om een aparte kernel te onderhouden met een ander beveiligingsdinges. Het is imho beter om een project zo min mogelijk te forken, en de aandacht en tijd die anders in een fork gestoken wordt gewoon in de hoofd dinges te investeren.

Waarom zou je forken?

Je kunt ook zelf SELinux in de kernel patchen en LSM niet mee compileren. Dat is namelijk de Kracht van Linux de vrijheid van keuze.

Dit verhaal is natuurlijk koren op molen van mensen die niets op hebben met Linux.

Lunis zal uiteindelijk een lijn moeten uitzetten voor de standaard kernel die je op ftp.[cc].kernel.org download. Zijn verantwoordelijk ligt ook in het stabiel houden van de standaard onderdelen. Natuurlijk is niet iedereen eens met zijn beslissingen.

Correctie:
NSA SELinux Support zit in de kernel.

[Reactie gewijzigd door worldcitizen]


Ja en nee. In zijn boekje heb je met LSM nog steeds de modulaire opbouw * waar Linux bekend om is. Daardoor is er veel te zeggen voor LSM, en het standpunt van Linus. Maar door het tegelijkertijd zo hard neer te leggen schopt hij wel veel mensen tegen het zere beentje... En aangezien de gemiddelde ontwikkelaar een knap groot beentje (lees: ego) heeft, kan dat nogal aankomen... :+

*: voor zover ik het begrepen heb

Linux werd juist bekend door het -niet- modulair opstellen van de kernel, ironisch genoeg. Zie z'n pennenoorlog met dr. Tanenbaum.

Correct. Qua architectuur is de Windows NT kernel "beter".
Monolitische kernel (Linux) vs micro-kernel (Windows NT).

http://en.wikipedia.org/w...el-wide_design_approaches

Heeeeeeeeeeeeeeeeeeelll scherp op gemerkt maar niet heus.
een microkernel is een zeer kleine kernel alles zijn modules die je gemakkelijk kan laden en ontladen. omdat alles een module is hoeft de kernel nooit aangepast te worden. dus geen restarts en zeker geen complete crashes van het systeem. dit omdat alleen maar een module crashed. en deze kan weer herstart worden.
ook kan je de modules in usermode draaien. elke user zijn eigen modules wat het systeem zeer veilig maakt.

DUS Wat heeft het gehackte zooitje wat de NT-kernel heet nu met een echte microkernel te maken. (zoals mach).
Blue screens of Death (cashen van de kernel) en Herstart uw computer mogen niet kunnen optreden in een microkernel.

Je hoeft niet zo debiel te reageren op een kleine fout. Het is inderdaad zo dat zowel de linux kernel en de windows nt kernel monolithisch zijn opgebouwd, en mach er dus helemaal niets mee van doen heeft. Maar hij heeft wel gelijk dat de windows kernel modulair (en platform onafhankelijk) is opgebouwd, dit blijkbaar in tegenstelling tot de linux kernel.

Als je wat meer van de windows nt kernel zou weten dan zou je ook weten dat het niet een bijeen gehackte zootje is, het zit allemaal goed en duidelijk inelkaar. Wat erbij is gehacked is de backwards compatibility met (vrij grote) ontwerpfouten in eerdere windows versies.

En leg mij eens uit waarom een microkernel niet zou mogen crashen? Het is altijd mogelijk dat een module binnen het systeem crashed wat in een omgeving voor een bsod kan zorgen, (die dan natuurlijk op te vangen en misschien zelfs te fixen en resumen). Maar als de controller van de module niet bewezen bugvrij is (wat mij vrij waarschijnlijk lijkt) kan die ook alsnog crashen, met een algehele systeemcrash als gevolg.

Ik ben overigens geen expert op het gebied van kernels dus ik sta open voor correcties, vind het alleen vervelend als mensen die blijkbaar ook over wat kennis beschikken toch zo ongenuanceerd reageren.

[Reactie gewijzigd door d-snp]


Maar hij heeft wel gelijk dat de windows kernel modulair (en platform onafhankelijk) is opgebouwd, dit blijkbaar in tegenstelling tot de linux kernel.
Aha... vandaar dat Windows alleen op de Intel architectuur draait en Linux op ruim 20 andere hardware platformen...
De windows kernel is net zo modulair als dat je mijn arm er zonder problemen af kunt draaien... Niet dus...
En leg mij eens uit waarom een microkernel niet zou mogen crashen? Het is altijd mogelijk dat een module binnen het systeem crashed wat in een omgeving voor een bsod kan zorgen, (die dan natuurlijk op te vangen en misschien zelfs te fixen en resumen). Maar als de controller van de module niet bewezen bugvrij is (wat mij vrij waarschijnlijk lijkt) kan die ook alsnog crashen, met een algehele systeemcrash als gevolg.
Een microkernel kan best crashen, maar als bijvoorbeeld de module voor het netwerk onderuit gaat dan moet alleen het netwerk onbruikbaar zijn en eventueel automatisch opnieuw opstarten. De rest MOET dan wel blijven draaien, dat is het hele idee achter een microkernel: 1 onderdeel kan de rest niet meeslepen in z'n ellende...

Aha... vandaar dat Windows alleen op de Intel architectuur draait en Linux op ruim 20 andere hardware platformen...
De windows kernel is net zo modulair als dat je mijn arm er zonder problemen af kunt draaien... Niet dus...
De oorspronkelijke NT 3.51 en 4.0 waren wel degelijk heel modulair en platformonafhankelijk. Zo draaide het behalve op x86 ook op Alfa, MIPS, PowerPC, Moterola en weet ik wat nog meer. Later werd dat losgelaten want ze hadden toch World Domination.

Als jij de Windows (NT 5) broncode zou hebben dan zou je die kunnen compilen voor een hele reeks verschillende platformen. Overigens draait een aangepaste versie van de windows kernel dus wel op jou arm processor, ooit van Windows CE gehoord?

Als dat de definitie is van microkernel, dan is dat denk ik iets waar Microsoft met de NT kernel naar toe wil gaan. Maar volgens mij is het zoals bassekeNL hieronder zegt, alleen een kleine kernel in de kernelspace, en de rest daarboven. Een model waar Microsoft dus naartoe gaat met windows vista. Wellicht dat sienna echt microkernel is?

Ik denk dat op het moment als een driver crashed Windows nog een redelijke kans heeft dat te overleven.. maar wat doe je als een beeldscherm driver crashed en je informatie van de user nodig hebt om je te redden? Wat ik zou doen is de driver ontladen en de simpelst mogelijke driver laden om daarmee een blauw scherm te toveren met daarop in heldere witte letters wat de gebruiker moet doen om het systeem te debuggen ;)

[Reactie gewijzigd door d-snp]


Blijkbaar in tegenstelling? De linux kernel kent al tijden gewoon modules.

Een microkernel is zo klein (zeg 1000 regels code) dat je mag aannemen dat een dergelijk stuk code bewijsbaar bug vrij is. Dan wordt elke driver of andere module een programma in user space die gewoon kan crashen zonder de machine plat te leggen. Het prpobleem van monolitische benaderingen is juist dat er teveel functionaliteit in de kernel zit (twee ordes van grootte meer), waarvan je niet kan garanderen dat die allemaal correct zijn. Een crash is waarschijnlijker en heeft ook direct grotere consequenties (machine plat). Microkernels zijn dus aantoonbaar beter voor de veiligheid. Het belangrijkste andere aspect is in het beheersbaar maken van beveiligings policies. Daar is volgens mij nog veel winst te behalen.

Dat gaat over een microkernel vs monolithische kernel: het gaat over welke code je in welke ring van de processor laat draaien.

Volgens Tanenbaum alleen een hele kleine kernel in de laagste ring, en de rest daarboven. Linux daarentegen draait alles in "kernelspace", ook de later ingelezen modules. Het is dus geen microkernel, maar een modulaire kernel, waarvan het ingeladen geheel monolithisch in kernelspace draait.

Dat is inderdaad bijzonder hypocriet van meneer Torvalds: tegen anderen zeggen dat ze niet moeten zeggen dat zij alleen gelijk hebben (wat ze volgens mij niet eens gedaan zullen hebben) maar ondertussen wel meteen zelf verkondigen dat jij gelijk hebt. Overigens lijkt dit stuk bijzonder gericht tegen meneer Torvalds, was dat de bedoeling?

Overigens lijkt dit stuk bijzonder gericht tegen meneer Torvalds, was dat de bedoeling?
Als ik het e.e.a. zo lees maakt hij het er wel naar.

Ik heb even door de bron heen gescanned en volgens mij valt het wel mee.

Het enige wat ik hem zou verwijten is het nogal heftig tekeer gaan, maar zijn punt (modulariteit boven één systeem) kan ik niet anders dan onderstrepen.

Het is de kern van Linux, het kan niet zo zijn dat we zomaar daarvan af moeten stappen.
Er is wel wat te zeggen voor het implementeren van één systeem, aangezien je daar dan al je aandacht op kan vestigen, maar het is natuurlijk ook je achilleshiel.

Het wordt Windows toch altijd verweten dat beveiliging niet een integraal onderdeel van het OS is? En dat echte beveiliging helemaal in het systeem verweven hoort te zijn?

Dat spreekt heel duidelijk Tegen modulariteit. Beveiliging hoort geen moduleetje te zijn, dan vraag je er om dat een hack om de module heen kan, of uitschakelt etc.

met een linux module kun je echter veel dieper in de kernel komen, dan met een windows kernel module het geval is. Want microsoft bepaald nog altijd hoe diep een module mag komen. (en gezien de mededelingen van Microsoft uit het verleden houden ze dergelijke dingen tamelijk uit de buurt van de diepste krochten van de kernel)

Als je een goeie security module schrijft, met de daarbij horende aandacht voor security in je code, dan krijgt een exploit weinig tot geen ruimte om daar omheen te werken.

aan het eind van de rit blijft natuurlijk wel de regel staan: alles is te hacken. (of het nou linux, windows, BSD of solaris is)

[Reactie gewijzigd door arjankoole]


Ik meen begrepen te hebben dat het (succesvol) hacken van OpenBSD zo ongeveer wereldnieuws is?

Je mag inderdaad wel een behoorlijk botnetwerkje op een OpenBSD systeem neerploffen, wil je uberhaupt een kans hebben :) Echt heel andere koek dan een GNU/Linux systeem.

Ik juich dan ook de personen toe die dit _niet_ modulair hebben, aangezien ik het liever terug wil zien komen als een integraal onderdeel van de kernel (één systeem, waar iedereen zich maar aan moet houden en wat jarenlang verbeterd kan worden). Een unicum, aangezien ik voor de rest modulariteit juist toejuich.

[Reactie gewijzigd door Jungian]


Hoe verhoogt het hebben van een botnet je kans op het inbreken op een OpenBSD systeem?

Het mooie aan modulair is dat beveiliging juist erop vooruit gaat. Als er een lek in een veiligheidsmodule zit zou je eventueel (mits compatibel) over kunnen stappen. Bij een integraal onderdeel kan dat niet. Je zou moeten wachten tot een patch. Ook verdeeldheid houd de beveiliging hoog. Je weet niet wat voor veiligeidsmodule ik gebruik? Jammer dan. Doe het dan maar op de gok.

Naast dat is er zo ook altijd ruimte voor alternatieven, experimenten en specifieke modules.

Het is een afweging die niet alleen afspeelt tussen graad van beveiliging, maar ook tussen bruikbaarheid. In hoeverre is dit bruikbaar?

De kracht van mijn server is dat er niks verdachts op komt. alles op echtheid geverifieerd. Programma's draaien op hun eigen beperkte rechten. De enige manier om in te breken is met informatie die ik je niet verschaf (Ironie). Of door een lek die in software zit dat onder een gemachtigde gebruiker gebruikt wordt.

De desktop wordt toch iets lastiger. Maar ach lang leven Ubuntu met apt-get en een geverifieerde repository. Jammer dat de programma's zo nieuw zijn. Dat is wel risicovol , maar gelukkig niet het draai alles onder admin feest. Oke, dan heb je ook nog altijd van die websites en die gebruikers!?!? "READ ME OR YOU GET A VIRUS" :+

[Reactie gewijzigd door tuXzero]


Hij doet het inderdaad misschien ook wel, maar het is voor de ontwikkeling van Linux wel belangrijk dat er een persoon is die dit soort beslissingen maakt. Anders blijf je discussieren, en kom je nooit verder. Ik denk dat dat het punt is dat Linus wil maken. Neemt niet weg dat het hem zou sieren als hij op inhoud zijn keuze zou beargumenteren, in plaats van een emotioneel betoog te houden.

Maar goed, developers denken vaak nou eenmaal de wijsheid in pacht te hebben. Ik kan het weten, ik ben er ook een :). Wat belangrijk is om te onthouden is, dat er vaak meerdere wegen naar Rome leiden, en dat de meest bereden weg uiteindelijk ook wel het best zal worden onderhouden.

[Reactie gewijzigd door cashewnut]


Een beetje democratie lijkt me ook geen kwaad kunnen, alhoewel ik hem wel gelijk geef dat gaan voor een standaard aanpak enkel positieve effecten heeft en wanneer hij iedereen zijn zegje zou laten doen er binnen vijf jaar nog niets zou besloten zijn. Ik zie dat hier op mijn werk ook.. Iedereen wil zijn zegje doen, en uiteindelijk komt er gewoon niets van wegens het eeuwenlange gediscussieer.

Een beetje democratie lijkt me ook geen kwaad kunnen, alhoewel ik hem wel gelijk geef dat gaan voor een standaard aanpak enkel positieve effecten heeft en wanneer hij iedereen zijn zegje zou laten doen er binnen vijf jaar nog niets zou besloten zijn.
Het verschil met open-source is dat je het niet met iemand eens hoeft te zijn. Je kan gerust een fork maken (eventueel onder een andere naam) en nieuwe versies van deze fork elke keer op de nieuwste kernelversie van Linux baseren.

[Reactie gewijzigd door The Zep Man]


Dat kan zeker, maar is verre van wenselijk en zou alleen als last resort redmiddel gebruikt moeten worden. Zo splits je namelijk de community in 2, een groep van de voor en een groep van de tegen. Het hebben van een grote community is het allerbelangrijkste voor open source ontwikkeling, dus geen van beide partijen zal er baat bij hebben tenzij de voortgang van een project door de interne conflicten stagneert.

Maar je bied meer keuze, en meer keuze is toch veel belangrijker dan meer ontwikkelaars per project?

Nee, er zijn al teveel varianten van Linux. Het is nu al moeilijk om te kiezen tussen Linux varianten, laat staan als de kernel ook al een fork krijgt. Soms moeten er keuzes gemaakt worden die de meeste mensen tevreden zal stellen, maar niet iedereen. Iedereen tevreden maken gaat niet lukken. Dat wil niet zeggen dat een discussie over een bepaalde richting binnen een project niet gezond is. Ik weet zeker dat binnen alle gesloten projecten er ook heftige discussies zijn over bepaalde keuzes, maar die zijn niet en public.

Verder is het OSS ontwikkelproces niet echt geschikt om voor iedereen een gespecialiseerde variant te krijgen. Wat je wel kan doen is het erg generiek, maar toch flexibel maken, zodat iedereen het naar wens kan instellen. Maar er zijn altijd beslissingen over functionaliteit die niet door de gebruiker in te stellen zijn, zoals de kernel. Er zijn wel verschillende Linux distributies, maar dat zijn géén forks, maar verschillende combinaties software uit bestaande projecten. Niemand schiet er straks wat mee op als je allemaal verschillende incompatibele varianten van een OS hebt.


Dit noemen ze nu 'overspannen'. Een beetje slaap zou hem goed doen, iets minder hard werken ook. Ik weet zelf hoe het gaat: Iedereen altijd zijn zegje laten doen en uiteindelijk volledig doorslaan. Altijd diplomatiek bezig zijn en opeens een dictator-actie.

Komt wel goed, maar handig is het niet.

Niet sterallures. Hij heeft er een probleem mee dat mensen proberen hun zin te krijgen zonder echte argumenten aan te dragen.
In diezelfde discussie zegt hij namelijk:
Quite frankly, I'm not a security person, but I can tell a bad argument
from a good one. And an argument that says "inodes _or_ pathnames" is so
full of shit that it's not even funny. And a person who says that it has
to be one or the other is incompetent.

Yet that is *still* the level of disagreement I see.

So LSM stays in. No ifs, buts, maybes or anything else.

When I see the security people making sane arguments and agreeing on
something, that will change. Quite frankly, I expect hell to freeze over
before that happens, and pigs will be nesting in trees. But hey, I can
hope.
En de conclusie is simpelweg:
The biggest reason for me to merge SMACK (and AppArmor) would not be those
particular security modules in themselves, but to inject a sense of
reality in people. Right now, I see discussions about removign LSM because
"SELinux is everything". THAT IS A PROBLEM.
Het lijkt me dat ie daar gewoon een lijn trekt en als je het mij vraagt meer dan terecht. Hij zet er notabene bij dat ie open staat voor fatsoenlijke argumenten, maar hij die niet ziet. Hij is geen beveiligingsexpert en kan niet op andere gedachten worden gebracht met argumenten als "ja maar SELinux is beter" zonder onderbouwing. Ik kan me dat goed voorstellen.

Dit artikel concludeert dan ook wel erg hard dat het geen kwestie is van mitsen en maren, het ligt zo te zien iets genuanceerder want er is wel degelijk een "maar". :)

Goed gezien.

De kracht van Linux blijkt hier maar weer eens. Dit soort discussies wordt gewoon openlijk gevoerd. Niet achter gesloten deuren een besluit nemen, maar openlijk zeggen waar het op staat en waarom dit wordt besloten.

Volgens mij gaat het erom dat er niet zoiets bestaat als 'absolute security'. De NSA wil nu eenmaal een strengere beveiliging dan ik thuis handig vind. Je hebt thuis ook geen kluis met wanden van 3 meter dik voor je spaarpot. Je gebruikt het slot dat nodig is. En dat is precies wat met LSM kan. Je 'eigen' slot erin aanbrengen.

Linus doet hier exact datgene wat hij moet doen, een besluit nemen op basis van argumenten. Niet mee eens? Niet janken, gewoon betere argumenten aandragen.

Zachte heelmeesters.....

Linus op z'n best. Het is wel duidelijk dat Linus niets leert van zijn voorgaande veto-acties. Ik verwacht echt dat er een dag komt dat iedereen linus gedag zegt en de Linux kernel forkt naar een eigen implementatie.

Je moet niet vergeten dat hij ook een heleboel wel toelaat in de kernel. Hij heeft nu tegen 3 dingen aangeschopt, maar als je de laatste release van de kernel bekijkt zijn er veel meer dan 3 dingen geupdate c.q. toegevoegd.

Zal zijn opvolger trouwens al klaarstaan voor het geval hij tegen een boom rijdt vanavond?

Tuurlijk. XFree86 was ook een ongoing process, maar mensen waren de idealistische houding van de foundation erachter helemaal zat en gingen over tot een fork; x.org.

Nu zie je ook steeds meer een tweedeling in de kernel-development. Het idealistische volk (including Linus Torvalds) dat vanuit theoretisch oogpunt verbeteringen doorvoert waar waarschijnlijk geen enkele desktop-gebruiker iets van merkt... en het pragmatische volk dat gewoon spijkers met koppen wil gaan slaan en innovatie in de kernel wil bewerkstelligen, waaronder desktop-functionaliteiten.

Zover ik zie lijkt mij LSM juist het innovatieve.
Torvalds is gewoon het ongefundamenteerde 'ik ben tegen!' gezeik zat, en terrecht.

Het verhaal XFree en X.org heeft niets te maken met pragmatisch of innovativiteit.
De fork is alleen ontstaan vanwege licentiekwesties, niet omdat er technische onenigheid was.

Zoals het artikel al stelt; Linux schopt wel vaker tegen vanaf alles en nog wat. Zo zijn Objecten ook nog steeds 'evil', en mede vanuit dat standpunt heeft ie laatst nog een lange rant gehouden tegen C++, wat in Linus' boekje zo ongeveer de meest evil taal is die er bestaat (samengevat; niet zo low-level als C en niet zo high-level als Java of C#, maar iets er middenin dat het volgens Linus 'net niet' is).

Ik zou dat als developer ook doen. Hij heeft gewoon een doel en personaliteitstrekjes die de Linux kernel al heel wat verder hebben gebracht.

Ik weet niet wat Linus nu juist gezegd heeft over C++ maar ik vind persoonlijk dat object-programmeren niet overal thuishoort. Het is inderdaad krachtig binnen talen als Java maar vb. PHP was origineel geen objectieve taal maar slechts sinds PHP5 hebben ze het heel wat uitgebreid. Ik vind persoonlijk dat (ik programmeer reeds sinds PHP3) voor de meeste PHP programmeurs het object-georienteerd programmeren met classes etc. helemaal niet nodig is als je weet wat je doet en veiligheid in gedachte houdt bij je opbouw.

Heel Off-Topic _/-\o_ _/-\o_ _/-\o_ 100% mee akkoord, dat probeer ik mijn collega's ook al maanden duidelijk te maken, vooral nieuwkomers hebben het daar heel moeilijk bij want PHP5 & Objecten zijn in hun ogen heilig ... Zo gebruik ik in simpele sites (homepage, blogje, foto'tjes, ...) nog steeds geen MySQL class en is alle code nog netjes geprogrammeerd met het idee we starten vanboven en we eindigen onderaan en elk onderdeel is een aparte module. Een simpele site is dan ook meenstal binnen de 2 dagen af waar men collega's met hun classes & 1001 functies etc er een week overdoen :O

Ook merk ik dat het idee van OO programmeren in een project op lange termijn zijn doel vaak voorbijgaat, ipv bestaande objecten aan te passen wordt er dan vaak vanuit tijdsdruk & gemakszucht maar nieuwe objecten erbij geprogrammeerd met als gevolg dat je na een jaar met zo'n boel onoverzichtelijke code zit dat je niet meer weet waar je wat moet aanpassen.

Om toch iets on-topic te zeggen, ik ben dan geen linux gebruiker maar als ik er over lees denk ik toch dat het eens tijd om een ietswat democratisch systeem te onwikkelen. Zo is er een oude fwd mail van eind jaren 90 waar besturingssystemen worden vergeleken met vliegtuigen, en bij Linux staat er ...

"GNU/Linux Airlines: Iedereen brengt een stuk van het vliegtuig met zich wanneer ze naar het vliegveld komen. Dan gaan ze allemaal op de runway staan en zetten het vliegtuig samen, constant ruzie makend over welk soort vliegtuig ze aan het bouwen zijn."

Objecten zijn heilig omdat dat is wat ze op school geleerd hebben en dus mee vertrouwd zijn. Ik heb dat niet geleerd maar moet er wel mee werken, en dat vind ik ook bepaald niet altijd prettig.

In de Linux kernel wordt veel op een OO manier gedaan. Maar dan wel in gewoon C. Je ziet er veel structures met een hoop functie-pointers. Dit is hoe C++ en Java virtual functions onder water implementeren.

Sluit deze beslissing SELinux uit? of kan je SELinux gewoon gebruiken ook met deze nieuwe kernel? Want als dat zo is is het meer een kwestie van 'de devs zien meer in modulariteit, en daarom is SELinux niet gekozen, maar je bent vrij die zelf alsnog te gebruiken' toch?
Als ze dit systeem door iedereens strot proberen te douwen is het fout, maar voor zover mijn beperkte kennis reikt sluit dit systeem SELinux niet uit...

[Reactie gewijzigd door graey]


IMO is nu juist dat probleem van James Morris: het gebruik van LSM. Linus geeft nergens aan dat hij SELinux niet wil zien. Hij geeft enkel aan dat LSM blijft.

Nee, deze beslissing betekend alleen dat SELinux niet in de kernel zit die je op ftp.[cc].kernel.org ophaalt. Dit zegt ook niets over de toekomst of SELinux ooit in de standaard kernel terecht komt.

Dit betekend niet dat SElinux niet (meer) gebruikt kan worden. Redhat gebruikt bijvoorbeeld SELinux in hun distro. SuSE heeft het ook gebruikt maar zijn over op apparmor omdat ze SELinux te complex/te moeilijk te configureren vonden.

Het voordeel van de Linux kernel is dat er een framework gebouwd wordt naar de ideen van de kernel beheerders. Wat in mijn ogen helemaal niet slecht. Daarbovenop worden patches door de distros gedaan en de gebruiker kan dit zelf ook.

Zo heeft SuSE al heel vroeg voordat Xen in de kernel zat om een Xen aware kernel bij hun distro te leveren.

Correctie:
NSA SELinux Support zit in de kernel.

[Reactie gewijzigd door worldcitizen]

«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:52
Vorige 15:43
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: