Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties

Google heeft besloten om onderdelen voor de Linux-bestandssystemen ext2, ext3 en ext4 weer te integreren in de bètacode van zijn Chrome OS-besturingssysteem. De stap volgt na een golf van kritiek op het eerdere voornemen van de Chrome OS-ontwikkelaars de code te verwijderen.

Chrome OS is als besturingssysteem gebouwd bovenop de Linux-kernel. Google brengt samen met diverse elektronicafabrikanten steeds meer Chromebooks op de markt, waarbij Chrome OS ook overweg kan met externe harde schijven en andere opslagmedia die zijn ingedeeld met het ext2-, ext3- of ext4-bestandssysteem. Ontwikkelaars die namens Google aan Chrome OS werken, opperden echter het plan om ondersteuning voor deze Linux-bestandssystemen te schrappen. Zij zouden problemen hebben om scripts te schrijven die externe schijven met ext-indeling succesvol kunnen mounten in de Files-applicatie.

Hoewel de plannen om de ondersteuning voor de Linux-bestandssystemen uit te faseren al enige tijd op de Chromium-website waren te vinden, ontstond na een aantal publicaties op het web pas een week geleden een storm van kritiek over de voornemens. Sommige Linux-gebruikers noemden het onbegrijpelijk dat developers die hun eigen OS op Linux baseren, het meestgebruikte bestandssysteem op Linux willen schrappen en dreigden met een boycot van Chrome OS.

De Chrome OS-developers lijken geschrokken van de kritiek en hebben inmiddels aangekondigd de support voor ext2-, ext3- en ext4-bestandssystemen alsnog in het besturingssysteem op te nemen. In de eerstvolgende stabiele release moet daarmee de support weer zijn hersteld.

Moderatie-faq Wijzig weergave

Reacties (36)

Hier ging het dus alleen op support weg halen in de frontend. Hier liep ik enkel weken op m'n chromebook al tegen aan aangezien ik de beta draai. Zeer irritant, maar ik vond het niet super erg dat ik het via command line moest mounten. Daadwerkelijk support zou er sowieso niet zo maar uit gaan aangezien over het algemeen root filesystem toch echt ext4 is. Maar goed, mooi hoef ik niet meer via command line te mounten. Heeft dat gezeur dus toch nut gehad.
Klinkt mij erg als luiheid/geen moeite willen doen; "(goede) ondersteuning voor EXT inbouwen is lastig, dus we doen het niet".
Nee, de ondersteuning is uiteraard wel goed, gezien ChromeOS op Linux draait. Het ext bestandssysteem mist echter de functionaliteit om partities een naam te geven omdat dat op Linux anders werkt. Doordat de ontwikkelaars daardoor geen feature-parity konden garanderen besloten ze ondersteuning volledig te verwijderen.

[Reactie gewijzigd door ClementL op 16 oktober 2014 16:17]

Maar moeten ze het er dan maar volledig uitslopen?

Laat dan de optie weg uit de GUI maar blijf gewoon ext4 ondersteunen voor 'advanced users'
Ik zou het alsnog begrijpen als ze het eruit slopen, aangezien Chrome OS eigenlijk voor de makkelijke gebruikers is. Wie geeft er een scheet om hoe Windows met ext* omgaat? Precies. Wel leuk voor developers, maar het zorgde nu voor problemen en 99% van de gebruikers gaat het echt niet missen hoor.

Maar verstandig dat ze zich wat aantrekken van de community, dus goed gedaan wat dat betreft. Microsoft deed dat verkeerd toen ze zeiden; niemand gebruikt het startmenu > menu > menu amper, dus laten we alleen de favorieten overhouden in een nieuw scherm. Mensen klaagden maar toch bleven ze aanhouden en zie het resultaat.
Jep ms beweerde zelfs dat ze dat met anonieme statistieken konden onderbouwen... Hoor je ze nu niet meer over.
Dat beweer ik niet. Ik leg enkel uit wat de redenering achter de eerdere beslissing om ext functionaliteit weg te halen was.
Wat is het verschil tussen e2label en "een naam geven" dan?
In deze post wordt aangegeven wat de praktische problemen bij het implementeren van die functie zijn.
Volgens mij vroeg ie wat het verschil is, daar ben ik ook wel benieuwd naar namelijk. Niet wat ChromeOS z'n probleem is met de implementatie daarvan, heb ik op linux al 20 jaar geen last van namelijk :).

