Google opent ontwikkeling Fuchsia en wil volledig OS van de software maken

Google heeft de ontwikkeling van Fuchsia openbaar gemaakt en laat meer mensen meewerken aan de software. Anders dan Google eerst meldde, gaat het niet meer om een proeftuin voor OS-technieken, maar moet Fuchsia een volledig OS worden.

Google neemt diverse stappen om meer mensen te betrekken bij de ontwikkeling van Fuchsia. Het bedrijf start een mailinglijst voor mededelingen en discussies over het project, er is een overzicht met verduidelijking over het organisatorisch beheer, een tracker is openbaar gemaakt zodat deelnemers kunnen zien waar aan gewerkt wordt en ontwikkelaars kunnen zich aanmelden om bij te dragen aan Fuchsia.

Bovendien is er een technische roadmap die inzicht geeft in de Fuchsia-projecten waar Google aan werkt, zoals die voor het verbeteren van het bestandssysteem. Google benadrukt dat Fuchsia een langetermijnproject is en dat het doel is om een general-purpose opensource-OS te ontwikkelen dat gericht is op beveiliging, updaten en prestaties. Ook wijst het bedrijf er op dat de software nog niet gereed is voor productieomgevingen.

Het doel is om te komen tot een besturingssysteem dat voor verschillende soorten producten en voor lange termijn gebruikt kan worden, aldus het bedrijf. Google heeft Fuchsia al vier jaar in ontwikkeling zonder veel over het project te communiceren. Voorheen meldde het bedrijf dat het om een project ging om nieuwe ideeën en technieken voor een besturingssysteem uit te proberen. Fuchsia is niet ontwikkeld rond de Linux-kernel, maar op basis van Googles eigen Zircon-kernel.

Reacties (163)

[Eonfge]

Fuchsia is de natte droom van alle elektronica fabrikanten. Linux heeft een gebruiker-respecterende licentie die eist dat fabrikanten hun aanpassingen publiceren, waardoor fabrikanten geen absolute macht kunnen afdwingen over hun apparatuur.

Fuchsia wordt gebrouwd met een licentie die die gebruiker-respecterende clausules niet heeft.

Toegift

Heb voor Fedora Magazine een heel artikel geschreven over hoe jouw gebruikersrechten beschermd en gerespecteerd worden door middel van de GPL licentie:
https://fedoramagazine.org/web-of-trust-part-1-concept/

Fuchsia, en andere software met zwakke licenties zoals MIT en BSD, beschermen jouw rechten niet. Er is een heldere rede waarom multinationals licenties zoals MIT en BSD zoveel promoten...

[Reactie gewijzigd door Eonfge op 23 juli 2024 09:31]

[David Mulder]

Stellen dat de MIT licentie de gebruiker niet respecteert is gewoon absolute onzin. Niet dat je punt niet correct is: De MIT licentie is meer 'open' en plaats inderdaad niet dergelijke (zeker in bepaalde zin positieve) 'restricties' op gebruikers van een library. Met MIT mag je dus inderdaad doen wat je je wilt, terwijl de GPL inderdaad een copyleft license is.

Werk momenteel bij een groter bedrijf en daar is de regel ronduit dat het gebruik van copyleft libraries verboden is, want bureaucratie en een algemene mentaliteit dat een dergelijke houding potentiële toekomstige problemen zou kunnen voorkomen. Totaal niet mee eens, maar m'n punt is gewoon dat Eonfge zeker gelijk heeft dat licenties echt wel een verschil maken voor veel bedrijven.

Hoe dan ook, het is gewoon niet eerlijk is om Google erop aan te vallen dat ze een open source besturingssysteem ontwikkelen met een te open licentie. Ja, het is goed om te weten dat dit een bepaalde impact kan hebben, maar tegelijkertijd hadden ze het ook net zo goed als closed source commercieel project kunnen doen (ala Windows of Mac OS of iOS).

