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 , , 53 reacties
Submitter: Lauwes

De Gnome-community heeft de officiŽle release van Gnome 3.22 aangekondigd met een groot aantal wijzigingen en nieuwe functies, waaronder integratie van Flatpak, betere Wayland-ondersteuning en de mogelijkheid in een batch de naam van meerdere bestanden vanuit Nautilus te wijzigen.

De ontwikkelaars van de Gnome-desktop hebben vooral veel opvallende wijzigingen doorgevoerd bij de bestandsmanager Nautilus. Zo is het nu mogelijk om meerdere bestanden in een keer te hernoemen zonder terug te moeten grijpen op de command line of een andere applicatie. Het is ook mogelijk om metadata via de batch-methode te wijzigen, zoals de naam van een muziekalbum of de datum waarop een bestand aangemaakt werd. Ook kunnen hernoem-templates aangemaakt worden en wordt bij het aanmaken van een nieuwe map met alle geselecteerde bestanden een passende naam voorgesteld.

Daarnaast is de integratie van bestandscompressie onder handen genomen. Een dubbelklik op een zip-bestand pakt dit bestand direct uit in de map waarin deze staat. Daarnaast is het in Nautilus 3.22 mogelijk om vanuit de bestandsverkenner zelf verschillende compressie-opties te selecteren. Gebruikers die toch liever File Roller blijven gebruiken, kunnen dat instellen.

De ontwikkelaars hebben ook het ontwerp van de dconf-editor aangepakt, de applicatie waarmee bepaalde instellingen gewijzigd kunnen worden. De interface is versimpeld en verschillende wijzigingen kunnen in een keer doorgevoerd worden. Bovendien is er een reset-optie toegevoegd.

Kleinere wijzigingen bestaan uit het makkelijker kunnen delen van foto's vanuit de Photo-app, verbeteringen aan Software, betere ondersteuning voor Wayland, zoals multitouch-features, aanpassingen aan de toetsenbordinstellingen-app, een verbeterde Mapps-app en de mogelijkheid om video's op verschillende snelheden af te spelen.

Het team achter Gnome heeft zich ook toegelegd op ondersteuning voor Flatpaks, een manier om Linux-applicaties op een simpelere wijze te verspreiden door alle afhankelijkheden in te bouwen, vergelijkbaar met Snaps van Canonical. Zo is er vanuit de Software-applicatie nu de mogelijkheid om Flatpak-repositories te installeren.

De release van de volgende stabiele Gnome-versie staat weer voor over zes maanden gepland.

Gnome 3.22 applicatiesGnome 3.22 applicatiesGnome 3.22 applicatiesGnome 3.22 applicatiesGnome 3.22 applicatiesGnome 3.22 applicaties

Moderatie-faq Wijzig weergave

Reacties (53)

Het team achter Gnome heeft zich ook toegelegd op ondersteuning voor Flatpaks, een manier om Linux-applicaties op een simpelere wijze te verspreiden door alle afhankelijkheden in te bouwen, vergelijkbaar met Snaps van Canonical. Zo is er vanuit de Software-applicatie nu de mogelijkheid om Flatpak-repositories te installeren.
Het grote voordeel van Linux moest toch juist zijn dat een security probleem in een onderliggende library kon worden gefixed zonder dat de afnemer van een package z'n app moest updaten. Hoezo plots nu vanuit meerdere kanten dat we naar het Windows/Mac OS X model gaan in de Open Source community?
Dit maakt het mogelijk dat ontwikkelaars een nieuwe versie van hun software uitbrengen voor meerdere distributies in een keer. Vaak worden zulk soort nieuwe versies niet beschikbaar gesteld voor de stabiele versies van distributies.

Het helpt ook met het onderzoeken van een bug. Je kan met een Flatpak veel makkelijker de gebruiker de laatste ontwikkelversie aanbieden.

Er zijn ook nadelen: security. Maar tjah, niet elke distributie is goed in security. Linux Mint staat redelijk bekend om het niet leveren van security updates bijvoorbeeld. Verder vangt Flatpak het gedeeltelijk af door gebruik te maken van Runtimes. Een applicatie hoort afhankelijk te zijn van een runtime. Deze runtime en de updates wordt bijgehouden door een team.
Mee eens, ik ben tot nu toe op Gentoo nog nooit tegen een issue met libs aangelopen, ook omdat je daarin relatief gemakkelijk meerdere versies van een lib kunt hebben, dus snap niet helemaal welk daadwerkelijk probleem men hiermee probeert op te lossen.