Heb derhalve ook ergens het vermoeden dat het meer ligt aan hoe ChromeOS bepaalde dingen implementeert dan dat het aan ext ligt.

R2D2 mnt # mount /dev/sdb1 /mnt/data
R2D2 mnt # e2label /dev/sdb1

R2D2 mnt # e2label /dev/sdb1 "Whooptie Friggin' Doo"
Warning: label too long, truncating.
R2D2 mnt # e2label /dev/sdb1
Whooptie Friggin
R2D2 mnt # e2label /dev/sdb1 "Nog een keer!"
R2D2 mnt # e2label /dev/sdb1
Nog een keer!

[Reactie gewijzigd door freaky op 16 oktober 2014 21:16]

Beter slechte feature-parity dan geen feature, maar dat is mijn mening.
Als de filosofie van je bedrijf is om alles in de cloud op te slaan dan is onderseuning van lokale externe hardeschijven eigenlijk een vreemde luxe om te bieden in je OS.
Kijk, daar komt de aap uit de mouw denk ik dan. Als ze al hierom geen sd ondersteuning in de nexus telefoons inbouwen lijkt me het niet onwaarschijnlijk dat dit precies dezelfde reden heeft. Krijg eensteeds grotere hekel aan Google, 5 jaar geleden was het nog de good guy, maar inmiddels heeft het al zijn onschuld wel verloren.
Lijkt me sterk dat dit de reden is, want de meeste harde schijven hebben NTFS of FAT als partionering. Dat wordt wél ondersteund door Chrome OS.
Misschien eerder om er voor te zorgen dat het installeren van andere Linux distributies lastiger word?
Ik vind het ook een raar verhaal; je baseert je OS op Linux en ondersteunt vervolgens enkel bestandssystemen van Microsoft, terwijl de support voor het het meest gebruikte Linux-filesystem niet meer wordt ingebouwd. Ze maken bij Google wel een hele vreemde spagaat op deze manier.
Gebruikt Chrome OS dan zijn eigen bestandssysteem of een Windows variant?

Het is natuurlijk wel erg handig om USB-sticks en externe hardeschijven van OS X en Linux te kunnen gebruiken.

[Reactie gewijzigd door TheNephilim op 16 oktober 2014 16:13]

Ze ondersteunen FAT, NTFS en dus nu weer EXT2,3,4

De reden dat ze EXT wilden droppen was omdat daarop volume namen niet makkelijk te renamen zijn vanuit de gui. FAT en NTFS kan dat wel gemakkelijk bij.

* aanvulling: ik weet het verder ook niet, ik las het in dit artikel: http://www.phoronix.com/s...page=news_item&px=MTgxMTg

[Reactie gewijzigd door jwal op 17 oktober 2014 09:26]

Dat lijkt me niet een reden, als je het zonder "GUI" kan hernoemen kan je het ook wel in het settings schermpje bakken op de plek waar het voor NTFS en FAT hernoemd kan worden.

Dat hoeft er voor de gebruiker ook helemaal niet anders uit te zien. Intern bekijk je wat je bestandssysteem is en op basis daarvan voer je de juiste code uit om de hernoeming door te voeren.

edit: Hieronder lees ik dat EXT niet iets ondersteund als een naam voor een volume. Dan is er ook weinig te veranderen qua naam.

[Reactie gewijzigd door ZpAz op 16 oktober 2014 16:22]

Uhmm je kunt toch een label zetten met e2label ?

Waarna de partitie beschikbaar is via "/dev/disk/by-label/LABEL" ...

[Reactie gewijzigd door gekkie op 16 oktober 2014 16:32]

Linux heeft wel labels, dus waarom ze dat niet hebben gebruikt?
Lijkt me inderdaad ook niet de reden.

Ik denk dat het gewoon uit een zakelijk perspectief is gedaan.