Ook trouwens nuttig om te noemen is dat je meestal de GPL licentie kiest voor eigen code zodat je daarnaast commerciële licenties kunt verkopen onder een andere licentie, dit doen tal van bedrijven (en m'n eigen open source projecten hebben ook om deze reden van een copyleft license gebruik gemaakt). Als je echter een project released onder MIT dan mag iedereen er letterlijk mee doen wat je wilt en dat is op tal van manieren super positief. Google had ook prima het onder GPL kunnen releasen en daarnaast apart aan fabrikanten licenties kunnen verkopen.

[Reactie gewijzigd door David Mulder op 23 juli 2024 09:31]

[Eonfge]

Knip-plak reactie op @Cergorach
---
Klassiek voorbeeld van The Paradox of tolerance. De MIT, BSD en dergelijke licenties zijn zo 'vrij' dat ze jou niet beschermen tegen de (misbruik van) macht van anderen.

[The Zep Man]

Klopt. Echte vrijheid houdt in dat de vrijheid van jou ophoudt waar die van een ander begint. Zo heeft iedereen vrijheid.

GPL voldoet hieraan, het meeste andere niet.

[84hannes]

Klopt. Echte vrijheid houdt in dat de vrijheid van jou ophoudt waar die van een ander begint. Zo heeft iedereen vrijheid.

GPL voldoet hieraan, het meeste andere niet.

Ik vindt dat er veel goeds van GPL is gekomen, dus begrijp me niet verkeerd als ik zeg: GPL is geen heilige graal als het om vrijheid gaat.

Als ik jou een fiets cadeau geef, maar ik stel dat je iedereen die wil weten waar je met die fiets geweest bent, dan beperk ik jouw vrijheid om te doen en laten wat je wilt met die fiets. Als ik jou een stuk softwarecode geef, maar ik verplicht je die code, en iedere wijziging die je er op maakt, te delen met iedereen die dat wil, dan beperk ik jouw vrijheid. Als ik jou echter een stuk code met BSD-licentie geeft, dan is het aan jou om te delen wat je wilt. Je bent veel vrijer!

De keus is dus of ik jou beperk, of dat jij je gebruikers beperkt; linksom of rechtsom beperkt iemand een ander.

[teek2]

Je moet het net anders zien (het zijn namelijk verschillende definities van vrijheid), jij hebt (met GPL) de vrijheid om te kijken of een programma niet jouw rechten schendt (even afgezien van workarounds nu, en we kijken puur naar de intentie). Als MIT/BSD wordt gebruikt heb je als eindgebruiker eigenlijk geen rechten met betrekking tot de auteur. Iedereen mag MIT/BSD broncode pakken en veranderen maar jij hebt niet het recht om die veranderde broncode in te zien van het programma wat je op dat moment gebruikt om te kijken of inderdaad jouw rechten worden gewaarborgd. Veel fabrikanten en projecten (zoals FreeBSD) publiceren wel de broncode, maar daar zeggen ze dus bij: Pak maar, verander maar, doe wat je wilt, je hoeft de veranderingen die maakt nooit aan iemand te laten zien.

In deze context: Google kan de kern van Fuchsia publiceren en samenwerken aan die kern met vele anderen. Dan een set patches draaien die de hele kernel volzetten met trackers en dat doorverkopen aan fabrikanten. Dat mag gewoon. Als Fuchsia GPL was, mocht dat niet, dan mochten ze geen gecompileerde programma's distribueren zonder de broncode erbij. Iedereen zou dan dus de trackers kunnen zien en weer verwijderen.

Dus ja, je kunt meer met MIT/BSD software, maar wat precies? MIT/BSD geven je als schrijver vooral de macht om ook dingen te verbergen van je eindgebruikers. Of om open code te pakken en er verborgen dingen aan toe te voegen. Dat is ook vrijheid, als auteur/fabrikant.

Als je als auteur de GPL gebruikt voor je code geeft je dus wat controle en vrijheid weg, ten behoeve van je eindgebruikers. Tevens verzeker je ook dat je broncode kan groeien omdat je anderen verplicht (dus vrijheid ontneemt) om hun verbeteringen op je code de delen. Maar goed, iedereen is toch weer vrij om zelf wat te schrijven, maar veelal zijn het de "nadelen" van de GPL waard. Persoonlijk vind ik filosofisch de GPL superieur (ik ben meestal gebruiker en ik zie graag wat ik gebruik), maar dat is een mening, over wat vrijheid is en op welk niveau het zou moeten werken.

Maar ik zou nooit iemand willen verplichten een bepaalde licentie te gebruiken. I Disapprove of What You Say your license, But I Will Defend to the Death Your Right to Say It apply it to your work.. zeg maar.

[Reactie gewijzigd door teek2 op 23 juli 2024 09:31]

[i-chat]

In deze context: Google kan de kern van Fuchsia publiceren en samenwerken aan die kern met vele anderen. Dan een set patches draaien die de hele kernel volzetten met trackers en dat doorverkopen aan fabrikanten. Dat mag gewoon. Als Fuchsia GPL was, mocht dat niet, dan mochten ze geen gecompileerde programma's distribueren zonder de broncode erbij. Iedereen zou dan dus de trackers kunnen zien en weer verwijderen.

Of je compiled de /root tree (dus zonder trackers) zelf en flashed die op je hardware, of je compiled hem alleen om te kijken of de hashes overeen komen, Als er met FoSS gekloot wordt mag je er vanuit gaan dat iemand dit uiteindelijk ontdekt, als het structureel gebeurd is het einde project en einde fabrikant, als het eenmalig gebeurt zal het alsnog snel genoeg aan het licht komen. Uiteindelijk zal er wel iemand zijn die die trackers ontdekt een boze brief (of een DDoS) stuurt.

[teek2]

Ik vind dat je beter kan zeggen: "De meeste anderen laten het in het midden en kiezen verder geen filosofische kant." Ze kunnen dus (makkelijker) misbruikt worden om jou rechten te schenden, maar dat is aan degene die de code schrijft uiteindelijk.

[Verwijderd]

Laat mij raden, *BSD besturingssystemen zijn volgen jou ook het toppunt van evil dan? Als je ziet op hoeveel netwerk-apparatuur dat draait over heel de wereld?

[Eonfge]

De playstation draait er ook op. Een toonbeeld van gebruikerscontrole en rechten

[Verwijderd]

En dat weet je op voorhand, dus als je een gameconsole wilt waar jezelf aan wilt sleutelen en de firmware aanpassen dan is de PS niet het ding dat je moet kopen.

Voor mij komt het allemaal wat neer op :"Ik ga zelf in de beerput staan, en dan heel hard klagen dat het stinkt".

[xfj]

Daar gaat het hier niet om. Er zijn tweakers op een website genaamd Tweakers die een mogelijke toekomst zien waarin men qua telefoons alleen kan kiezen tussen de gesloten telefoon van Apple of een willekeurige gesloten doos met Android; mogelijk minder tweakbaarheid in moderne telefoons in de toekomst dus, dus natuurlijk dat tweakers dat opnoemen.

[Verwijderd]

Je doet alsof er enkel Apple en Google is. Als een fabrikant een smartphone op Linux wil uitbrengen, dan is er niemand die hem of haar tegenhoudt. Er is letterlijk niemand die een tweaker tegenhoudt om een smartphone op Linux te ontwikkelen, als de licentie van Fuchsia/Android/iOS je niet aanstaan.

[MN-Power]

En dat weet je op voorhand, dus als je een gameconsole wilt waar jezelf aan wilt sleutelen en de firmware aanpassen dan is de PS niet het ding dat je moet kopen.

De PS3 wás dat wel. Was meteen ook mijn laatste. Hadden ze (o.a.) de otherOS optie maar niet moeten verwijderen.

[Eonfge]

Klopt. Die rechszaak is ook grotendeels waarom de Playstation 4 niet meer gebruik maakt van linux. Al die consumenten met principes heeft ze uiteindelijk een boel geld gekost in rechtszaken en schikkingen.

[Niosus]

De PlayStation 3 draait niet op Linux. Die draait gewoon een variant van BSD net zoals de PS4 en vermoedelijk ook de PS5. Die BSD draaide wel boven op een Hypervisor, die je toeliet van ongetekende code te draaien met beperkte toegang tot de hardware. Dat is hoe dat "OtherOS" werkte als ik het goed heb.

Het probleem is dat die random code van gebruikers het wel héél makkelijk maakt om de zaak verder open te breken als er een fout in de hypervisor gevonden wordt (of om zelfs die fout te zoeken). Als je enkel getekende code toelaat, dan blijft het lastig om een exploit uit te voeren, zelfs als die al gevonden is.

Niet dat dat hackers echt permanent tegenhoudt, maar uiteindelijk heeft de PS3 het toch lang uitgehouden zonder praktische hacks.

[Korben]

Als ‘de PlayStation’ op Linux zou draaien, zou dat Linux dus ook evil maken.

Er zijn heel wat Android-telefoons die zeer gesloten zijn, die ook op Linux draaien. Ergo, Linux is evil.

[Jeanpaul145]

Hij heeft 't nooit gehad over evil.
Enkel dat licenties zoals MIT en BSD heel erg vrij zijn, en daardoor kunnen ze, itt copyleft licenties, geen poortwachter spelen voor gebruikers en hun rechten.

[teek2]

Zeker niet, FreeBSD is netjes en je kunt de broncode zo inkijken en dan zelf compilen uit die broncode zodat je zeker weet dat er niets vreemds in de uiteindelijk implementatie zit. MAAR, iemand mag die FreeBSD broncode nemen helemaal vol plempen met trackers en dan (het ge-compile-de product) verkopen aan jou, zonder dat jij precies weet wat die trackers doen en hoe ze werken. Linux (de Kernel) mag je op dezelfde manier wijzigen, en je kunt de Linux kernel broncode ook pakken, vol plempen met trackers en dan aan jou verkopen MAAR zo'n fabrikant moet dan de broncode van de trackers ook publiceren. Dat is het verschil. De GPL staat keihard aan de kant van de gebruiker, MIT/BSD kiezen niet echt een kant. Wat precies vrijheid is, daar gaan we hier dan maar niet over discussiëren

(Edit: Toch maar wel een beetje gaan discuseieren in andere comments hehe)

[Reactie gewijzigd door teek2 op 23 juli 2024 09:31]

[svenslootweg]

Echter doet de GPL dat in de praktijk ook niet. Het aantal rechtszaken om disputen rondom GPL-overtredingen op te lossen is op twee handen te tellen, en de GPL wordt zeer breed overtreden, voornamelijk in de embedded-industrie. Met eigenlijk nauwelijks tot geen gevolgen. Want rechtszaken kosten een boel geld, en dat heeft de gemiddelde ontwikkelaar niet.

De GPL is interessant op papier. Maar in de prakijk heeft het zich wat mij betreft niet bewezen, en levert het vooral kopzorgen op voor welwillende ontwikkelaars die nu een ellenlange licentie moeten begrijpen en met lastige interacties met andere licenties om moeten gaan, waar dat bij permissive licenties geen probleem is. Netto lijkt het de welwillende open-sourceontwikkelaars vooral tegen te werken, en werkt het dus averechts.

Ik ben zelf ook behoorlijk ideologisch ingesteld wat FOSS betreft, tot op het punt dat anderen zich er soms aan ergeren. Maar een 'morele overwinning' waar je in de praktijk gewoon verliest is wat mij betreft niet nuttig.

[Reactie gewijzigd door svenslootweg op 23 juli 2024 09:31]

[Eonfge]

Het verschil tussen gelijk hebben en gelijk krijgen. Ik steun juristen die bedrijven aanklagen en dwingen om hun code te openbaren, maar als kleine gebruikersrechten actiegroep is het natuurlijk David en Goliath.

Ik hoop dat de rechtszaken tegen onder andere Tesla en Huawai voet aan de grond kunnen krijgen, zodat er in de Europese Unie een import verbod komt op hun illegale apparatuur. Maar tot die tijd moeten we maar accepteren dat hun autos en telefoons vendor-locked zijn.

[Fuzzillogic]

Als gebruiker van GPL-software heb je het recht om de broncode te verkrijgen, en aan te passen naar je eigen goeddunken. Bij MIT/BSD heb je dat recht niet. De Fuchsia die jij op je telefoon kan op gewijzigde, maar voor jou nadelige, broncode draaien, maar je hebt het recht niet om die broncode in te zien.

Als gebruiker prefereer ik ook GPL boven MIT/BSD-alikes.

[David Mulder]

Gezien de licentie tussen de gebruiker van de library en de maker van de library is, is het vreemd om te redeneren vanuit het perspectief van de gebruiker van de gebruiker van de library. MIT staat je toe om een library te maken die vrij in commerciële context kan worden gebruikt door wie dan ook, GPL betekent in de praktijk vooral dat in commerciele context iedereen de link tussen hun eigen code en de GPL code zo 'zwak'/dynamisch mogelijk maakt, zodat hun eigen applicatie zoveel mogelijk apart blijft staan en wel de GPL code kan blijven gebruiken. Dit betekent dat in de praktijk de eind gebruiker sowieso niet de code kan opvragen van een Android spyware applicatie die een fabrikant heeft voorgeïnstalleerd.

Wat ik probeer te zeggen is gewoon dat ik het idee heb dat het in de praktijk sowieso niet extreem veel verschil maakt. Het maakt absoluut verschil en de GPL licentie heeft zeker geholpen om bepaalde bedrijven te motiveren om bij te dragen aan de linux kernel, maar tegelijkertijd zijn er ook oneindig veel bedrijven die geen of minimale veranderingen maken aan de 'core' en alles enkel er rondom schrijven.

[frietfriet]

De eindgebruiker is juist de essentie van waarom de GPL bestaat. zoek maar eens op waarom Richard Stallman met de GPL licentie is begonnen. Heeft niets te maken met 'motiveren om bij te dragen' maar alles met ervoor zorgen dat consumenten vrijn zijn hun producten te gebruiken zoals ze zelf willen: hardware fabrikanten moeten hun broncode openbaar maken daarom. Ze hoeven niets "bij te dragen". Daar is eenieder vrij in.
voor het gemak heb ik het voor u opgezocht:
https://www.gnu.org/gnu/thegnuproject.html

dat het nog steeds mogelijk is om 'apps' te installeren die niet vrij zijn doet er niet toe. Dat is aan de eindgebruiker zelf om te beslissen die te installeren of niet. Het voorbeeld met de printer van Stallman legt het probleem uit.

[Fuzzillogic]

Dat is helemaal niet vreemd. De GPLv3 is mede gemaakt om TiVoization te vookomen, zodat juist de eindgebruikers de controle over hun hard- en software houden. Dat dat niet past in het straatje van veel fabrikanten (en Google) zegt toch wat over hun houding jegens de eindgebruiker. Daarnaast, MIT/BSD leidt maar al te vaak tot "take what you can, give nothing back" bij veel bedrijven; gratis open source licenses vinden ze top, maar dragen zelf niets tot weinig bij aan open source software.

Dus als eindgebruiker prefereer ik GPL, en zelfs GPLv3, omdat mij dat meer rechten geeft.

[controvi]

Als leek in deze.
Waarom klinkt het heel erg alsof google zijn eigen OS wil gaan maken zonder linux om zo uit eindelijk wellicht de kant van Apple op te gaan met IOS maar dan open.

Kan het verkeerd hebben natuurlijk maar als google meer performance uit zijn telefoons wilt halen zonder java te gebruiken en het wellicht makkelijker wil maken om het te updaten......
Is deze stap van google dan niet een logische?

Ik kan me goed voorstellen dat ze bij google ook tegen de android limitaties van java aanlopen.
daar zullen devs ook hun haren uit hun hoofd trekken om de performance hoog te houden en de hardware specs ervoor zo laag mogelijk.

[The Zep Man]

Kan het verkeerd hebben natuurlijk maar als google meer performance uit zijn telefoons wilt halen zonder java te gebruiken en het wellicht makkelijker wil maken om het te updaten......

Er is nog zat rek in de prestaties van Linux en alles wat daarop draait. Verder ligt het probleem van 'updaten' bij fabrikanten die hun drivers en binary blobs gesloten en kernelgebonden houden. Google staat dit toe.

Zoals gewoonlijk is het probleem niet de techniek.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:31]