IMHO heeft dit alles idd vooral potentie voor grote security issue omdat nu voor elke applicatie individueel de applicatie + dependencies bijgewerkt moet worden en de gebruiker de applicaties als geheel weer allemaal moet updaten.
Nadeel van shared libraries is dat je geklooi met versies krijgt. Debian patcht bijvoorbeeld heel veel libraries zelf nog weer, waardoor een versie die je op debian hebt niet hetzelfde hoeft te zijn als een versie die je op fedora hebt. Als je alle dependencies in 1 pakketje hebt, is dat een stuk makkelijker te installeren over verschillende platformen.
Dat is wel zo, maar dat komt dus de veiligheid niet ten goede. Een shared library is voor elk programma tegelijk gepatcht. Nu krijg je dus eerder zwakheden in programma's wanneer de software niet geŁpdatet wordt.
Ja, dat zegt David Mulder hierboven ook al. Het komt er uiteindelijk op neer wat je belangrijker vind. Makkelijk installeren van applicaties en dan maar hopen dat die vendors hun pakketten up to date houden, of betere veiligheid.
Dat is juist de kracht en zwakte van een GNU/Linux distributie. DLL's meeleveren zoals bij Windows brengt alleen maar mee dat bepaalde software met hopeloos verouderde libraries blijft zitten.

Nadeel is natuurlijk dat wanneer je een update doet bepaalde software niet meer werkt omdat het bepaalde functionaliteit uit een lib nodig had die nu niet meer in de nieuwe versie zit. Meestal wordt die software ook wel mee aangepast, maar er zijn natuurlijk altijd edge cases die brute pech hebben.
Zover ik de requirements voor flatpacks heb gelezen (toen nog xdg-app) is het zo dat een developer alleen dingen in de flatpak mag stoppen als hij/zij er ZEKER van is dat deze op het host OS niet voldaan kunnen worden, om wat voor reden dan ook. Of dat nog zo is kan ik helaas zo snel niet vinden.
Het team achter Gnome heeft zich ook toegelegd op ondersteuning voor Flatpaks, een manier om Linux-applicaties op een simpelere wijze te verspreiden door alle afhankelijkheden in te bouwen,
Nog een partij die het wiel opnieuw uitvind.

Wat hebben we ondertussen, wat er oplijkt.
- docker
- vagrant
- snaps
- Nu dus ook Flatpaks.
- onder systemd verschillende containers.

Beetje een wild groei als je het mij vraagt.
Docker is voor Applicaties zonder GUI
Vagrant is voor hele Virtual Machines
systemd ondersteund containers starten, stoppen, en heeft wat logica om er goed mee om te gaan, maar maakt zelf geen containers/abstractielaag.

Alleen Snaps is voor zover ik weet een beetje hetzelfde.

Maar goed, we klagen ook allemaal dat we WinZip, WinRAR, 7Zip, Archiver x-y-z hebben...

Soms is keuze niet slecht.
In grote lijnen klopt dat, maar in een X omgeving kan je prima GUI programma's met docker draaien.
Nog een partij die het wiel opnieuw uitvind.
Zoals @teek2 aangeeft zijn flatpaks en snaps van een andere orde. Flatpak geeft een manier om apps te distribueren die identiek is voor alle distributies. Hierdoor moet het voor ontwikkelaars interessanter worden om ook Linux te ondersteunen, want met 1,5% marktaandeel houdt het al niet over en dan heb je ook nog 3 of 4 verschillende manieren van inpakken. Snaps beoogt ongeveer hetzelfde maar dan alleen binnen de wereld van Ubuntu.

Onder de motorkap gebruikt flatpak Linux Containers om te sandboxen. Daar is ook docker op gebaseerd, en dat zit nog maar enkele jaren (bruikbaar) in de linux kernel.

Voor de volledigheid, dit is wat flatpak zelf zegt over het wiel uitvinden:

Flatpak tries to avoid reinventing the wheel. We build on existing technologies where it makes sense. Many of the important ingredients for Flatpak are inherited from Linux containers and related initiatives:
  • The bubblewrap utility from Project Atomic, which lets unprivileged users set up and run containers, using kernel features such as Cgroups, Namespaces, Bind mounts and Seccomp rules
  • systemd to set up cgroups for our sandbox
  • D-Bus, a well-established way to provide high-level APIs to application
  • The OCI format from the Open Container Initiative, as a convenient transport format for single-file bundles
  • The OSTree system for versioning and distributing filesystem trees
  • Appstream metadata that makes Flatpak apps show up nicely in software-center applications