Chrome-OS kun je alleen monopoliseren indien men gedwongen/gebonden is aan je online opslagdiensten.

Zodra je mensen toestaat om hun data op te slaan waar ze maar willen heb je geen mogelijkheid om hen te monopoliseren, want ze kunnen heel gemakkelijk overstappen.

Niets bij Google is gratis, er zit altijd een andere verdien model achter.
Klinkt logisch, ware het niet dat de meeste externe media ntfs en fat gebruiken, precies de systemen die tot voor kort juist als enige ondersteund werden.
Maar dat kunnen ze op den duur er ook uit slopen, en ik meen dat ntfs en fat royalties aan Micro$oft betaald moeten worden.

Ik ken zelf Chrome-OS niet (nooit gebruikt) maar vraag me wel af of je NFS en SMB kunt mounten, want dan maakt de externe FS niets uit.

[Reactie gewijzigd door totaalgeenhard op 17 oktober 2014 20:38]

Het probleem zit in het automatisch mounten. Voor interne disks is er dus geen probleem, alleen voor portable media is het wat lastiger. Als je dan in de veronderstelling bent dat mensen toch geen EXT4-USB-sticks hebben, kan ik me voorstellen dat je overweegt de ondersteuning daarvoor gewoon te skippen ipv een patch te maken.
Mijn Chromebook geeft aan ext2 als bootdisk en ext4 voor de rest, /dev/dm-0 is ext2 en /home/* is ext4
Om even de advocaat van de duivel te spelen... ik had het haast van harte aanbevolen om >NIET< EXT-filesystems te ondersteunen als de automounters lastig te scripten zijn, zolang de optie maar bestaat voor mensen om het toe te voegen, maar dat geld voor elk OS (Windows/MacOS en GNU-LINUX kunnen onderling een hoop filesystems lezen, waar Windows zelfs HFS+ kan lezen).

Linux is in alle opzichten een kernel. Geen operating system. Dat er een hoop GNU-geinspireerde X.org-viewerende operatingsystems zoals Ubuntu, Debian, het gebruiken, en mogelijk incidenteel "de eerste" generatie linux-gebaseerde operating systems zijn wil nog niet zeggen dat ze alleen zijn. Hun eigen (!) bewuste keuze om EXT te gebruiken ipv ReiserFS of, omdat het niet met GPL valt te verenigen, ZFS, dat is hun zaak. Niet die van de Linux Kernel. ChromeOS gebruikt meer GNU tools dan dat andere Google-OS; Android (ook Linux van binnen, en nee: EXT-ondersteuning zat er lang niet altijd in, RFS is soms voorgekomen als "enig" fileystem in sommige handsets). Big woop. Puur omdat de GNU-community Chrome OS als "de" manier ziet om desktop linux een ding te maken, wil nog niet zeggen dat ze keihard vast moeten houden aan de standaard GNU tooling. Zelfs Canonical (toch grote Linux fanaten) is wat meer controversieel bezig geweest in het loslaten van "legacy GNU/Linux architectuur" met hun MIR, en Weyland begint ook te vormen. Er is altijd een storm van kritiek. IT-ers, en dan zeker de GNU/Linux-ers, zijn altijd best weerstandig tegen verandering....
Precies, Linux biedt ontwikkelaars de mogelijkheid om diverse bestandssystemen te gebruiken, iedereen is vrij om zijn eigen voorkeur te bepalen. Juist die vrijheid maakt Linux zo succesvol.
Wel goed dat ze op de achterpoten zijn gaan staan . en zo zie je maar weer... mooi dat google soms wel degelijk hoort wat je zegt :)
Een Linux-based OS zonder EXT-support? Dan zou je net zo goed de FAT- en NTFS-ondersteuning uit je Windows media center kunnen schrappen. Goed dat de developers weer bij zinnen zijn gekomen.
klein (groot) foutje : fat16 is uitgefaseerde legacy die niet meer gebruikt wordt, ext4 is net 't tegenovergestelde hiervan ...
alleen verander je een filesysteem dat nog veel gebruikt word (binnen linux) door een bestandsysteem wat al 10-tallen jaren achterhaald is, waardoor je comment dus nergens op slaat

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True