Torvalds kondigt eerste release candidate van Linux-kernel 4.0 aan

Linus Torvalds heeft het groene licht gegeven voor de release candidate van Linux-kernel 4.0. Ondanks de sprong in het versienummer bevat de nieuwe kernel geen grote wijzigingen. Hij is vooral gericht op het wegwerken van bugs en het verbeteren van de stabiliteit.

Binnen de Linux-ontwikkelgemeenschap was er de afgelopen weken discussie of het versienummer van de Linux-kernel naar versie 3.20 getild moest worden of juist naar een 4.0-release. Linus Torvalds heeft echter, mede naar aanleiding van een poll, de knoop doorgehakt en de eerste release candidate van kernelversie 4.0 aangekondigd. De codenaam die Linus heeft toegekend is 'Hurr durr I'ma sheep'.

Linux 4.0-rc1 bevat geen opzienbarende vernieuwingen. Wel is er ondersteuning voor IBM's nieuwe Z13-mainframe toegevoegd, evenals voor de Quark-soc van Intel en diverse ARM-socs. Ook is voor de AMD Radeon-driver ondersteuning voor audioweergave op een DisplayPort-aansluiting aanwezig en zijn diverse drivers aan de kernelcode toegevoegd.

Reacties (94)

Het was altijd vrij helder: van 3.* naar 4.* betekent een grote stap voorwaarts. Veel nieuwe features, etc. Daar is toch echt wel verandering in gekomen en het is wachten op een nieuwe standaardregel.

Linux is niet de enige waarbij er flinke discussie was of er wel of niet een nieuw versienummer zou komen. Chrome zit in de relatief korte tijd dat ze bestaan al op versie 40. Ook WordPress heeft onlangs 4.0 geïntroduceerd, terwijl de echt grote features die waren aangekondigd werden uitgesteld en in 4.1 kwamen of zelfs nog moeten komen.

Standaard? http://semver.org/

Zeker handig om dit te volgen. Ik weet dat ze met PHP dit proberen te volgen, zelfde geldt voor Symfony en Doctrine binnen de PHP wereld. Volgens mij gebruikt NPM (Nodejs Package Manager) dit ook.

Werkt echt handig mbt het upgraden van libraries.. Of het ook voor applicatie releases werkt? Geen idee. Ik heb geen ervaring met kernels, maar het lijkt mij een "public" API, dan lijkt semantic versioning mij zeker een goed idee.

leuk en aardig natuurlijk, maar de linux kernel doet eigenlijk niet aan niet backward compatible API changes. als dat gebeurt is het nagenoeg altijd op een klein deel.
en dat soort veranderingen wordt dus niet uitgesteld en naderhand gebundeld zoals je bij veel andere software ziet.

afhankelijk van hoe je dan kijkt heeft de kernel dan of heel regelmatig een nieuwe major versie, of helemaal nooit.

het is gewoon niet een standaard die geschikt is voor de Linux kernel. of eigenlijk nagenoeg geen een software pakket dat word ontwikkeld in korte iteraties (dus decentral en/of agile).

Wachten op een nieuwe standaardregel? Versie nummers zeggen al sinds de oudheid niets over de inhoud, maar er zijn veel mensen die:

• 1.0 Publieke versie 1
• 1.0.1 Publieke versie 1 met een bugfix/revisie
• 1.1 Publieke versie 1 met nieuwe functionaliteit en waarschijnlijk voorgaande bugfixes
• 2.0 Publieke versie 2 waarschijnlijk nodig op te upgraden of niet helemaal compatible met versie 1

Maar daar is nooit een wet voor geschreven en intern werkt men altijd aan 'de nieuwe versie/release' oftewel zoals bij Chrome gebeurd inmiddels release 40, dat dat zelfde nummer '40' in het vakje van versienummer gezet is is misschien iets wat ongelukkig maar dit is hoe ze nu eenmaal werken.

Als er dan toch 1 iets gestandaardiseerd/geconventioneerd zou mogen worden, dan is het aangeven of de ABI gebroken is tov vorige release of niet.