[Fuzzillogic]

Het lijkt inderdaad de kant van een soort van open iOS op te gaan; ik denk dat het met name om controle over het platform gaat. Zij willen bepalen hoe het werkt, voor hun eigen wensen, zonder rekening te hoeven houden met derden. Met Linux zijn er veel meer steakholders, en Linus zelf die nog een vinger in de pap heeft. Dat code, net als bij de Darwin-kernel van MacOS, open source is met permissive license, is dat niet zo relevant.

Case in point:

Fuchsia has already caused internal disputes at least once, when Google's advertising department clashed with engineers over some of Fuchsia's increased privacy features. The ad team won that particular dispute, according to one person.

(bron)

Performance zal vast aandacht krijgen, al was het maar in de marketing naar de consument. Maar ik betwijfel of je het verschil echt gaat merken in de praktijk. Controle over het ecosysteem is voor Google m.i. dé reden waarom ze Fuchsia ontwikkelen.

[Reactie gewijzigd door Fuzzillogic op 23 juli 2024 09:31]

[Glup]

Jaren geleden las ik van een Google ontwikkelaar dat het ze voornamelijk ging om naadloze updates en upgrades welke konden worden uitgevoerd zonder dat acties van gebruikers nodig was of interactie met derden (fabrikanten). Dat dat de reden was om te gaan expirimenteren met een OS maar dat nog lang niet duidelijk was of dat zou gaan lukken (met Fuchsia wat toen anders heette). Dat was trouwens ook midden in de juridische oorlog met Oracle over Java dus dat zal op de achtergrond zeker een stevig aandeel hebben meegespeeld.

[Reactie gewijzigd door Glup op 23 juli 2024 09:31]

[Fuzzillogic]

Waarom maakt dat mijn opmerking bullshit? Ik zie het in de praktijk gebeuren.

[_Pussycat_]

Bij mijn oude bedrijf werd ook niets van GNU/Linux gebruikt, uit angst dat we alles opensource zouden moeten maken. Dan maar een andere math-library gebruiken.
Het bleek toch moeilijk modules en linken etc. uit elkaar te houden, en er is gewoon een grote kans dat als ik een GNU-library open heb staan, ik toch een stukje code copy-paste.

Niet dat ik iets fout vind aan copyleft, iedereen mag licensies verstrekken zoals hij wilt.

[BikkelZ]

Niks fijner als een door een fabrikant vernaggelde installatie waar je als gebruiker niks meer aan kunt doen. Eigenlijk de Android situatie van dit moment in een notendop.

[Bender]

Hoe vaak kun je als gebruiker daar iets aan doen dan als het op Linux draait? ;-)

Edit:
Bijzonder dat ik een -1 krijg hiervoor, de realiteit is dat de meeste gebruikers geen Tweakers zijn en helemaal niet zitten te wachten op het 'modden' van andermans software. Het geven van een -1 is naar mijn mening een tunnelvisie en negerend dat een groot aantal gebruikers anders is.

[Reactie gewijzigd door Bender op 23 juli 2024 09:31]

[Yggdrasil]

Nou best vaak. Niet iedereen heeft daar het geduld voor maar met een bugreport en een vriendelijke conversatie met de maintainers van de driver kom je best een eind. Wij draaien veel Linux installaties op het werk en hebben zelfs voor rare problemen vaak in een dag of twee een patch gekregen om te testen. Werkt die, dan wordt ie in de volgende release meegenomen en profiteert iedereen ervan.

[BikkelZ]

Nou in het geval van Android natuurlijk ook niet zo veel, Linux is zeker niet de heilige graal van "oh er zit ergens Linux onder dus is het open". Je moet gewoon een vanilla OS kunnen installeren a la Windows op een PC. Zo heb je vaak OEM PC's met een Windows installatie vol met trialware, die kun je doorgaans formatteren en met de zelfde key een schone Windows er op zetten.

Eigenlijk is juist Windows een enorm goed voorbeeld van hoe het wél moet in tegenstelling tot Android en waarschijnlijk ook Fuchsia.

[HollowGamer]

Heel veel, je kunt updates prima terugdraaien of andere dingen binnen en buiten het OS installeren. Android en ChromeOS hebben die vrijheid stukken minder, zie alleen al het hele gedoe om root te krijgen op je device.

Dit OS voelt voor mij dan ook een flinke stap terug in vrijheid. De doorsnee gebruiker zal het niet super veel schelen, maar vanuit een ontwikkelaar POV twijfel ik meer hierover dan over de blobs op Linux.

[Ghxst]

Google zelf maakt het extreem makkelijk om root te krijgen op je Android device, het zijn de andere fabrikanten (zoals Samsung) die het proberen lastig voor je te maken (met sommige exploits als gevolg van kernel modificaties ).

Als dev phone heb ik altijd het liefst een Pixel, OnePlus of de goedkopere moto modellen want die zijn vaak ook redelijk stock.

Op deze devices heb ik nog nooit problemen gehad met rooten.

ChromeOS heb ik geen recente ervaring mee dus daar kan ik verder niks over zeggen.

[Bender]

Een Tweaker is doorgaans een minimaal percentage van de gebruikers, dus de meeste zullen daar weinig aan doen.

[controvi]

Ik verwacht in de toekomst alleen maar meer limitaties van google uit.
Zoals al vaak in opspraak is gekomen, is dat google zijn limitaties oplecht aan bedrijven als samsung die android services willen gebruiken en een berg apps mee MOET installeren.

Wat google doet is gewoon tussen apple en stock android gaan zitten.

Wil je alles zelf doen? dan ga je stock zonder playservices.
Wil je de meest stabile ervaring tussen apps die gebouwd zijn om samen te werken met de dezelfde feel en update support voor aps die komen uit een "veilige" app store ?
Dan ga je voor de playservice met alles wat er bij komt.

Dat laatste is basically een open vorm van IOS van apple.

Als Google zijn eigen OS zou willen maken on van Java af te kunnen stappen en zelf alles helemaal naar zich toe te trekken lijkt me dat niet direct een slechte ontwikkeling.
En het rechtvaaridgd helemaal nog niet de haat die iedereen direct googles kant opschuift.

[K-aroq]

En waarom zou je als gebruiker van een apparaat altijd de mogelijkheid willen hebben of nodig hebben om zaken aan te passen? Heb jij ooit de noodzaak gehad om de software van jouw wasmachine aan te moeten passen om de was schoner te krijgen? Je kunt een product ook gewoon gebruiken, dat is nuttige dat tijd steken in het configureren een aanpassen en ondertusen geen tijd meer hebben om iets productief te gebruiken.

[BikkelZ]

Het probleem met Android is dat de applicaties, het OS en de hardware door drie verschillende partijen gemaakt wordt met verschillende doelstellingen, terwijl de wasmachinefabrikant gewoon tevreden klanten wil en zo weinig mogelijk kapotte wasmachines binnen de garantieperiode.

Maar als je bijvoorbeeld kijkt dat Safari onder macOS veel zuiniger is met batterij dan Chrome, dat heeft te maken met het feit dat Apple wil dat jouw hele ervaring (hardware+OS+applicatie) fijn werkt en dat Google alleen geïnteresseerd is in zo snel mogelijk méér advertenties laden, wat conflicteert met doelstellingen zoals batterijverbruik.

Zo moet je voor bepaalde (Huawei? Xiaomi?) telefoons jezelf specifiek aanmelden voor een push notificaties register omdat anders je push notificaties niet meer gegarandeerd aankomen. Dat is echt fucken met de basisfunctionaliteit van een OS omdat de hardware fabrikant liever een kleinere batterij installeert.

Een cleane installatie van Android voorkomt echt een heleboel problemen en is eigenlijk altijd aan te raden als het mogelijk is.

[oef!]

Afgezien van een paar liefhebbers zit er echt geen mens te wachten op een installatieprocedure op een telefoon. Het maakt een systeem alleen maar ontoegankelijker voor de meeste mensen.

[Cergorach]

Zowel Tweaker.net als jij zelf zijn weer lekker duidelijk. Benoem de aap dan bij zijn naampje! Wat voor license betreft het exact? Google heeft het zelf over MIT-style en BSD-style licenses voor verschillende onderdelen, "-style" is dus niet het benoemde license. Dus als je exact wil weten wat de license dan precies is, dat kan je voor de kernel hier zien:
https://fuchsia.googlesou...ter/zircon/kernel/LICENSE

Copyright 2016 The Fuchsia Authors
Copyright (c) 2008-2015 Travis Geiselbrecht
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Hoeveel vrijer/open wil je het hebben?

[StefanJanssen]

Het is wel open, maar fabrikanten die er gebruik van willen maken kunnen zelf hun spyware implementeren en hoeven de aangepaste code niet opnieuw te publiceren. Oftewel het orginele systeem is open, maar niet alle variaties erop zijn dat.

[Verwijderd]

Goed, dat is nu eigenlijk niet anders. Mensen trekken met hordes tegelijk Androidtelefoontjes uit China met weet ik wat erop geïnstalleerd. Die developers liggen vast dubbel als je komt aankloppen voor de broncode.

Publiceren Samsung e.d. al hun aanpassingen ook ergens voor elke telefoon?

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:31]

[mjz2cool]

Het is wel anders, aanpassingen aan de Linux kernel van Android moeten openbaar gemaakt worden. Het bovenliggende OS hoeft niet open source te zijn. Fuchsia gebruikt geen Linux, en volgens die licenties hoeven aanpassingen ook niet openbaar gemaakt te worden.
Zo publiceert Samsung als het goed is zeker wel hun aanpassingen. Alleen doen ze dit niet voor hun Touchwiz/Nature UX/One UI, wat volledig hun eigen software is. Android zelf is open source, maar de rom die ze er uiteindelijk van maken niet.

[Verwijderd]

Wassen neus dus. Leuk dat ik de Linux kernel in kan kijken, maar dat vergroot mijn privacy of veiligheid dus gewoon helemaal niet. Het maakt dus weinig uit welke kernel je eronder schuift als je vervolgens in een blackbox OS erboven allerlei fratsen uithaalt. De meeste schendingen die we volgens mij zien zijn telkens op OS/app-niveau, waarbij er van alles gelekt wordt naar Google/FB-apis.