Zelf vind ik het een mooie ontwikkeling die met een beetje geluk leidt tot meer applicaties die ook voor linux worden uitgebracht.

edit: opmaak van quote

[Reactie gewijzigd door VictorK op 22 september 2016 14:05]

Even een kleine correctie:
Snaps beoogt ongeveer hetzelfde maar dan alleen binnen de wereld van Ubuntu.

Dat klopt niet, snapd draait inmiddels op Fedora, Debian, Arch en OpenWRT en er komen er denk ik nog wel meer.
(https://insights.ubuntu.c...n-multiple-linux-distros/)

[Reactie gewijzigd door teek2 op 22 september 2016 17:00]

Docker en Vagrant hebben hele andere usecases dan flatpack en snaps. Maar keuze is toch juist fijn? De verschillen zijn best groot dus laat ze lekker ontwikkelen, van elkaar leren en ons de keuze geven wat we uiteindelijk het fijnste vinden.
Ja als er duizenden ontwikkelaars op zaten dan had je gelijk gehad, waarschijnljik zijn het teams van 5 of zo waarbij het beter is om samen te werken dan alles dubbel down en 50% minder productief zijn.
Een team verdubbelen n zal toch nooit de efficiŽntie verdubbelen hoor. En daarbij het gaat niet alleen om code kloppen maar een andere visie uitwerken. Waarbij de user/community uiteindelijk zal beslissen welke variant de beste is.
Te vaak zijn er meerdere oplossingen voor hetzelfde probleem binnen Linux. Ik ervaar werkelijk bij alles keuze stress. Laat ze de kwaliteiten van de verschillende opties samenvoegen en een uniforme standaard ontwikkelen waar iedereen blij mee is.

Voor een normale gebruiker, die de command prompt vermijd is dit stront vervelend.
Welke 'ze'? De "Linux bazen?" Het feit dat er meerdere opties zijn komt voort uit mensen die een ander idee hebben en dat zelfstandig uitvoeren. Je voorstel zou in de politiek overeenkomen met 'laten we alle politieke partijen samenvoegen en de kwaliteiten van elke partij gebruiken om een standaard partij te maken voor iedereen'...
Of een coalitie vormen net zoals W3C of Apache en de PVDA/VVD.

Meerdere partijen die werken aan ťťn gemeenschappelijk doel.
Niet perse. Apache alleen al heeft meerdere webservers, applicatieservers, database servers enz.

Het idee is leuk, maar er is geen noodzaak voor mensen om zich aan andere groepen te verbinden. Er is geen materiaal nodig, er is geen geld nodig, alleen maar iemand met een computer en een idee. En zolang iemand een eigen idee mag hebben ga je meerdere versies van een oplossing voor hetzelfde probleem zien, en daar is niet perse wat mis mee.
Dan moet je misschien geen Linux gebruiken. Of je kan je natuurlijk ook gewoon neerleggen bij de keuzes die Canonical voor je maakt? Distributies zijn er juist om uit het aanbod een mooi geheel te kiezen. Daarbij is een uniforme standaard waar iedereen blij mee is een utopie.

Je zoek zelf problemen en stress, om niks.
Ten eerste zullen het dus de distro bouwers zijn die kiezen welke opties ze meeleveren. Impact gebruiker? Nihil. Ten tweede gaat het om een manier van installeren die werkt met een simpele dubbelklik. Dus als jij een distro installeert die beiden ondersteunt da ga je daar als gebruiker echt weinig van merken. Of je nu een flatpack of snap installeert.
Ik denk dat Gnome meer richting de .app van Apple's OS X/MacOS gaat. Dus dat je applicatie in een bundeltje zit, waarin alles zit.
Een .app is dan eerder te vergelijken met .msi voor Windows en (bijvoorbeeld) .deb voor Debian / Ubuntu.
Nee, een .app is een Application Program Package. Een mapje waarin alle resources + de binary van een applicatie zitten. Dat is een vervanger van resource forks (of in NTFS lingo: "streams"), en het los verspreiden van resources en de binaries in een random mapje. Het is dan ook geen bestand, maar een map met een speciale naam en een paar minimale eisen aan de inhoud.

[Reactie gewijzigd door johnkeates op 22 september 2016 14:50]

Nee totaal niet. Een .app is iets wat direct kan gebruiken. msi/deb/etc zijn installables.
Das toch .sh?? In Linux
.sh zijn bash scripts, net als .bat of .cmd in Windows.
Nee, want daar zitten er nog steeds genoeg gedistribueerde frameworks en dylibs los in het systeem. Het idee van de platgeslagen pakketjes komt eigenlijk meer in de buurt van fat binaries waarbij alles statisch gelinkt is, wat naar mijn idee nogal idioot is op non-embedded platforms. Een crunchprog maken in een resource-restricted omgeving kan ik me voorstellen, maar alles maar lekker op een hoop gooien om dat er toch wel genoeg ruimte is gaat mij dan weer net te ver, vooral als het alleen maar luiheid van matige developers in de hand speelt.

[Reactie gewijzigd door johnkeates op 22 september 2016 14:52]

Alleen is vagrant niet echt vergelijkbaar aangezien het gaat om een "echte" virtualbox VM. Containers gebruiken in principe geen VM. Tenzij bijvoorbeeld docker op non-linux vanwege het (los) virtualiseren van de kernel.
Dit is vanuit technisch perspectief slechts deels correct. Dat de vergelijking op een aantal vlakken niet opgaat is door anderen al aangestipt.

Aan de andere kant bestaat AppImage al behoorlijk lang en doen Snaps (van Ubuntu) en xdg-app/flatpack voor de eindgebruiker nagenoeg hetzelfde. Dat is helaas hoe t vaak werkt tussen de grote/corporate Linux reuzen als RedHat en Ubuntu.
Flatpak is anders dan bijvoorbeeld Docker, omdat het framework zich specifiek toelegt op Linux-applicaties, terwijl Docker ook op Windows en Mac werkt. Los van dit alles werkt Docker iets anders; Docker-images bieden meer dan een simpel programma. Ze omvatten vaak een compleet OS met bijbehorende software.
Mee eens. Tijd om een nieuwe standaard te maken, met de voordelen van alle bovenstaande!
https://xkcd.com/927/.

Maar wat serieuzer: tot voor kort was dit wel echt een probleem in de Linux-wereld. Alle oplossingen die je noemt, zijn iets van de afgelopen paar jaar. Redelijke kans dat de Gnome ontwikkelaars al bezig waren voordat er een van deze populair werd.

De komende tijd zal er vast een als populairste uitpakken. Goede gok is dat het Docker wordt, omdat deze op het moment het makkelijkst verkrijgbaar is op meerdere distributies.
Eerlijk gezegd vind ik het een vreemde reactie nadat anderen al duidelijk hebben uitgelegd dat er verschillen zitten tussen de genoemde producten. Eigenlijk hebben ze compleet andere doeleinden.

Je kan whatsapp ook niet vergelijken met gmail.
batch rename zat toch allang in nautilus? of was dat build 2.xx
Bij gnome3 hebben ze een hoop functionaliteit eruit gesloopt. De huidige files app kan bijvoorbeeld niet eens een terminal window openen binnen nautilus.
Deze functionaliteit is verplaats; het is niet weg. Je kan dit nog steeds doen alleen het package wat je moet installeren is anders. Afhankelijk van je distributie is dit beschikbaar. En afhankelijk van je distributie is dit standaard geÔnstalleerd of niet.
Bedoel je "Open in Terminal"? Ik weet niet hoe lang het er al in zit, maar ik heb het gevoel dat het niet weg is geweest.
Kan natuurlijk zijn dat jouw distro dat zelf weer ingepatcht heeft.
Na wat digging zie ik dat deze package mee wordt geinstalleerd. Ik heb het zelf nooit specifiek opgegeven dus het zal wel automatisch gebeuren.

https://www.archlinux.org...4/nautilus-open-terminal/

Op Ubuntu is het hetzelfde pakket, maar ik weet niet of het daar al dan niet optioneel/automatisch is.

[Reactie gewijzigd door !nFerNo op 22 september 2016 13:04]

Je kunt toch een pad openen door op rechtermuisknop te klikken en op 'Open in Terminal' te klikken? Lijkt mij defaultfunctionaliteit.
Dat is idd. heel irritant.. gelukkig is daar dan wel weer een menu-extensie voor te installeren. Maar ik wist niet dat batch-rename in 2.x heeft gezeten.
Het verbaast me dat ze uberhaupt nog functies toevoegen aan Nautilus. Met iedere release verdwijnen er functies. Er zit niet eens meer een treeview in, voor mij toch wel een van de belangrijkste dingen in een file browser.
Alhoewel ik Gnome 3 wel steeds beter vind worden (afgezien van die share-troep die ze overal in bouwen) heb ik het ondertussen helemaal gehad met Nautilus. Ik heb m vervangen door Nemo en denk niet dat ik ooit nog terug ga, want Nautilus is ondertussen voor mij nauwelijks functioneel meer.
nautilus 2 was super, zeker vanwege de vele scripts die je kunt installeren
'gScrpts' https://help.ubuntu.com/community/NautilusScriptsHowto
draai hier xubuntu, nieuwe gnome vind ik helemaal niets :+ lekker oldskool gtk2 ... maar het werk o zo lekker snel
Die scripts zijn nog steeds mogelijk. Verdere functionaliteit is bijvoorbeeld het gebruik van templates. Werkt allemaal nog prima.
Nemo is een fork van de oude Nautilus, maar wel met GTK3. Best of both worlds ;)
Volgens mij kun je er ook nautilus scripts in draaien, maar dat is nou weer een functie die ik zelf nooit gebruikt heb, dus kan het niet met zekerheid zeggen.
Er uit gehaald toen ze met 3.0 bezig gingen, zo ver ik weet.
"Nog een partij die het wiel opnieuw uitvind.