De Linux wereld kreunt onder het gewicht van ABI breaks overal en een echt goede oplossing is er niet. Het gros van de upstream developers kijkt er niet naar, of weet niet eens waar je't over hebt. Los dit probleem op en je hebt plots een groot stuk van het distro-probleem opgelost.

Linus doet niet aan een stable ABI uit ideologisch redenen. Hij wilt namelijk source code van drivers in de kernel en denkt dit door een unstable ABI (maar wel een stable API) te kunnen afdwingen.

Wat Sympa zegt:
De kernel heeft naar userspace een uiterst stabiele ABI, maar geen stabiele API.
Intern heeft de kernel geen van beide. Wie out-of-tree leeft, moet daar de gevolgen maar van dragen.

Hier doet Linus zelve er nog zijn beklag over dat developers van userspace zo weinig ABI garanties geven:
https://www.youtube.com/watch?v=1Mg5_gxNXTo

Voor wie het niet weet:
Een stabiele API betekent dat de geëxporteerde signatuur van functies en hun datastructuren niet wijzigen tussen versies. Het betekent dat je je eigen code zonder aanpassen kunt laten werken met verschillende versies van de code met stabiele API. Dit is allemaal tijdens het ontwikkelen van de code (i.e. compile-time)

Een stabiele ABI betekent dat programma's die ooit voor versie X werden gebouwd/gecompileerd, ook nog werken op versie X+Y zonder opnieuw compileren. Dit betekent dat als je een package van een library hebt geinstalleerd, je deze kunt updaten zonder alle afhankelijke software mee te updaten.

Misschien schrijf ik hier beter eens een blogje over

Met Linux API dacht ik eigenlijk specifiek aan de syscalls en die zijn toch uiterst stabiel. Misschien had ik dit moeten verduidelijken.

PS: Ik kijk uit naar je blog .

Ik vrees dat je de betekenissen van API en ABI precies omdraait hier.

goarila of ikzelf?

Uzelf.

http://en.wikipedia.org/w...ion_programming_interface
http://en.wikipedia.org/wiki/Application_binary_interface

En als je nu ook nog kunt zeggen waarom ik fout ben?

API = signatuur van functies, data structure field names, ...; Hercompileren van nieuwere versies werkt zonder aanpassing.
ABI = calling convention, data structure layout, ... Updaten van binary blijft werken zonder recompile.

Ik vermoed dat we in het beste geval een spraakverwarring hebben en in het slechtste geval zal je veel bijleren van mijn blogje (welke ik al aan het schrijven ben).

Linux heeft een uiterst stabiele ABI naar userspace, dus naar de applicatiesoftware. Volg Linus maar eens als iemand een obscure feature wil wijzigen of verwijderen.

Naar kernelmodules en drivers heeft Linux dat niet. Zeker geen ABI (bij elke recompile is het anders) maar ook geen API (kernel-intern wijzigt er wel eens wat).

You couldn't be more wrong, zie het al door HighGuy gelinkte filmpje van Linus bij DebCon.

Welke standaard,

MS had windows 3.11
XP Vista
7
8
8.1 en nu 10

Zit weinig standaard in.
Uiteindelijk zijn cijfers gewoon marketing. Hoger moet het idee van nieuwer geven en nieuwer geeft het idee van beter.

Het gaat hier om de kernel nummers:

3.1 = Win NT 3.1
3.5 = Win NT 3.5
4.0 = Win NT 4.0
5.0 = Win 2000
5.1 = Win XP
5.2 = Win Server 2003 (& Home Server)
6.0 = Win Vista (& Server 2008)
6.1 = Win 7 (& Server 2008 R2 + Home Server 2011)
6.2 = Win 8 (& Server 2012)
6.3 = Win 8.1 (& Server 2012 R2)
6.4 = Win 10

Win 3.11, 95, 98 en ME zijn niet op een NT kernel gebaseerd.
MS gaat bij Win 10 het kernel nummer 6.4 hernoemen naar 10.0 om weer, net als in het NT tijdperk, gelijk te lopen.

Win10 = 10 tegenwoordig

Allemaal een kwestie van perspectief

Als je een Z13 mainframe hebt:
3.x => Werkt niet
4.x => Werkt wel. Groot verschil