[bskibinski]

Is dat zo?
Het dikgedrukte stukje van Cergorach:

"The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software."

Dat betekent dan toch dat hun aangepaste variant (dat is namelijk een copy of substantial portion of the software) deze notice ook moeten bevatten, en dus open hoort te zijn?

Ik ben geen licentie expert, maar dat is wel hoe ik het lees.

[mjz2cool]

Dat betekent dat die notice aanwezig moet zijn, niet dat de broncode beschikbaar moet zijn. Iedereen mag de software (al dan niet aangepast) verspreiden, maar hoeft de broncode niet openbaar te maken.

[bskibinski]

Ok er staat inderdaad niet dat ze het makkelijk bereikbaar moeten maken (zie edit onderaan), maar als iemand de broncode ook maar 1 keer uitlekt, kunnen en mogen ze daar dus niks aan doen? Een programmeur die er mee/aan werkt mag er namelijk mee doen wat hij wil, excerpt:

"to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction,"

De werkgever zal dan vast "niet blij" zijn, maar lijkt me dat je zoiets niet lang verborgen kan houden dan toch? Of begrijp ik dan weer iets van licenties niet goed?

edit: en trouwens, betekent deze zin niet dat ook mensen voor wie de software is gemaakt, deze rechten dus ook moeten hebben, en het dus ook voor hun beschikbaar moet worden gemaakt?

"and to permit persons to whom the Software is furnished to do so"

[Reactie gewijzigd door bskibinski op 23 juli 2024 09:31]

[mjz2cool]

Volgens mij klopt dat wel, de licentie verplicht je niet om de sourcecode beschikbaar te maken, maar het verplicht je ook niet om de sourcecode verborgen te houden.

[bskibinski]

Die laatste zin zegt toch dat je de code beschikbaar moet stellen, vertaald met google translate:

"en om personen aan wie de Software is verstrekt toe te staan dit te doen".

Dat houd dan toch in dat als ik van de aangepaste software gebruik maak (als end-user dus) de (bron)code mag opvragen, en zij mij die moeten/horen te geven?

[strigi]

Als de broncode is gelekt, dan heb je geen licentie gekregen en dus geen toestemming om de broncode verder te verspreiden.

Als je de broncode inclusief licentie hebt gekregen, dan mag je de broncode verder verspreiden.

Als je een binary heb op basis van MIT of BSD broncode, heb je geen recht op die broncode.

Als je een binary op basis van GPL broncode hebt, dan heb je het recht op die broncode en mag je een nieuwe binary maken op basis van die broncode en je mag de broncode met dezelfde rechten verder verspreiden.

De Linux kernel in Android valt onder GPL. Als je een Android telefoon hebt, heb je recht op de broncode en mag je een aangepaste versie (laten) maken. Zo kun je je hardware langer gebruiken en evt spyware vinden en verwijderen.

In Fuchsia heb je die rechten *niet*. Meehelpen aan Fuchsia is dus meehelpen aan het verdringen van Android en het verminderen van digitale rechten van gebruikers.

[bskibinski]

Maar zoals Cergorach zei, is dit geen MIT, maar een "MIT-style"
en hij plaatst vervolgens de precieze voorwaarden, en daarin staat toch (de korte relevante delen):

"Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction"

maar voornamelijk het belangrijkste deel:
"and to permit persons to whom the Software is furnished to do so"

Ik lees dit toch echt, dat als ik gebruik maak van Fuchsia (of een variant erop), ik recht heb om de code in te zien, en er vervolgens weer mee te doen wat ik wil. De laatste zin die ik quote vertaalt naar "en om personen aan wie de Software is verstrekt toe te staan dit te doen". Dus niet aan wie de "code" is verstrekt, maar de software.

Daarbij hoort deze licentie inherent bij de code, omdat de licentie dat zelf ook weer voorschrijft:
"The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software."
Dus als je de code hebt, heb je de licentie, die "krijg" je niet los van een instantie ofzo, het is een onderdeel van deze codebase zelf.

Tenminste dit is hoe ik het interpreteer, ik hoor graag wat ik hier verkeerd zou begrijpen, of wat ik dan verkeerd lees, dan leer ik er ook iets van
(en ik heb het dus niet over de standaard MIT license, maar de license die dus bij fuchsia hoort)

[strigi]

De licentie die je linkt is exact de MIT license. Dus alles wat ik hierboven zei is van toepassing. De term 'Software' in die licentie slaat op de broncode en niet op eventuele binaries die je daarvan maakt.

Als je in de toekomst een telefoon met Fuchsia koopt, op basis van de MIT license, heb je geen recht op de broncode van de precieze versie op je telefoon. Bij Android op basis van de Linux kernel met GPL licentie heb je dat recht wel.

Zoals Eonfge hierboven zegt vinden telefoonmakers dat fijn omdat er zo meer lock-in is. Mensen die willen tweaken kunnen nu nog de GPL drivers opvragen om een aangepaste versie te maken. Met Fuchsia worden de drivers vrijwel zeker gesloten modules.

[bskibinski]

"De licentie die je linkt is exact de MIT license" Idd Had ik zelf ook wel even kunnen opzoeken.

Check, duidelijk verhaal met de binaries idd, en ze hoeven het dan niet 'vrijwillig' vrij te geven.

Maar deze statement:
"Als de broncode is gelekt, dan heb je geen licentie gekregen en dus geen toestemming om de broncode verder te verspreiden."
Dat snap ik dan niet zo goed. Als jij die (aangepaste) files in handen zou krijgen, heb je toch de code met bijbehorende licentie, om er vervolgens toch weer mee te doen wat je wilt?
deze zin uit de licentie:
"to any person obtaining a copy"
Misschien is dit weer te juridisch voor mij, maar er staat "obtaining" en niet "issued by" oid. Dus als ik het (ver)krijg, zou ik het mogen gebruiken lijkt me?

Maar iig thx voor je uitleg.

[K-aroq]

Wireshark er op en je ziet meteen of er verdacht verkeer is.

[SuperDre]

Tja, dat is bij Linux ook niet anders hoor.

[StefanJanssen]

De Linux kernel is GPL welke zegt dat elke wijziging onder dezelfde licentie gedeeld moet worden met een vermelding dat het om een aangepaste versie gaat:

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

[Eonfge]

Klassiek voorbeeld van The Paradox of tolerance. De MIT, BSD en dergelijke licenties zijn zo 'vrij' dat ze jou niet beschermen tegen de (misbruik van) macht van anderen.

[Raymond Deen]

Wat @Eonfge doet, is zorgen uitspreken over de gekozen licentievorm met daarbij de motivatie van die zorgen.
Dat lijken mij heel reële zorgen, omdat de eindgebruiker in een zwakkere positie komt tegenover de fabrikant die de eindgebruiker effectief minder eigenaar maakt van het gekochte product.
Ik doel daarbij op in een latere versie van firmware ineens beperkingen aanbrengen die tijdens de aankoop nog niet bestonden; dat hebben we de laatste tijd al een aantal keer voorbij zien komen in het nieuwsoverzicht.

[SwaggyEggs]

Only a sith deals in absolutes

[Chinco]

Als mogelijke, toekomstige gebruiker heb je toch alle recht op een mening? Dat is ook financieren, hoor. Dat draait een bedrijf zelfs op en om.

Ik heb geen moeite met het model dat Microsoft hanteert, maar daar mag iemand anders best een andere mening over hebben.

[candela]

Jij snapt helaas niet waar Eonfge het over heeft. Het gaat niet over vrijer/open maar over het afdwingen van gebruikers rechten

[Cergorach]

Hij heeft het over een 'gebruikers respecterende licentie', dat is deze licentie. Het is Open Source. Wat het niet doet is fungeren als een infectie factor die alle software die ervoor gemaakt wordt niet ook hetzelfde licentie afdwingt. De licentie zelf respecteert de gebruiker wel degelijk! Ik heb ook liever een GPL, maar er is een reden waarom veel bedrijven juist dit niet gebruiken, omdat het hun product in de weg zit omdat ze het moeten opensourcen. Of ze gebruiken het wel, maar geven het broncode alsnog niet vrij, daar heb je er ook zat van.

Het voordeel hiervan is en blijft dat het OS open source blijft en aan de producent is of ze hun eigen software wel of niet open sourcen. Dan kan je prima zelf de keuze maken of je dat product wel of niet wil hebben op basis van die beslissing. Maar mensen kunnen nu prima zelf wat bouwen op die hardware... Als we echter naar Android kijken is die zelfbouw nu niet super ingrained als je kijkt naar de brede adoptie van Android.

[T-men]

Met Fuchsia is Linux niet opeens weg dus daar veranderd niet veel aan.
En die "natte droom voor elektronica fabrikanten" bestaat al in de vorm van Windows, iOS, Android enz.

[Blokker_1999]

Nee, maar als Google Fuchsia doorontwikkeld als toekomstige vervanger van Android, dan kom je op ene gegeven moment wel op een punt dat ze de wissel gaanmaken en wordt die droom voor telefoonfabrikanten wel waarheid.

[davekok]

Proberen alles in een licentie op te lossen gaat natuurlijk nooit werken. De wetgever zal simpelweg beperkingen moeten stellen aan wat een leverancier wel en niet mag doen, m.b.t. AVG, beveiliging, recht op reparatie, zelf mogen aanpassen, doorverkoop en meer. Het auteursrecht is in eerste plaats bedoelt om de auteur te beschermen tegen machtsmisbruik, niet om de consument te beschermen tegen de auteur of tegen tussenpersonen. Een consument zal simpelweg moeten overwegen of die iets wel of niet wil kopen en daarbij degelijk onderzoek doen.

[Loller1]

Altijd leuk om te zien hoe mensen de vrijheid van software verdedigen zolang dat *hun* vrijheid is, maar dat de maken vrijstaat om een licentie te kiezen? "No no, mijn licentie of je bent gemeen!"

[joco]