Wat hebben we ondertussen, wat er oplijkt.
- docker
- vagrant
- snaps
- Nu dus ook Flatpaks.
- onder systemd verschillende containers."


Gewoon statisch linken, dan is dat allemaal niet nodig.
Is al zo oud als de weg naar Rome.

edit: maar ja, dat is niet "hip"...

[Reactie gewijzigd door Grimm op 22 september 2016 12:16]

Flatpak gebruikt runtimes. Deze runtimes leveren de libraries welke onafhankelijk van de applicatie worden bijgehouden.

Ik help ook mee met een distributie. Een security fix in Firefox of een belangrijke library wordt prima geupdate. Maar security fixes in kleine applicaties? Vaak komt er geen update. Met een flatpak hebben de gebruikers wel de update.
Aangezien je er wat meer van weet: Wat is dan precies het verschil tussen deze runtime en een system library? Een system library wordt toch ook door de distributie bijgehouden en geŁpdatet wanneer nodig? Als een kleine applicatie een system library gebruikt en er komt een security fix voor heeft deze applicatie er toch ook profijt van?

Zoals je het uitlegt zie ik geen verschil.
Gewoon statisch linken, dan is dat allemaal niet nodig.
Is al zo oud als de weg naar Rome.
Net zoals dat security-lekken uit de tijd van Rome ook nog in je applicatie zitten omdat jouw applicatie lang niet zo goed wordt bijgehouden als het library-pakket dat de distributie zelf mee levert. Een bug in bv openssl is meestal al gefixed via een update op het moment dat ik er over lees. Dat gaat je met statisch linken niet gebeuren. Of met flatpacks/snaps for that matter...
Al deze oplossingen doen wel iets meer functioneel gezien dan puur statisch linken. Ten eerste is statisch linken zelden volledig statisch want afhankelijk van libc etc. Daarnaast voegen deze packaging system aan de runtime kant ook sandboxing toe.
GNOME 3 is na een wat moeilijke start dť innovatieve, mooie, ergonomische, intuÔtieve, makkelijke en mooiste Desktop.
Na vele installaties van vele smaken (Cinnamon, MATE, LXDE, Xfce, KDE), bij vele en diverse mensen (oud - jong, ervaren - onervaren, conservatief - nieuwsgierig) is mijn ervaring dat GNOME 3 het allerbeste is voor vrijwel iedereen. Niet voor niets werkt Linus ermee en niet voor niets heb ik bijna analfabeten en ouderen erg gelukkig zien worden van deze DE. Hoevaak ik wel niet heb gehoord: "Dit is zoveel makkelijker, waarom geven ze dit niet aan iedereen?". Die discussie ga ik uiteraard niet aan maar het is voor mij veelzeggend!

Dank GNOME Community _/-\o_


Om te kunnen reageren moet je ingelogd zijn



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