Als je een Intel PCtje hebt:
3.x => Werkt
4.x => Werkt ook. Nauwelijks verschil.

Versienummers zeggen sowieso al weinig meer. Soms kom je software met versies als "V8.1.14.3974.A2 RC3" tegen. Wat vertelt jou dat nou helemaal?

Wanneer je dat soort versienummers tegenkomt, dan kun je er best zeker van zijn dat ze niet voor jou bedoeld zijn. Ze zijn bedoeld voor het bedrijf en de ontwikkelaars om makkelijk verschillende builds, doelgroepen en features uit elkaar te houden. Als er dan een bugreport binnenkomt, kunnen ze heel precies vaststellen welke variant van hun product het mankement heeft.

Beetje zoals dit: http://xkcd.com/619/

"V8.1.14.3974.A2 RC3"

Major Minor Revision Build Release Client 3? 😋

Ik gebruik altijd Semantische Versionering: http://semver.org/

Jij legt ongeveer semver uit: http://semver.org/

Hier werk ik met pilight met een stable versie 1.0, 2.0, 3.0. Daarnaast worden er elke nacht nightlies gemaakt. Die nightlies worden genummerd aan de hand van het aantal commits na de stable plus de git commit SHA. Een nightly die 5 commits bevat sinds stable 3.0 heet:
3.0-5-cdergf12

Zo heb ik dus de vrijheid om met major en minor nummering te werken: 1.0 of 1.1, maar daarnaast ook a.d.v. github met nightlies te werken die een patch nummer krijgen. Dat laatste maakt met me makkelijk om te zoeken waar gebruikers zitten in de ontwikkeling naar de volgende stable.

[Reactie gewijzigd door CurlyMo op 23 februari 2015 13:38]

Echt de hele versie nummering/benaming discussie is 1 grote troll fest.

Als IT binnen je bedrijf moet het werkelijk waar geen barst uitmaken hoe ze het noemen, want is totaal niet in het belang van het bedrijf. Een versie nummering is alleen van belang voor de ontwikkelaar voor ondersteuning en bug tracking. Voor ons als klant van het product is het alleen maar een identificatie die je meegeeft voor support voor de rest heb je er 0 mee te maken en 0 belang bij. Het is zelfs niet eens belangrijk voor je upgrade proces. Je upgrade tenslotte wanneer de verandering voor jou als bedrijf van belang zijn niet wanneer het ineens van 2.x naar 3.x gaat of van 2.1 naar 2.2. Als dat de procedure binnen je bedrijf is moet men nodig de procedures herzien.

De hele vernummering is hoogstens een nettiquette en geen regel. Er is nooit vastgelegd dat je van 1.x naar 2.x alleen mag doen met grote nieuwe features of hetzelfde van 2.1 naar 2.2.
Steeds meer zie je svn nummering, datums of niks een gewoon een github update en daar kan je dat niet eens meer doen., maar zaols ik al zei als klant moet het je niks uitmaken. Degene waarbij dat wel zo is zijn gewoon verkeerd bezig.

Voor end-user van een applicatie maakt het geen zak uit wat het bedrijf naar buiten brengt als versie nummer. Echter zijn er voor package managers geen denkbare scenarios waar het een goed idee is dat package A andere regels volgt dan package B.

Het is zelfs niet eens belangrijk voor je upgrade proces. Je upgrade tenslotte wanneer de verandering voor jou als bedrijf van belang zijn niet wanneer het ineens van 2.x naar 3.x gaat of van 2.1 naar 2.2. Als dat de procedure binnen je bedrijf is moet men nodig de procedures herzien.

Bij shared libraries of frameworks is het voor je upgradeproces wel belangrijk om een beetje inzicht te hebben of de nieuwe versie API of ABI compatible blijft met je bestaande software, en juist dan is het wel zo handig om een systeem te hebben waarbij je aan de versienummers kan zien of dat het geval is. Als je dan een major.minor.patchlevel nummering afspreekt waarbij je belooft dat alleen bij een nieuwe major versie geen in-place upgrade mogelijk is, dan maak je het leven gewoon makkelijker voor de eindgebruiker die alle factoren bij een upgrade moet afwegen. Het is gewoon net iets duidelijker dan een notitie ergens in de changelog dat het kapot gaat als je een upgrade doet.