exact, ik moet de vrijheid hebben van code die ik schijft die alleen maar eventueel gebruik maakt van andere open software componenten kunnen licentieeren hoe ik het wil, dat moet mijn vrijheid zijn mijn keuze.

Behalve natuurlijk als ik er niet echt gebruik van maak maar ook verander (Dus fork en een eigen build er van maak) dan moet ik voldoen aan de licentie voorwaarden van dat software component.

[Verwijderd]

Het staat toch elke fabrikant vrij om gpl software te gebruiken om daarop eigen propriety software te draaien? Dat is wat er gebeurd met Android en al zijn varianten en UI schillen.
Ik zie het verschil niet zo.

[K-aroq]

Precies. Sommige mensen denken blijkbaar dat als je open source/GPL gebruikt alles wat geleverd wordt open is. Maar er zijn genoeg voorbeeld van software waarbij open source componenten worden gebruikt naast closed software. Ik denk eerlijk gezegd dat er meer producten met een combinatie van open en closed dan producten met volledige open software.

[Verwijderd]

Hear! Hear!

[joco]

maar welke licentie zouden we moeten hebben dan?
GPL werkt niet (Die vermijden wij ook als de pest in onze bedrijf)

ik vind het prima als ik open source componenten gebruik en ik maak daar wijzigingen in dat ik dat moet vrij geven onder dezelfde licentie

Maar ik moet code die ik zelf gebruik die gebruik maakt van de open source component (Dus als lib) op mijn licentie die ik kies moeten kunnen gooien, kan een andere open source licentie zijn, kan closed source. Dat moet gewoon mijn keuze zijn
Het kan niet zijn dat puur door gebruik van een component die voor mij een black box is dat ik plotseling moet voldoen aan hun licentie. (behalve als dat geld voor wijzigingen in die black box, die moet ik vrij geven en open sourcen)

Het lijkt dat LGPL dat precies is maar het is nu een beetje vaag of dat echt zo is.

[Eonfge]

GPL werkt niet (Die vermijden wij ook als de pest in onze bedrijf)

Having ones cake and eating it too?

Als ik het goed begrijp zoek jij dus als bedrijf een licentie die jouw alle rechten geeft om te doen wat je wilt, maar je wilt vervolgens jouw eigen product uitbrengen onder een licentie die niet die zelfde rechten beschermt? In deze discussie wilt jouw bedrijf dus het zelfde als Google.

En dat is jouw probleem als bedrijf, en als gebruiker moet ik dus alert zijn want jullie willen mij duidelijk benadelen. Begrijp goed dat de LGPL en GPL niet bestaan voor het beschermen van bedrijfsbelangen, maar voor het beschermen van gebruikersrechten. Je kunt dus kiezen of delen: Of je gaat gebruikersrechten respecteren met de zelfde rechten die jij als ontwikkelaar hebt, of je blijft weg bij de GPL.

De LGPL (Lesser GPL) probeert nog een soort van compromis te vinden, en deze is dan ook heel geschikt voor libraries: Alleen (indirecte) aanpassingen aan de library vallen dan onder de GPL. Deze zie je in de FLOSS wereld dus veel terug bij bijvoorbeeld UI kits (zie bijvoorbeeld GTK).

[joco]

klopt helemaal

komt ook bij dat wij wel heel veel terug sturen en ook vele pull request doen (deze week al 2 stuks, vorige week zeker 3a4 over meerdere projecten)

dus ja wij supporten heel veel open source en geven ook heel veel terug.

Maar onze core is wat wij verkopen en dat is dus niet GPL, ik moet ook brood op mijn plank hebben.

Anders had je nergens producten die je kunt verkopen alleen maar support en zo werkt ons bedrijf niet.
(en vele andere)

Ja LGPL gebruiken we wel, dat is tenminste een wat vriendelijke, zoals ik al zei wij hebben geen probleem mee om terug te geven en vele patchen en pull request te doen.
Grote delen van onze code base is open source, maar niet alles, en dat kan dus niet met een GPL licentie.

Kun jij mij eens uit leggen hoe het kan dat NVidia close source drivers heeft op linux?

[Eonfge]

Het blijft inderdaad lastig om een competitief product te maken onder de GPL. Closed-source software is een stukje economische macht die jij, of andere grote software boeren, kunnen gebruiken om in de beginfase concurrenten weg te drukken. In een wereld waar 95% closed source is, doe jij jezelf als onderneming tekort door meer respect te hebben voor je gebruikers.

Zie bijvoorbeeld bestandsformaten. De helft van de macht die bedrijven zoals Microsoft en Adobe hebben, zit hem in hun gesloten bestandsformaten. Nu kun jij een text-editor maken als concurrent, maar als je dat doet met open standaarden dan is dat alleen maar in je eigen nadeel: Jij kunt dan nog steeds niet de documenten van de concurrent lezen, maar andersom wel.

GPL software kan dus ook alleen werken als klanten het eisen en als ze vervolgens ook bereid zijn te betalen. Anders zal de kortzichtigheid van klanten, ze later met veel duurdere closed-source producten opzadelen. Immers, closed-source producten streven per definitie naar een vendor-lock, en als die er eenmaal is dan ben je als klant de sjaak.

Kun jij mij eens uit leggen hoe het kan dat NVidia close source drivers heeft op linux?

Hoofdpijn. Zo doen ze dat... Oke, korte uitleg.

De Linux Kernel is GPL 2.0. Echter zitten er ook op de GPL enkele rationele beperkingen. Zo gaat de GPL pas in dienst treden als je software distribueert. Zolang het dus alleen op jouw eigen computer/server/smart-dinges staat hoef jij je niet aan de GPL te houden. Conceptueel logisch, de GPL is er om jouw gebruikers te beschermen, dus de licentie gaat dan ook pas in werking.

De Linux Kernel heeft ook een speciaal module-systeem. Op deze manier kan het logica inladen vanuit pakketten die los worden gedistribueerd. Dan kun je eventueel een hele kleine Kernel bouwen en aan de hand van andere pakketten, extra modules inladen.

NVidia combineert die twee met hun eigen drivers. Als Linux gebruiker download je de binaries als onderdeel van een extra pakket, en wanneer je deze modules installeert, compileert de installer een kleine shim tussen de binaries van NVidia en de Linux Kernel. Het is vervolgens verboden om deze shime te distribueren, maar het is (binnen de hopeloze licentievoorwaarden van NVidia) wel toegestaan deze te gebruiken op je eigen machine.

NVidia drivers zijn trouwens niet de enige die dit hebben. FFmpeg (de backend van VLC) heeft ook enkele codecs die ze wel als source distribueren, maar niet als binary, omdat er GPL licentie conflicten in zitten.

[Reactie gewijzigd door Eonfge op 23 juli 2024 09:31]

[Korben]

Closed-source software is een stukje economische macht die jij, of andere grote software boeren, kunnen gebruiken om in de beginfase concurrenten weg te drukken.

Als het gaat om concurrenten, sure. Wat dacht je van klanten? Wie gaat er nog flink wat geld neerleggen voor iets als Photoshop als de broncode vrij beschikbaar is? Closed source is in veel gevallen een noodzaak, omdat mensen zich nou eenmaal niet aan de regels houden. Als een filmmaatschappij een film in goede kwaliteit ter download aan zou bieden met een Tikkie ernaast, ‘vergeet niet om nog ff te betalen’, dan weet iedereen wat er zou gebeuren. Een hoeveelheid überdegelijke mensen zou netjes betalen, maar de meerderheid zou dat niet doen.

Zie bijvoorbeeld bestandsformaten. De helft van de macht die bedrijven zoals Microsoft en Adobe hebben, zit hem in hun gesloten bestandsformaten.

Het is wel heel erg jaren-‘90-denken om te zeggen dat Microsoft macht heeft door gesloten bestandsformaten. LibreOffice kan gewoon Word-documenten lezen en schrijven, en er zijn honderden library’s die dat ook kunnen. De waarschijnlijke reden dat Office zo populair is, is omdat het gewoon goed is. En de reden daarvoor is dat veel componenten van Office ouder zijn dan de gemiddelde Tweaker waarschijnlijk (Word 1.0 kwam uit in 1983), en hoewel het véél concurrentie heeft gehad, is het zo ongeveer de enige van enige relevantie die nog over is. De meeste closed-sourceprojecten kunnen niet opboksen tegen 37 jaar evolutie, en bij open source zal dat nog minder zijn, vanwege de overhead die open source met zich meebrengt.

[Pinkys Brain]

NVIDIA distribueert hun drivers niet samen met de kernel, dus de enige manier waarop de GPL voor hun van belang kan zijn is als ze de kernel headers gebruiken in de driver.

Het zijn de distros die zich schuldig maken aan contributory infringement of in het geval van Ubuntu zelfs rechtstreeks (staan op dezelfde iso). Maar tot nog toe is niemand naar de rechter gestapt.

[Reactie gewijzigd door Pinkys Brain op 23 juli 2024 09:31]

[joco]

het lijkt me sterk dat ze toch niet iets van linux gebruiken (een interface die ze moeten implementeren) voor hun driver om te integreren met linux

Het lijkt me echt sterk at de hun driver kan compileren zonder ergens tegen gpl code aan te linken.

En dan is de grote vraag, nee zij distribueren het niet met een kernel of distribute (dat doen anderen dus)

Maar op het moment dat zij het op een site zetten zodat je het kunt downloaden, distribueren ze het toch?

Op een site staat een download van software wat absoluut niet compileert zonder GPL code en dat mag je dus gewoon aanbieden? Lijkt mij niet want waar is dan de scheidslijn met ons product waar wij misschien ook ergens tegen GPL aan compileren en dan ons product shippen?

[Pinkys Brain]

Ze hebben een GPL shim (denigrerend ook wel condoom genoemd) waar ze zelf copyright voor hebben (die is voor hun dus geen GPL). Ze gebruiken de API van de shim voor hun driver, dus ze hebben zelfs geen kernel header nodig (header gebruiken is ook niet echt linken en hij kan reverse engineered zijn).