Ik vind ook dat er eigenlijk ook geen goede reden is om zo'n systeem níet te gebruiken, tenzij je opzettelijk mensen langer bezig wil houden dan noodzakelijk. Af en toe een zinvolle release tag maken van een bepaalde repo revisie is nou ook niet zo lastig.

Het klopt dat dat eerder netiquette is dan een harde regel, maar dat is bijna alles op internet, wat niet betekent dat het niet belangrijk is

[Reactie gewijzigd door Sfynx op 23 februari 2015 21:58]

In de linux kernel wereld niet helemaal. Je had De verschillen tussen 2.0, 2.2, 2.4 en 2.6 waren groter dan bij de sprong van 2.6 naar 3.0 naar 4.0

De linux kernel is een vrij complete kernel geworden waardoor het toevoegen van grote functionaliteit niet zo vanzelfsprekend is, maar om daarom regelmatig dan maar het voorste nummertje te verhogen lijkt mij ook wel wat ver gaan.

Je doelt met name op 2.4 versus 2.6

Helaas vreet het ook ontzettend veel meer RAM.

Ach, wat een grote of kleine verandering is verschilt voor veel mensen en toepassingen. Met een hoop resources zou je theoretisch de hele kernel van de grond af opnieuw op kunnen bouwen met behoud van 100% compatibiliteit. Vrijwel niemand zou er iets van merken. Is dat dan een grote wijziging of niet?

Je zou prima kunnen betogen dat het enige nut van versie of build nummers is om te laten zien welke versie nieuwer is.

[Reactie gewijzigd door Maurits van Baerle op 23 februari 2015 12:32]

Linux doet niet aan Semantic Versioning, dus de versienummers zijn eigenlijk zinloos, hetzelfde geldt voor Chrome en Firefox.

[Reactie gewijzigd door halofreak1990 op 23 februari 2015 12:58]

Bij Chrome is er weinig discussie, ze hebben bewust gekozen voor een maandelijkse 'milestone', waarbij het eerste nummer van het versienummer naar die milestone verwijst. Dit is juist helder voor iedereen, omdat alles wat tussendoor wordt gereleased alleen maar bugfixes betreft.
(en die "korte tijd" betreft dus 40 maanden )

[Reactie gewijzigd door gpgekko op 23 februari 2015 13:36]

Linux sinds 2003 toen ik voor het eerst met Linux werkte en nu is toch echt wel een MAJOR step geweest..

Het had allang V10.x kunnen heten. hoelang men wel niet op V3.26 is blijven hangen..

De codenaam die Linus heeft toegekend is 'Hurr durr I'ma sheep'.

Ik vind dit geniaal. Kan me echter wel voorstellen dat het moeilijk is om Linux serieus te nemen met dit soort grappen.

Ik vind het vanuit persoonlijk standpunt wel 'lol'.

Echter vind ik het in deze situatie (externe codenaam voor een professioneel product) totaal kinderachtig.

De Linux kernel is opensource, dus een 'interne' codenaam bestaat niet. Daarnaast is de Linux kernel geen professioneel product (het is wel een kwalitatief goed product.) Je kan namelijk geen professioneel product vrijgeven met de volgende voorwaarde (GPLv2)
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

Daarnaast, ik ken geen softwareontwikkelaar die dit niet kan waarderen.

Als ik het goed heb is dit enkel een maatregel om rechtzaken tegen te houden. Ik heb de proef op de som genomen en JAVA SE van Oracle (2de grootste softwarebedrijf, hopelijk dus professioneel: http://en.wikipedia.org/w...argest_software_companies) proberen te downloaden. 4de punt in de license agreement:

4. DISCLAIMER OF WARRANTY. THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ORACLE FURTHER DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT.

Dan heb ik maar eens bij VMware (5de grooste bedrijf) gaan kijken:
[quote]
7. WARRANTIES.

7.1 Software Warranty, Duration and Remedy. VMware warrants to You that the Software will, for a period of ninety (90) days following notice of availability for electronic download or delivery (“Warranty Period”), substantially conform to the applicable Documentation, provided that the Software: (a) has been properly installed and used at all times in accordance with the applicable Documentation; and (b) has not been modified or added to by persons other than VMware or its authorized representative. VMware will, at its own expense and as its sole obligation and Your exclusive remedy for any breach of this warranty, either replace that Software or correct any reproducible error in that Software reported to VMware by You in writing during the Warranty Period. If VMware determines that it is unable to correct the error or replace the Software, VMware will refund to You the amount paid by You for that Software, in which case the License for that Software will terminate.

7.2 Software Disclaimer of Warranty. OTHER THAN THE WARRANTY ABOVE, AND TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VMWARE AND ITS SUPPLIERS MAKE NO OTHER EXPRESS WARRANTIES UNDER THIS EULA, AND DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AND ANY WARRANTY ARISING BY STATUTE, OPERATION OF LAW, COURSE OF DEALING OR PERFORMANCE, OR USAGE OF TRADE. VMWARE AND ITS LICENSORS DO NOT WARRANT THAT THE SOFTWARE WILL OPERATE UNINTERRUPTED OR THAT IT WILL BE FREE FROM DEFECTS OR THAT IT WILL MEET YOUR REQUIREMENTS.
[/qupte]

Na even zoeken heb ik ook de licentie overeenkomst met MS Windos 8 gevonden:

Biedt Microsoft een BEPERKTE GARA NTIE voor de software? Ja. Micr osoft garandeert dat correct
gelicentieerde software in grote lijnen wer kt overeenkomstig hetgeen is beschreven in het
Microsoft-materiaal dat bij de software wordt geleverd. Deze beper kte garantie geldt niet voor problemen
die u zelf veroorzaakt, die zich voordoen wanneer u onze aanwijzingen niet opvolgt, of die worden
veroorzaakt door gebeurtenissen waarop Microsoft redelijkerwijs geen invloed kan uitoefenen. De
beperkte garantie gaat in op het moment dat de eerste gebr uiker van uw exemplaar van de software dit
exemplaar verkrijgt, en heeft een looptijd van een jaar. Eventuele supplementen, updates of
vervangende software die u gedurende dat jaar van Micr osoft ontvangt vallen eveneens onder deze
garantie, maar slechts gedurende de rest van deze periode van een jaar, of gedurende 30 dagen, als dat
langer is. De beper kte garantie wordt niet verlengd door overdracht van de software. Microsoft wijst alle
andere garanties of voorwaarden van de hand. Microsoft wijst alle impliciete garant ies, met
inbegr ip van garant ies van verkoopbaar heid, geschiktheid voor een bepaald doel en een
niet-inbreukmakend karakter van de soft ware van de hand. Indien uw plaatselijk recht de
uitsluiting van geïmpliceerde garant ies door Microsoft niet toestaat, gelden geïmpliceerde
garanties en voorwaarden uitsluitend voor de looptijd van de beper kte garant ie en worden
deze beper kt zover uw plaatselijk recht dit maximaal toestaat. Als uw plaatselijk recht een
langere garant ieper iode voorschrijft, zal deze langere per iode, niettegenstaande deze
overeenkomst, van toepassing zijn, maar hebt u alleen het verhaal dat in deze overeenkoms t
wordt beschreven. Een artikel aan het einde van deze overeenkomst beschrijft hoe u een claim kunt
indienen op grond van de beperkte garantie.

IMO is er geen enkel bedrijf dat 100% vertrouwt op de producten (al dan niet software).

BTW, linux is wel professioneel. Het wordt over heel de wereld op de enterprise markt gebruikt.

Commerciële licenties worden door advocaten geschreven en hebben maar één doel: Risico's en aansprakelijkheid vermijden. Garantie tot de deur.

Elk risico op claims wordt vermeden en elke aansprakelijkheid afgewezen voor zover de wet het toestaat, en vaak zelfs over het randje met het idee dat de klant uiteindelijk geen rechtzaak er aan waagt.

"Interne" code namen (lees voor eigen gebruik) voor OS bestaan gewoon, net al die gebruikt worden voor propertiary software. In beide gevallen worden deze vaak naar buiten toe bekend gemaakt.

"Professioneel software" heeft niets te maken met het feit of er wel of niet gebruik gemaakt wordt van open source code.

Daarnaast is de Linux kernel geen professioneel product

weten bedrijven als canonical, red hat en zowat elke hoster op de planeet dat wel?

Ik vertrouw geen enkel stuk software voor geen enkele toepassing.

Je stelt eisen, je gaat opzoek naar de beste oplossing. Test of deze voldoende is en accepteert deze. Alle onverwacht gedrag ga je later fixen of anders mitigeren.

In een wereld waar er duizend en een mogelijkheden zijn en miljoenen toepassingen ga je gegarandeerd iets tegen komen wat niet werkt. Daar zijn die clausules voor.

Maar aan het einde van de dag kun je de volgende stel regel aanhouden: "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

Waar je bij idiots, ook onbedoeld gebruik en onbekende invloeden mag meenemen.
Ja natuurlijk kan ik een RaspBerry Pi gebruiken om dat röntgen apparaat aan te sturen. Of je dit moet doen en dat je interface software rekent in milliseconden belichting in plaats van pico seconden... Ja, dat zijn de fouten die je dag maken of breken.

Achja .. easter eggs in software dan ?
Je hele "professionele omgeving" staat er vol mee

Ach enige referentie naar een uit de klauwen gelopen hobbyprojectje mag toch nog wel ?

Niet noodzakelijkerwijs; al in 2002 kondigde Microsoft aan om juist te stoppen met Easter Eggs in hun software als onderdeel van hun Trustworty Computing initiatief. Nu valt een rare codenaam mijn inziens niet onder de noemer "easter egg", maar het helpt wellicht nog steeds niet mee om serieus genomen te worden.

Als iemand zich meer druk maakt om en waarde hecht aan een codenaam dan aan de kwaliteit van de werkelijke code en de mogelijkheden die je daarmee geboden worden, dan zou ze misschien beter hun eigen prioriteiten bij kunnen stellen
(al denk Ik dat er betrekkelijk weinig mensen zijn die Linux niet serieus nemen; en al helemaal niet om deze reden, de gemiddelde witte boord ziet het niet eens)

Maar goed opzich past het wel bij de hele politiek correctheids discussie .. geloof alleen dat Linus zelf daar een beetje een broertje dood aan heeft.

Zou dan ook vooral maar geen grep -r -i "shit" doen op de source
krijg je pareltjes als:
sound/pci/cs46xx/dsp_spos_scb_lib.c:223: /* !!!! THIS IS A PIECE OF SHIT MADE BY ME !!! *
arch/sparc/lib/checksum_32.S:333: * give up. I'm serious, I am going to kick the living shit
arch/sparc/kernel/pcic.c:499: * to shit into regions like that.
drivers/net/wireless/iwlegacy/3945-mac.c:3339: /* all this shit doesn't belong into sysfs anyway */
drivers/net/wan/z85230.c:1604: ct=2; /* Shit happens.. */
drivers/net/ethernet/sun/sunhme.c:929: /* Remember: "Different name, same old buggy as shit hardware." */

[Reactie gewijzigd door gekkie op 23 februari 2015 13:14]

Dan kun je beter dit doen:

"$ grep -rw shit /usr/src/linux"

Als je sources in /usr/src/linux zit,pad aanpassen als het niet zo is.

staat er toch ook ..."op de source" ... where ever that might be .. en met de -w mis welliswaar zaken als het onschuldige " Matsushita" aan de andere kant mis je ook weer de stierenpoep .. zou toch ook zonde zijn.

Aah, over je "op de source" heengelezen, my bad.

Achja net als dat je "shit" best mag vervangen door een willekeurige andere engelstalige krachtterm
fuck geeft ook mooie resultaten:
./lib/vsprintf.c: * Wirzenius wrote this portably, Torvalds fucked it up :-)
./Documentation/DocBook/kernel-locking.tmpl: If you don't see why, please stay the fuck away from my code.