Omdat de GPL alleen maar toepasbaar is bij distributie mag je inderdaad code aanbieden die alleen maar compileert met GPL code, zonder het GPL te maken. Maar je moet een beetje voorzichtig zijn met headers, daarom de condoom methode van NVIDIA.

[McBacon]

in het geval van Ubuntu zelfs rechtstreeks (staan op dezelfde iso)

Ik denk dat je nouveau bedoelt. ;] Da's een reverse engineered, open saus (en "free", als in "vrij", niet "gratis") variant van de non-free NVidia driver. Die hebben ze gemaakt zodat je kernel niet "tainted"' wordt door incompatible licences. Ubuntu zelf doet dus geen infringement/violation.

[BikkelZ]

Ik heb al weer gelezen dat het gebouwd is op C/C++ en dat Dart de hoofdtaal wordt om apps mee te bouwen. Bovendien is Rust wel toegestaan maar niemand heeft er wat meer gedaan:

https://fuchsia.dev/fuchs...icy/programming_languages

Google is echt in de jaren '90 blijven hangen. Wie gaat er bij de mogelijkheid van een schone lei toch alsnog voor bewezen problematische en oubollige oplossingen? C en C++ zijn gewoon niet veilig voor de hackers van de 21ste eeuw en Dart is gewoon een soort pseudo Java laag over JavaScript waar je ook niet echt vrolijk van wordt. Had ook net zo goed Kotlin kunnen zijn want dat kennen de meeste mobiele ontwikkelaars toch wel, al is het maar doordat Swift er zo veel op lijkt.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 09:31]

[Creesch]

Mja welke taal suggereer jij dan? C/C++ is toch nog echt een veel gebruikte taal als het gaat om OS/Kernel ontwikkeling en gezien Linux ook de taal waarmee je het meest eenvoudige ontwikkelaars kan binnenhalen die al goed bekend zijn met OS ontwikkeling.

De eerste stabiele release van Kotlin was in 2016, de eerste keer dat er nieuws over Fuchsia naar buiten kwam was iets later in dat jaar. Google was toen waarschijnlijk al langer met het project bezig.

Voor Rust geld zo ongeveer hetzelfde maar dan iets een jaar eerder qua stabiele release. Er zullen dan ook zeker in het begin weinig programmeurs bekend zijn geweest met Rust en zeker niet met Rust en OS/Kernel ontwikkeling.

Betreffende Dart heb je het redelijk mis aangezien het een taal is C-stijl syntax die kan compileren naar JavaScript voor gebruik in browsers maar ook kan compileren naar native code. Wat dat betreft eigenlijk heel geschikt in de context van een OS waarvan de ontwikkelaars ook al bekend zijn met talen in C-stijl syntax.

[BikkelZ]

Mja welke taal suggereer jij dan? C/C++ is toch nog echt een veel gebruikte taal als het gaat om OS/Kernel ontwikkeling en gezien Linux ook de taal waarmee je het meest eenvoudige ontwikkelaars kan binnenhalen die al goed bekend zijn met OS ontwikkeling.

Linux komt uit begin jaren '90, ik kan daar niet te hard over oordelen natuurlijk. Maar ook Linux heeft inmiddels de eerste Rust patches ontvangen.

De eerste stabiele release van Kotlin was in 2016, de eerste keer dat er nieuws over Fuchsia naar buiten kwam was iets later in dat jaar. Google was toen waarschijnlijk al langer met het project bezig.

Google is in principe een stap achteruit gegaan van de JVM naar de JS VM, ik ben geen enorme fan van bepaalde limitaties die de JVM heeft ten opzichte van bijvoorbeeld .net maar het is veilig, wijd ondersteund en je kunt er legio talen op draaien. Dus een pivot van Java naar Kotlin was vrij makkelijk te doen geweest als ze al niet waren begonnen met de vergissing om voor de JS VM te gaan.

[David Mulder]

Om Dart aan te halen als 'echt in je jaren 90 blijven hangen' kan ik oprecht niet begrijpen. Het is een fijne en erg flexibele taal. Bijna iedereen die ik heb gezien die een serieus project heb zien doen in Flutter was er erg positief over en ook mijn eigen beperkte ervaring was ook erg positief. Iedere taal heeft natuurlijk z'n voordelen en nadelen, maar deze aanval lijkt me verwarrend sterk.

"C++ zijn gewoon niet veilig voor de hackers van de 21ste eeuw" Een taal is gewoon zo veilig of onveilig als je er in programmeert. Natuurlijk maken sommige talen het makkelijker en moeilijker om 'gevaarlijke' fouten te maken, maar wat betreft veiligheid zijn de risico's tussen (modern, juist geconfigureerd) C++ en Rust zover ik weet vergelijkbaar (en C geeft inderdaad meer vrijheden).

Wat betreft de keuze Rust vs C/C++ vind ik meer interessant, maar goed, Rust was nog maar 5 jaar oud toen ze met Fuschia begonnen, dus kan me inderdaad een bepaalde terughoudendheid voorstellen.

[Verwijderd]

Ik werk aan Android projecten, waarbij dus de meeste developers van Java naar Kotlin zijn overgestapt in de laatste ~4 jaar.
Bijna iedere developer in die context vindt Dart een stap terug, na Kotlin. Er zijn natuurlijk een paar uitzonderingen, maar die kan ik op 1 hand tellen.

Wat betreft het statement van "in de jaren 90 blijven hangen": Ik kan dat dus best begrijpen.
Heel veel zaken die we tegenwoordig (Kotlin/Swift/Rust/etc.) als vanzelfsprekend beschouwen, zitten namelijk niet in Dart.

Hier zijn wat zaken om dat te onderbouwen:
- null safety (alhoewel deze wel al in een beta zit, had dit er van in het begin moeten inzitten)
- generic variance leidt tot crashes ipv compile error (variabelen in generic classes zijn covariant)
- gevaarlijke impliciete type conversies waarbij data verloren kan gaan (bvb. num aan int assignen zonder casten)
- geen final classes
- geen type aliases
- geen sealed classes
- lijn beeindigen met ";"
- bizarre syntax keuzes (optional arguments, "@override" als annotatie, bloated lambda syntax, ...)
- etc.

Als je van Java komt, dan is Dart voor de meeste mensen waarschijnlijk een verbetering.
Als je van een meer moderne taal komt (Kotlin, Swift, Scala, etc.), dan voelt Dart al snel aan als meerdere stappen terug.

[BikkelZ]

Bijna iedereen die ik heb gezien die een serieus project heb zien doen in Flutter was er erg positief over en ook mijn eigen beperkte ervaring was ook erg positief.

Kom je van JavaScript af is het wellicht een redelijke verbetering. Kom je van Kotlin en Swift af dan is het echt maar een lullig taaltje. Nu zag ik weer een proposal voorbij komen dat ze non-null references willen introduceren (also ze in 2016 daar nog niet van hadden gehoord!) en ze gaan het op ongeveer de zelfde slechte manier doen als Java en C# het hebben gedaan. Wat ik wel leuk vind zijn die auto constructors waarbij je niet bepaalde velden die simpelweg geset worden via de constructor nog eens handmatig in de body van de constructor moet doorzetten.

deze aanval lijkt me verwarrend sterk.

Totaal niet. Het is gewoon een aantoonbaar zwakkere taal dan bijvoorbeeld Kotlin. En je moet het ook los zien van Flutter zelf, het layout systeem in Flutter is echt extreem goed en er zijn nog een aantal dingen echt goed gelukt. Ik was er zelf ook heel snel productief in. Maar Dart was gewoon een misser.

Een taal is gewoon zo veilig of onveilig als je er in programmeert.

Dat is een lekenmening, de ingebouwde garanties die een taal als Rust heeft zorgen er voor dat zelfs totale prutsers nog veiligere code schrijven. Sommige talen hebben weer betere garanties over correcte uitkomsten dan C. Het is gewoon wiskunde: bepaalde uitkomsten zijn vaak bij voorbaat niet mogelijk bij de juiste formule. Bij C( en ten dele ++) moet je zelf die formule nog bouwen én verifiëren. Bij andere talen weet je gewoon dat dingen correct zijn omdat het afgedwongen wordt.

C is een simpele abstractie over assembler waarmee je direct het geheugen manipuleert, goedschiks of kwaadschiks. Rust heeft allerlei compile time garanties die er voor zorgen dat kwaadschiks veel minder makkelijk mogelijk is zonder direct performanceverlies te lijden. C is geschreven voor compilers uit de jaren '70 die op 8 kilobyte RAM machines moesten kunnen werken, Rust is geschreven voor compilers van na 2010 die 8GB aan RAM hebben en miljoenen keer sneller zijn qua CPU. Mag er alsjeblieft iéts beter zijn geworden in 40 jaar?

Rust zorgt niet magisch voor alleen maar veilige code, maar als je kijkt waar de exploits keer op keer te vinden zijn en de garanties die Rust heeft is het wel een beetje nalatig om maar voor C en C++ te gaan "want dat kent iedereen tenminste". Volgens mij zitten legioenen aan programmeurs te springen om iets met Rust te mógen gaan doen.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 09:31]

[drZymo]

Vergeet niet dat moderne talen zoals Rust (zover mij bekend is) nog een standard library en bepaalde OS functies nodig hebben. Om dus de executables te kunnen draaien die uit een moderne programmeeromgeving komen moet je al een OS met libraries hebben.

Dus als je een kernel en een OS gaat maken, is die standard library er nog niet. Denk aan iets simpels als een geheugen allocatie. Daar heb je een component voor nodig dat het geheugen beheert. Dat heeft een Rust executable dus ook nodig om te kunnen functioneren. Als je een OS gaat maken zal je eerst met C of assembler zo'n geheugen manager moeten maken voordat je naar een modernere taal kunt overstappen.

[Pinkys Brain]

Libcore kan gebruikt worden in Rust zonder user space standard library.

Rust is ontworpen als systeem programmeer taal, het voornaamste probleem is hoe nieuw en onstabiel het is. Aan de andere kant, van de enige andere realistische systeem programmeer talen weten we al 30 jaar dat ze een gigantische ramp zijn. Je ontkomt niet aan geheugen exploits in c(++), dat kan je niet fixen met review en offline tools. Unsafe by default is geen optie.