LOL, nogmaals bedankt voor de hint. Ik ben eens wat gaan zoeken en graven en "drivers/net/ethernet/sun/sunhme.c" is geschreven in de "toon" van een McDonalds transactie

De naam van de module is ook zo'n mooie: "Sun HappyMealEthernet(HME)"

[Reactie gewijzigd door sfranken op 24 februari 2015 00:50]

Dat is geen externe codenaam, meer iets intern dat je vziw. alleen in de Makefile terugvindt.

Ik denk niet dat er relatief veel mensen zijn die dit ook maar ooit in hun leven te zien krijgen, dus op zich is er niets aan de hand IMO

Eens, ware het niet dat dit de RC is. Voor de stable zou ik dit minder vinden, maar nu moet je het gewoon als humor beschouwen

Moet je eens de foutmeldingen lezen Soms echt schaamteloos..

Oops, I think there is an error..
See dev/log for mor info..

Tja, vind ik wel meevallen hoor. Android gebruikt toch ook 'rare' namen zoals Ice Cream Sandwich en Lollipop ?

Android gebruikt een enigzins logische en betekenisvolle conventie (d-z, voedselnamen) voor de major release namen die voor de doorsnee gebruiker makkelijk te onthouden is. Een naam is nou eenmaal makkelijker te onthouden dan een reeks cijfers. Voor ontwikkeling hanteren ze een 'gewoon' semantisch versienummer en voor app developers hanteren ze een API nummer.
Dit is allemaal onderbouwd en gedocumenteerd, ik vindt het een van de helderste systemen en allround ook wel het meest gebruikersvriendelijk.