[BikkelZ]

Je hebt natuurlijk heel weinig nodig om een kernel te schrijven aangezien die kernel juist de bodem is voor de rest van een OS. En de standaard library van C is ook geen enorm uitgebreid ding, dat kon vroeger niet eens. Rust is al jaren redelijk compleet anders kon je er ook geen browser in schrijven, wat in principe een soort mini OS is tegenwoordig.

[ilPazzo]

En waarom is dit nodig? We hebben Linux al als general-purpose OS, en dat zit tenminste niet vol met Google-spyware...

[ErikJonker]

...als het echt een open-source OS wordt zoals linux dan kun je net zo goed vaststellen of er wel of geen spyware in zit

[Blokker_1999]

Met dat verschil dat dit met een licentie zal komen die er net voor zorgt dat de ontwikkeling wel open gebeurd, maar dat bij gebruik in productieomgevingen de fabrikanten niet langer hun code openbaar moeten maken.

[walteij]

Dus geen GPL, maar dan denk ik eerder aan de Apache License 2.0, die licentie wordt ook voor Android gebruikt. Nog mooier zou een BSD licentie zijn, dat is de meest vrije licentie die je je maar kunt voorstellen.
De vraag is of Google/Alphabet blij zou zijn met een dergelijk vrije licentie voor dit OS.

[Cergorach]

Hoeveel mensen compilen zelf hun Linux?

[Omega]

Het OS zelf kan open zijn, maar de extensies die er aan worden vast gesteld hoeven dat niet te zijn onder een permissieve licentie.

Android is hier een voorbeeld van dat onder de Apache licentie en de GPLv2 valt. Er word vaak genoeg spyware zooi geïnstalleerd op devices die met Android komen.

[teek2]

Ik vind Linux geweldig en draai het overal, maar soms is het ook goed om opnieuw te beginnen met iets en alles achter je te laten. Linux is toch al 25 jaar oud en ondersteunt nog veel oude hardware, als je dat allemaal achter ja kunt laten, dan maak je een ander OS, waar Linux misschien later weer wat van kan leren.

[Omega]

Linux doorgaat regelmatig grote schoonmaak periodes waar er meer code word verwijderd dan ingevoegd. Ondersteuning voor nauwelijks gebruikte hardware word regelmatig gedropped tenzij iemand bezwaar heeft.

Linux heeft de drivers voor interne floppy drivers al een tijdje in het vizier, de persoon die deze driver onderhoud kan namelijk niet meer aan nog werkende interne floppy drives komen om de driver te testen. Voor de duidelijkheid, USB floppy drives vallen hier dus niet onder.

Daarnaast hoef je ook niet de support voor deze oude hardware te compilen in je eigen build van de Linux kernel, je kan gemakkelijk een kernel bouwen die specifiek is voor jou hardware configuratie, alleen 64-bit ondersteund en op boot een schattige Tux pinguin toont voor elke thread die je CPU heeft etc..

Mocht Linux binnenkort Rust gaan toestaan in de kernel dan bestaat de mogelijkheid dat mensen grote delen van de kernel herschrijven en refactoren.

[Reactie gewijzigd door Omega op 23 juli 2024 09:31]

[Alfa1970]

De kracht van Linux is de compatibiliteit, en dat is meteen ook de crux waarom innovatie op dat platform al lang niet meer zo evident is als in het begin.
Wat dat betreft ondervindt Linux dezelfde problemen als Microsoft met Widows doet.
Omdat het compatibel moet zijn, zijn bepaalde innovaties niet mogelijk omdat dat zou betekenen dat de meeste software niet meer draait. En dat gaat dan voornamelijk om de software die (veel) geld kost.
Voor jan de keuterboer op de hoek niet zo'n probleem maar voor bedrijven die serieus hebben geinvesteerd een onoverkomelijk probleem.

[HollowGamer]

Windows is ook 25 jaar oud, voor MacOS weet ik het niet, maar ook hun geschiedenis gaat heel ver terug. Beide draaien nog, al zouden zeker genoeg zaken herschreven kunnen worden.

Een OS bouwen is niet zo eenvoudig, het is erg complex. Een land als Rusland en China bouwen zelf ook geen OS, maar kiezen ook iets dat al bestaat. Voordeel is dat je software erop draait en je weet dat het al jaren wordt gebruikt.

[bilkin2005]

Windows stamt uit 1985 en dat is 35 jaar geleden.

[K-aroq]

Precies. Soms moet je opnieuw beginnen om verder te kunnen komen. Linux zelf is als minstens 25 jaar oud maar de basistechnologie nog veel ouder. Dat betekent dat nieuwe soorten softwarearchitectuur nog steeds gebaseerd moeten zijn op iedeeen van 50 jaar geleden. Als je echte doorbraken mogelijk wilt maken moet je soms afscheid nemen van wat er is.

[bilkin2005]

Linux is 29 jaar oud.

[PdeBie]

Moet iets persé nodig zijn? Als Google hierin willen investeren is dat toch hun goedrecht?

[HollowGamer]

Ik heb liever dat Google investeert in Linux. Er draait ontzettend veel software & hardware op Linux en er wordt door veel andere fabrikanten en mensen aan bij gedragen. Een nieuw OS zorgt ook weer wat mensen mogelijk afstappen van Linux en er fragmentatie ontstaat.

Er moet nog veel gebeuren met Linux, maar met elke kernel release komt er weer verbetering en worden zaken opgeruimd. Buiten de kernel heeft Linux al steeds meer gebruikers, maar nog steeds te weinig ontwikkelaars. Ik ben bang dat Google die groep wilt aanspreken en dan vervolgens weer hun eigen implementaties op dit OS gaat maken. Hetzelfde wat ze doen met Chrome en Chromium.

Ik zeg niet dat het OS géén potentie heeft, enkel dat ik het jammer zou vinden als Linux nu opeens uit elkaar valt en Google net zoals met het web de standaard gaat bepalen.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 09:31]

[MiesvanderLippe]

Omdat een frisse blik op een kernel architectuur en het vanaf de grond af gebruiken van moderne technieken en talen echt onwijs interessant is! Dit is echt een super vet project. Ja Google maar wie heeft er anders tijd om een OS te ontwikkelen?

[amst3l]

Apple bijvoorbeeld! Denk ook zeker dat het een meerwaarde kan zijn om iets van de grond af aan zelf op te bouwen met de opgedane kennis. Zie bijv. de M1 chip van Apple

[Arrigi]

Nextstep/Apple masseert hun eigen kernel nu al 30 jaar precies op maat van hun eigen producten en is niet bang om in de loop van enkele OS-releases diepgaande veranderingen door te voeren zonder oog voor backwards compatibility.
Ik denk dat ze de nodige architecturele aanpassingen in de huidige situatie wel doorgevoerd krijgen

[HollowGamer]

Je weet dat de basis van Apple BSD is toch? Ja, ze bouwen hun eigen OS en er is inderdaad veel vanaf de grond opgebouwd, maar echt iets vanaf 0 zonder enige referenties van andere projecten doet vrijwel niemand.

[Korben]

Niemand meer, inderdaad. Waarschijnlijk het meest recente wijdverspreide OS dat ‘vanaf nul’ is ontworpen is Windows NT, en zelfs dat heeft veel weg van DEC VMS. Het kostte ongeveer 4 jaar om uit de grond te stampen voor een groot bedrijf als Microsoft.

[K-aroq]

Er zal bij Apple ook ongetwijfeld onderzoek worden gedaan naar nieuwe softwarearchitecturen. Net als bij Microsoft, IBM en noem maar op.

[Alfa1970]

Heh, nee, dat zit vol met spyware van degene die de distributie doet. Lees Canonical of Red Hat die beiden ook nogal wat boter op hun hoofd hebben wat dat aan gaat, de anderen ben ik wat minder bekend mee, maar er zal ongetrwijfeld in elke distributie wel ET-Phone-Home verborgen zitten op een of andere manier, al was het maar om te checken of en hoe veel mensen het hebben draaien..

[teek2]

Geen idee hoe het met RedHat zit maar Ubuntu stuurt 1 json na installatie en die kan je inzien en kiezen om niet te sturen. Als je die niet stuurt gaat er 1 ping uit die zegt dat er installatie bij is gekomen. Wat is er nog meer dan?

[Reactie gewijzigd door teek2 op 23 juli 2024 09:31]

[Alfa1970]

Reclame in de motd is de mindste denk ik.

[Tworkk]

Tja, en 100 jaar geleden hadden ze al papier dus waarom zou je nog verder kijken.
Het probleem met zulke stellingen is dat je dan heel snel vast komt te zitten. 'waarom moeten we dit doen, we hebben al iets wat werkt' is de dooddoener van innovatie.

[Omega]

Met Linux verwijs je ook naar Android of alleen GNU/Linux en andere traditionele Unix-like Linux varianten zoals Busybox/Linux?

Als ze er spyware in willen rammen mag dat met Linux. Alleen moeten verandering aan de kernel en andere software dat valt onder de GPL licentie beschikbaar worden gesteld. En ik het geval van GPLv3 software moeten ze ook de code van extensies beschikbaar stellen. Ze rammen ook al enorme hoeveelheden aan proprietary spyware in Android en ChromeOS.

Het doel van dit OS is dat het mogelijk is onder de permissieve licentie om er een enorme black box van te maken als je dat wil. Neem de Sony Playstation als voorbeeld, daar draait FreeBSD op.

[YangWenli]

Omdat ze dit op hun goedkope Chromebooks kunnen pleuren en dan lekker advertenties en tracking draaien.

[dakathefox]

De "waarom" vraag is natuurlijk de meest onzinnige vraag die er is. Als iedereen zo dacht, dan zaten we natuurlijk tot op de dag van vandaag nog in MS Dos te werken of bestond de elektrische auto nu niet.

[SuperDre]

Tja, maar je hebt toch ook honderden smaken van Linux, waarom zou je dan ook zoveel smaken nodig hebben?

[ACL]

Technisch voordeel is dat Fuschia een microkernel architectuur heeft..