De codenaam van deze Linux kernel release daarentegen raakt kant nog wal. Het versienummer maakt uiteindelijk ook weinig tot niets uit.

[Reactie gewijzigd door gpgekko op 23 februari 2015 13:32]

Het verschil is dat Android door end-users mee gewerkt word, de Linux kernel niet. Ik denk dat een developer wel door de naam heen prikt en met de versienummers kan werken.

Trouwens, een van de codenames van Fedora was "Spherical Cow". Zelfde idee ;-)

Ik denk dat juist omdat er geen end-users aan te pas komen (behalve met problem solving / bug reports) het gebruik van een versienummer überhaupt overbodig is. Gewoon een enkel nummertje of een datum is genoeg om in changelogs te kunnen zoeken en naar te verwijzen (i.m.o.).
Persoonlijk vindt ik het gebruik van een zin (zoals de kernel update) overigens een stuk suffer dan een 'geinig' naampje.

Een verisenummer overbodig? Dat is lekker als developer zijnde dan.. Hoe wil jij dan testen waar je code op werkt? En hoe ga jij aangeven in een commit wat wel en niet werkt op versie 3.x of 4? Via een commit hash?

Versienummers zijn gewoon de makkelijkste/beste oplossing. Namen kun je achterwegen laten, maar versienummers niet.

Kijk maar naar Android, daar word door een app gecheckt op versienummer, niet op naam.

In Android wordt een app gecheckt op een enkel nummertje (API level), niet op een versienummer. En dat is precies wat ik ook in mijn reactie aanhaal.

Nee, jij hebt het over versienummrs. Een versienummer is wat anders dan een API level

Laten we eerlijk zijn, een Linux kernel release is niet gericht op de consument. De mensen die een release op haar merites moeten beoordelen zijn software en hardware architecten. Ik denk dat deze de inside jokes wel kunnen waarderen (maar er verder weinig belang aan hechten).

Zij verpakken het is een product dat wel tot doel heeft de eindgebruiker aan te spreken. De producten worden door hen (of hun marketeers) weer van een releasenaam voorzien als: Lollipop, Dastardly Dingo, 300N of BLUEGENE/Q

Dat denk ik ook over Android ("Lollipop") maar mijn posts hierover zwemmen in de vijver met de min-eendjes.

Nu, zolang de buitenwereld enkel het versienummer ziet, blijft de imagoschade beperkt. En dat ligt met Android wel anders.

Volgens mij als je naar andere bedrijven kijkt heb je soort gelijke benamingen..