[HollowGamer]

Legt maar uit wat het voordeel is dan.

Ik mis nu niet iets aan de Linux-kernel. Alles wat ik nodig heb zit erin en op een redelijke PC kan je Linux bouwen binnen een half uur, nog minder als je zaken eruit haalt zoals bepaalde drivers/services. Het is juist een kracht van Linux dat je niet op het web moet zoeken naar drivers, laat staan dat deze goed geprogrammeerd of veilig zijn.

[MiesvanderLippe]

Het merendeel van de drivers is toch compleet irrelevant voor een laptop / tablet / telefoon? Ja je zal wat USB drivers nodig hebben maar de Linux kernel zit ook vol met support voor 20 architecturen en 1600 verschillende chipset.

[Pinkys Brain]

Het maakt driver isolatie makkelijker, over het algemeen zullen die geschreven worden onder de aanname dat ze in hun eigen adres space draaien. Kan je ze evengoed in kernel space draaien om context switches te vermijden, maar je hebt de optie.

[Omega]

De Linux kernel is niks meer dan eer grote berg aan drivers. De technologieën rondom die drivers word continue doorontwikkeld met nieuwe functionaliteit en verbeteringen. Daarnaast doet de kernel zelf niks, de software die jij er bovenop legt is wat het systeem functionaliteit geeft.

[amst3l]

Alleen vind ik dit dan toch weer een beetje jammer... https://fuchsia.dev/fuchs...terminology_to_be_avoided

Ik snap best dat iemand sommige dingen als racisme o.i.d. kunnen ervaren, maar soms heb je nou ook eenmaal een term waar 0,0 racistisch gedachtegoed achter zit.

[fapkonijntje]

Is hippe marketing hè, tegenwoordig.

[Klaus_1250]

Ik word echt te oud volgens mij, maar het is gewoon onzin. Ik krijg ook steeds vaker het idee dat mensen maar aan het zoeken of ze van onschuldige zaken iets racistisch of discriminerend kunnen maken.

Als je de lijn doortrekt kunnen we ook stoplichten en controle indicatoren gaan verbieden, want het is natuurlijk niet correct om een positieve of negatieve actie en gedachte aan een kleur te verbinden.

[synoniem]

Stoplicht heeft een negatieve connotatie en heet daarom ook verkeerslicht.

[jorisvergeerTBA]

Hoezo zouden termen zoals "blacklist" en "whitelist" onschuldig zijn. Je weet heel goed waar die namen vandaan komen. Waarom is "WHITE" de kleur van iets dat mag, en "BLACK" de kleur van iets dat niet mag.

Juist, dat komt omdat die termen zijn bedacht in een tijd dat apartheid een algemeen geaccepteerd gedachtegoed was.

En ja, daar zijn we nu met zijn allen op gewezen. Dus laten we ons best doen om die termen uit te faseren. Voor ons een kleine moeite, en voor iemand die wel tegen die termen aan loopt een wereld van verschil.

Mijn eerste reactie was ook "wat een onzin" maar daarna ging je je toch wel afvragen waarom sommige termen zo zijn. En ja er zijn vaak ook betere termen. Die vaak ook veel duidelijker aangeven wat er met iets bedoeld word.

[Hemingr]

Je bedoelt de root "white magic" en "black magic", de echte root van deze termen (goed en slecht).

white/black heeft geen ene kut te maken met ras, no matter hoe woke je denkt te zijn.

[jorisvergeerTBA]

Helaas zijn er wel veel termen die wel een steriotyperende of rasistische achtergrond hebben.

Ik moet zeggen dat de nieuwe namen wel een stuk explicieter aangeven wat er mee bedoeld word.

@amst3l Heeft u voorbeelden die onterecht zijn?

[Reactie gewijzigd door jorisvergeerTBA op 23 juli 2024 09:31]

[Tworkk]

Maar goed, dat ontkent ook niemand. Alleen hoeveel mensen storen zich aan de termen slave/master in een computer programma? En hoeveel programmeurs gebruiken dat met het idee 'ja lekker die slaven beledigen met deze code'.

Maar zelfs als je dat los laat, die lijst laat al zien dat hier een oplossing voor moet komen. Er is namelijk één algemene definitie die nu geaccepteerd is (zeg even master/slave) en daar worden 4 alternatieven voor gegeven, en daar gaat het mis. Het is zo vrijblijvend dat we over 10 jaar met code zitten waar alle alternatieven worden gebruikt, waardoor je heel veel issues gaat krijgen. Zeg dan gewoon 'dit moet het zijn'. Het probleem zit hem ook in de dubbelzinnigheid die er in zit. Totdat er één standaard wordt aangenomen zit je met iedereen die zijn eigen termen verzint, want ja het zijn maar suggesties.

Overigens, misschien ben ik te onwetend, maar redline? Ik zie niet helemaal voor welke groep mensen dit beledigend moet zijn.

[amst3l]

Maar zelfs als je dat los laat, die lijst laat al zien dat hier een oplossing voor moet komen. Er is namelijk één algemene definitie die nu geaccepteerd is (zeg even master/slave) en daar worden 4 alternatieven voor gegeven, en daar gaat het mis. Het is zo vrijblijvend dat we over 10 jaar met code zitten waar alle alternatieven worden gebruikt, waardoor je heel veel issues gaat krijgen. Zeg dan gewoon 'dit moet het zijn'. Het probleem zit hem ook in de dubbelzinnigheid die er in zit. Totdat er één standaard wordt aangenomen zit je met iedereen die zijn eigen termen verzint, want ja het zijn maar suggesties.

Dat komt er inderdaad ook nog is bij kijken. Doordat er nu afgeweken wordt (onder maatschappelijke druk) van een standaard. Ontbreekt het juist aan één standaard. Door met 4 alternatieven te komen los je misschien het ene probleem op, maar creëer je weer nieuwe. Goed punt, hier had ik zelf nog niet aan gedacht!

[boschhd]

Als je de lijst zo bekijkt gaat t niet alleen om racisme, maar om termen waaraan mensen zich kunnen storen. Lijkt me niet zo gek, toch.
Ben zelf niet zo'n fan van gekke henkie, en ik denk dat Joost een zekere uitdrukking ook vaak genoeg heeft gehoord.
Ook al bedoel je er niets mee, het is goed te weten dat de lezer er anders tegenover staan,

[rcroonenberghs]

how woke can you go?

[boschhd]

Nou, heel.

[calvinturbo]

Typisch Amerikaans probleem waarbij personen en organisaties steeds woker proberen te zijn, beter dan de ander, nog minder 'aanstootgevend'. Dat iemand die over deze developertermen klaagt misschien een dikkere huid moet groeien wordt genegeerd.

[boschhd]

Dat, of je houdt wel rekening met elkaar.

[amst3l]

Het is ook zeker goed om de discussie aan te gaan met je gebruikers of in dit geval developers. Maar persoonlijk vind ik het een beetje overtrokken. In de zin van, dat ik me moeilijk kan voorstellen dat iemand bewust termen in zijn/haar code gebruikt die aanzetten tot racisme of expres zo bedoeld zijn.

Dat iemand aanstoot neemt aan de 'algemenere' programmeer termen zoals master en slave kan ik me dan beter voorstellen.

[boschhd]

Het zal vooral ook gaan om het onbewuste gebruik, dat woorden buiten de door de schrijver bedoelde betekenis, door de lezer ook met een andere betekenis geïnterpreteerd worden.

[Hemingr]

Lekker woke zijn zolang het de bottom line niet raakt.

[MiesvanderLippe]

Ik zou het fijn vinden als ze het in een eigen organisatie stoppen met een toezegging op donaties de komende paar jaar.

Je zou kunnen zeggen maar het is open-source dus dan kunnen we zelf verder als het mis gaat maar het is natuurlijk onwijs moeilijk om snel een nieuwe richting en leiderschap te geven aan zo'n complex project.

[Ed Vertijsment]

Tip: let even op je interpunctie, dat maakt je reactie beter leesbaar.

[Simon Weel]

Interesante ontwikkeling. Ben benieuwd of Google gaat slagen waar anderen faalden? Een nieuw OS 'in de markt zetten' is niet zo moeilijk - zorgen dat daar voldoende applicaties voor beschikbaar komen die het gebruik van dat OS stimuleren is een heel ander verhaal. Dat is waar al die OS-bouwers van de afgelopen decennia op stuk zijn gelopen. OS/2 kan als schoolvoorbeeld gelden. Twee grote bedrijven, heel veel geld en toch mislukt, want nauwelijks applicaties.
Wellicht zal Fuchsia met iets als emulators of virtuele machines komen om grote hoeveelheden bestaande applicaties te draaien, maar dat is dan weer geen stimulans om programma's te herschrijven voor een nieuw platform. We zullen zien....

[Swindowmasher]

Is dit het project die android en chrome OS zal fuseren?

[Qlusivenl]

Hoop dat er forks van komen, want een OS van google komt mn huis niet in.

[pepsiblik]

Ik zou het eerst even aankijken. Misschien word je wel positief verrast. En zo'n iPhone is ook niet alles

[Qlusivenl]

Fuchsia heeft toch niets met een iPhone te maken.. fuschia is voor laptops en wellicht tablets.

[SuperDre]

Volgensmij is het de bedoeling dat het een OS is voor alle platformen.

[robertpNL]

Totdat het gebruik moet maken van Google (Play) Services die gesloten zijn. Dus net als Android met als verlengstuk Google diensten. Zo zie ik dit met Fuchsia ook gebeuren.

[Reactie gewijzigd door robertpNL op 23 juli 2024 09:31]

[tweakorinho]

Ik vertrouw Google voor geen meter, dus een OS door hun al helemaal niet. Ze hebben geen liefde voor de gebruiker. Geen zin om dit uit te leggen.

[Omega]

Als bedrijf en hun diensten, nee vertrouw ik voor geen meter. Maar een forkje van hun OS voor eigen gebruikt zeg ik geen nee tegen. Over het algemeen zijn de open source projecten van Google goed spul.

[tweakorinho]

Fork smakelijk, maar dan heb ik liever dat het GPL licenced is.