Windows Longhorn iemand
Android Ice Cream iemand Hoe kan je een telefoon OS nou een ijsje noemen
Apple Panther, Tiger, nu Yosemite Wat nou versie nummer we gebruiken de interne code naam gewoon als verkoop product.. Hoeven we het maar 1 keer te verzinnen niemand onthoud toch nummertjes..

Ten eerste, dat is een geit. Je moet serieus eens wat vaker naar buiten.

Ten tweede: het kwam hier vandaan. Een simpel testje om te zien hoe de poll werkt op Google+.

Waar zit de grap?

Tweede keuze in de poll

kom random op andere pagina's terecht ... hotlinken werkt dus niet

Geeft toch wat meer indruk dat er vooruitgang is dan "2.6.96".

Geeft toch wat meer indruk dat er vooruitgang is dan "2.6.96".

Dat was ook maar omdat een aantal fossielen niet kon leven met het idee om het versienumer eens op te hogen. Als het aan die gasten had gelegegen zaten we nu op 2.6.138-eneenhalf want de 2.6 was heilig voor ze.

Ik had inderdaad al gehoord dat 4.0 mogelijk zou komen. Linus had aangegeven dat 3.xx.xxx.xxxx wellicht toch irritant lang was en had de community gevraagt te stemmen of ze over moesten gaan naar 4.0 ondanks dat er geen grote updates waren. Goed dat het gedaan is.

'Hurr durr I'ma sheep' - Haha die is wel goed. Linux en open source heeft sowieso wel een hoop lol namen zoals yast zijn betekenis en nog een hoop meer hilarische.

En dan krijg je binnenkort bij linux hetzelfde verhaal als bij chrome. Na 7.0 komt niet langer 7.1 maar gewoon 8.0

Nou, volgens Phoronix zijn er wel degelijk grote wijzigingen. Maar dit geld eigenlijk voor alle nieuwe kernel release.

Vind het altijd grappig om te lezen dat er niet veel is gewijzigd, maar dat ligt er maar net aan. Bijvoorbeeld:
- The AMD Radeon driver finally has DisplayPort audio support.
- A new AMD ACPI driver and Skylake P-State support, among other power management and ACPI improvements.
- Ondersteuning voor (nieuwe) CPU's/GPU's
- DVB-updates
En zo kan ik wel even doorgaan. Wat ik wil aangeven is dat het misschien voor 'jou' niet interessant is, maar voor iemand juist een hele grote stap/verbetering kan zijn.

Ik hoop echt dat de fan van mijn Toshiba Satellite L300 eindelijk naar behoren gaat werken... zonder eerst in pauzestand te hoeven en weer in te schakelen.
Ondank dat al de beweringen van Linux lovers zoals : linux is superieur aan Windows en het werkt out-of-the-box etc etc niet waar zijn, vind ik Linux toch een leuk OS om meet te klooien.

fancontrol al geprobeerd ?

Nee dat nog niet, maar een heleboel wel wat ik kon vinden op internet. Waar kan ik vinden hoe dit werkt?

Je zou je afvragen waarom ze niet na 3.9 dan al naar 4.0 zijn gegaan (waardoor dit eigenlijk 5.0 zou zijn geweest). Van een .9 naar een 1.0 release gaan is een logischere stap als dit toch een schema wordt om niet hoger dan 19 te gaan.

Sommige mensen vinden het logisch om van 1.9 naar 1.10 te gaan. Sja. Ik vind het ook stom. Het ziet eruit als een getal, en dan is 1.9 toch echt hoger dan 1.10, maarja. Linux. Dat is soms een beetje raar.

Helaas meer van hetzelfde.

De wereld wordt overvallen door hacks en hackers van binnen, buiten en uit met name 3e wereldlanden, maar de kernel is weer meer van hetzelfde.

Wat tof zou zijn is als er meer gegaan zou worden naar een model waarbij device drivers niet controle over de hele kernel hebben (en effectief dus heel simpel je computer hacken).

Zo'n overgang hoeft niet in 1 grote sprong, want dat gaat toch niet lukken, maar in stapjes zou leuk zijn.

Linus heeft helaas hard te kennen gegeven niets aan de security van de kernel te willen doen in dat opzicht.

Goed op weg naar Linux 4.1.15.