Canonical levert Ubuntu 23.10 niet met GIMP 3.0, maar met versie 2.10

Ubuntu 23.10, dat in oktober verschijnt, maakt geen gebruik van GIMP 3.0. Het besturingssysteem krijgt nog het oude GIMP 2.10, omdat er voor die upgrade naar versie 3.0 volgens de ontwikkelaars meer werk nodig is.

Canonical-ontwikkelaar Jeremy Bícha schrijft in een mail aan ontwikkelaars dat Ubuntu 23.10 blijft vasthouden aan de oudere versie van het GNU Image Manipulation Program, dat al sinds jaar en dag standaard met Ubuntu wordt meegeleverd. In 23.10 wordt GIMP 2.10.34 meegeleverd en niet GIMP 3.0. Die versie is nog niet definitief af, maar nadert wel de eindstreep.

Bícha noemt als verklaring dat de overgang naar GIMP 3.0 veel werk kost. "Toen ik deze discussie begon, had ik niet door dat GIMP 3.0 een enorme overgang betekent. Er is geen voorbereidend werk voor die overgang gedaan en daarom blijven we bij GIMP 2.10.34."

Door Tijs Hofmans

Nieuwscoördinator

24-08-2023 • 11:16

51

Reacties (51)

51
50
28
1
0
20
Wijzig sortering
GIMP 3.0 is nog niet uitgebracht dus het lijkt me logisch dat ze die niet last-minute in een aankomende release kunnen verwerken. Maar een update van GIMP nadat deze is uitgebracht is toch geen enkel probleem?
Dat is niet hoe het Ubuntu/Debian ecosysteem werkt. In een release van die distributies (zoals b.v. Debian Bookworm) zit een bepaalde set software. Die software krijgt vervolgens updates, maar dat zijn in principe alleen bugfixes, geen heel grote wijzigingen in ieder geval.

Die grote wijzigingen (zoals hier van Gimp 2.x naar 3.x) komen dan in de volgende release van de distributie (b.v. Debian Trixie).

Op die manier weet je dat je bij het up to date houden van je systeem niet bang hoeft te zijn voor software die ineens stuk gaat omdat b.v. configuratiefiles ineens anders werken. Pas bij de overstap naar een nieuwe release moet je heel goed gaan kijken/testen/voorbereiden.

Ondertussen is het natuurlijk wel mogelijk om gewoon Gimp 3.0 te gebruiken op een systeem dat daar standaard niet mee komt alleen wijk je dan dus af van de standaard distributie. Helemaal geen probleem, zeker niet bij een desktopsysteem.

[Reactie gewijzigd door bartvb op 25 juli 2024 12:01]

In theorie kunnen ze natuurlijk een gimp2 en een gimp3 pakket toevoegen. Dan krijg je alleen wel het risico dat je een nieuw Java-11-probleem waarin gimp3 stiekem gimp2 is totdat gimp 3 helemaal af is.

Op zich kunnen Ubuntu-gebruikers met Flatpak en Snap gewoon de nieuwste versie draaien natuurlijk, dat lost de versieproblemen op door gewoon een losse kopie van alle dependencies en resources ergens anders te kopiëren, maar heel elegant is die oplossing niet.
Op zich kunnen Ubuntu-gebruikers met Flatpak en Snap gewoon de nieuwste versie draaien natuurlijk,
Ik heb zelf DarkTable in een container (Snap denk ik) gedraaid, tot ik er achter kwam dat OpenCL niet werkt. OpenCL maakt namelijk gebruik van libraries die meegeleverd worden met de drivers, en die zijn niet beschikbaar binnen de container, voor zover ik weet. Mijn oplossing was toen toch gebruik maken van een PPA (Personal Package Archive). Ik weet niet of Gimp 3.0 OpenCL-accelaratie biedt (ik kan er weinig over vinden, dus waarschijnlijk niet), maar daar zou een container-formaat als Flatpack of Snap een beperking kunnen zijn.
Er is experimentele ondersteuning voor OpenCL in GIMP. Er zijn diverse operaties in de GEGL library die dan een OpenCL versie gebruiken.

Echter de meeste of misschien wel alle operaties die je via ninja test in GEGL kunt testen laten zien dat de "gewone" versies sneller zijn.
Echter de meeste of misschien wel alle operaties die je via ninja test in GEGL kunt testen laten zien dat de "gewone" versies sneller zijn.
Ligt dat niet een beetje aan je verhouding tussen CPU en GPU? Ik heb speciaal voor OpenCL in een erg oude pc een iets minder oude videokaart gezet.
Ligt dat niet een beetje aan je verhouding tussen CPU en GPU? Ik heb speciaal voor OpenCL in een erg oude pc een iets minder oude videokaart gezet.
Mijn NVIDIA GeForce GTX 1660 Ti lijkt me niet het probleem te zijn. Een mogelijke verklaring kan zijn dat GEGL flink is geoptimaliseerd, maar dat er voor zover ik weet vrij weinig aandacht is geweest voor de OpenCL code. Om daar echt meer duidelijkheid in te krijgen zal er iemand naar die code moeten kijken.
Voor zover ik weet kan OpenCL wel vanuit de sandbox, mits de nodige drivers meegeleverd zijn. Voor bijvoorbeeld Darktable is dit met Flatseal of een andere permissiemanager op te lossen (applicaties zonder permissie voor hardwareacceleratie hebben geen hardwareacceleratie :))

Hoe dat bij Snap zit weet ik niet, maar ik gok dat het dezelfde problemen en oplossingen zal hebben.
Voor zover ik weet kan OpenCL wel vanuit de sandbox, mits de nodige drivers meegeleverd zijn.
offtopic:
Bedankt voor de tip. Helaas lijkt het voor mij geen oplossing.
OpenCL is only failing for AMD GPUs, nVidia works fine once you install the flatpak version of the nVidia driver.
offtopic:
Jammer om te horen, hopelijk packaget iemand snel de AMD drivers met Darktable zodat het wel weer werkt
Het is geen Darktable-probleem maar een flatpak-probleem
Ja, een gimp3-pakket, desnoods in Backports o.i.d., zodat je weet dat je een klein risico neemt.
Je vergeet te vermelden de backports repo :) zoals @TheVivaldi ook aangeeft. Daarnaast heb je APT repos, AppImage, FlatPack, en je zou ook nog Nix kunnen draaien (de package manager van NixOS).
Is ubuntu als developer werkbaar? Het is nog steeds veruit de meest gesupporte en dus beste linux distro voor de doorsnee persoon.
Ik heb al een paar keer geprobeerd de switch te maken, maar sinds windows 10 ben ik toch wel weer erg blij met windows. Toch blijft linux CL een stuk efficienter.
Ik werk sowieso al jaren (10+ jaar) op linux als developer, en ik mis helemaal niks. Hangt natuurlijk wel van je werkomgeving af of dat je net zo'n ervaring gaat hebben als ik.

Sinds een jaar of twee naar Ubuntu gestapt vanwege een plotseling overlijden van mijn laptop, en ik moest op de vervanger gewoon snel kunnen werken. Ik dacht aan Ubuntu voor de korte termijn en dan later wisselen, maar het staat er nog steeds op.

Op zich ben ik helemaal content, maar vind dat sommige snap packages die nu soms default zijn (i.t.t. de repos) soms wat buggy zijn. En dan met name firefox, geen idee of ik de enige ben.
Stap 1 na installatie van Ubuntu is toch altijd het deinstalleren van de Snap versie van Firefox en vervolgens je browser naar keuze te installeren? :+
Dat kan overigens naast de standaard apt versie van Firefox ook heel goed de developer versie zijn van Firefox.
Snap is een tweesnijdend zwaard. De extra veiligheid die je krijgt door de sandboxing maakt het stukken lastiger voor de boefjes om via een browserbug malware op je PC uit te voeren. Maar tegelijkertijd maakt het ook onmogelijk om dingen te doen die de snap ontwikkelaars niet voorzien hebben. Als het makkelijker zou zijn om daar overrides voor te maken zou ik er enthousiaster over zijn. Ik probeer bij iedere release de snap uit, maar meestel duurt dat niet langer dan een dag of twee.
Op zich ben ik helemaal content, maar vind dat sommige snap packages die nu soms default zijn (i.t.t. de repos) soms wat buggy zijn. En dan met name firefox, geen idee of ik de enige ben.
Zelfde ervaring met snap, ze pushen het door maar de kwaliteitscontrole laat te wensen over.
Zo kon je destijds snap firefox niet gebruiken in samenwerking met de BeID plugins. Ook was signal
een tijdje kapot, als in segfault tijdens opstart op de in de snap meegeleverde libraries, en kon je ook niet downgraden na een bepaalde periode. Ze hadden dat ding dus zelfs niet gestart voordat ze het als productieklaar releasde op hun snap repos. En snap is traaaaag, het lijkt wel alsof alle applicaties plots in java zijn geschreven.
Dat het trager is, komt dat niet doordat de dependencies inbegrepen zijn in elke snap? Dat maakt applicaties wel groter.
Niet echt, want bij AppImages is dat ook zo en die zijn razendsnel.
Dat is waar, daar heb ik net voor het eerst van gehoord bij het installeren van een applicatie op Arch Linux zojuist, het viel me al op dat dit sneller werkt.
Snap en Flatpak lijken hetzelfde te doen, maar er zijn veel interne verschillen. Zo gebruiken snaps SquashFS en AppArmor, terwijl Flatpak OSTree en namespaces gebruiken.

Grootste nadeel van Flatpak is dat jan en alleman Flatpak's kan uploaden naar flathub.org. Dit is ook de reden dat ElementaryOS, dat zelf veel Flatpak's gebruikt, flathub.org standaard heeft uitgeschakeld. Zonder flathub.org is Flatpak echter een stuk minder interessant.

Overigens is er ook nog AppImage. Die zijn in mijn ervaring het snelst. Ze zijn echter het lastigst in gebruik omdat je ze handmatig ergens in een bin folder moet zetten. (Een Applications folder zoals op macOS kent Ubuntu helaas niet).
Ik gebruik al jaren Ubuntu als dev bak/werksysteem (PHP/Magento) en dat werkt heerlijk. Vooral omdat het ook op de server gebruikt wordt (zonder GUI) en daarnaast ook geen geklooi met docker performance. Voor .NET gebruik ik nog wel windows aangezien dat dus ook veel meer native windows is.
.NET (Core) draait prima onder Linux hoor, geen Windows voor nodig. Helemaal niet met Rider als IDE
Ik doe al mijn hobby programmeer in .net op linux.
Ik draai rider in combinatie met .net (core) en het draait geweldig.
Voor desktop projecten ben ik ook overgestapt op Avalonia UI, wat vrij af lijkt te zijn tegenwoordig. Alleen mis je dan WPF bibliotheken, wat soms wel een gemis is.
Daarnaast draaien mijn hobby projecten dan zowel op Linux als op Windows.

Voor werk kan het ook, maar geen support van IT voor Linux, dus dat gaat hem jammer genoeg niet worden.
Ja, als je Windows desktop development doet met .NET moet je wel Windows gebruiken. Maar andere typen projecten draaien gewoon op Linux.
Ik gebruik al jaren Linux op het werk bij verschillende klanten. Het laatste jaar is dat Ubuntu. Ik heb dit keer Ubuntu geïnstalleerd omdat ik een nieuwe laptop kreeg van het werk, een ThinkPad die Ubuntu certified is dus ik dacht laat ik maar eens zien wat dat betekend in de praktijk. Alles werkt dus gewoon ,inclusief aanmelden met vingerafdruk. Ik doe Java, Python, (PL/)SQL,... dus niets met .net of C# ofzo, in die laatste gevallen kan ik me inbeelden dat Windows makkelijker is. Ubuntu is een aanrader voor proffesioneel gebruik omdat bijna alle software die claimt Linux te ondersteunen instructies heeft voor Ubuntu en het is ook lekker makkelijk dat Teams, Slack, Spotify, ... gewoon werken.
Ik doe al mijn C# dev werk gewoon op Linux met Rider. Ook mijn hobby/game pc is nu over op EndeavourOs ipv het gedrocht Windows 11.

Sowieso als je kijkt naar de meeste dingen voor developers dan zijn mac en Linux het beste gesupport.

Ik heb nu een tijdelijke Win11 laptop.... Het is echt huilen. Ik wil Linux of Win10. Ik heb nog steeds niet de optie om gegroepeerde vensters niet te groeperen. Dat is maar een van de dingen die iritant is.
Ik werkte eerst zelf jaren met ubuntu als OS, en bij mijn huidige werk moet ik met windows werken. Beiden hebben zo wat voor en nadelen als OS, maar als developer erger ik me helemaal kapot aan windows:

- Explorer is brak, zelfs nu er eindelijk tabs zijn.
- Bestandspaden in windows zijn gestoord.
- Hoe je je path moet aanpassen is niet bepaald handig.
- Symlinks bestaan niet eens.
- De command line is stukken minder fijn.
- Window management vind ik bij ubuntu lekkerder werken (alt+~ is geweldig).

Ik heb het idee dat linux veel beter geschikt is om te developen en dingen te automatiseren. Ik kijk er dan ook al naar uit om weer terug te gaan. Als schrale troost heb ik nu mijn thuis (game) pc overgezet naar ubuntu :Y)
Inderdaad, al is mijn main OS macOS, maar op dezelfde Macbook draai ik Ubuntu 22.04 in een VM en (soms) ook Windows 11. Maar die laatste voor mijn werk, want ik vind het eigenlijk helemaal niks, al is W11 (of W10) al veel beter dan eerdere versies.

- Explorer is brak, zelfs nu er eindelijk tabs zijn.
Daar zij 3rd party file browsers voor, net als op de Mac andere file browsers zijn ipv Finder, al vind ik Finder al beter dan Explorer. Vooral de file structuur vind ik heel raar. Desktop helemaal boven aan in plaats van de home folder van de huidige gebruiker zoals bij Linix / macOS.

- Bestandspaden in windows zijn gestoord.
Inderdaad die rare backslashes en partitienamen met één letter.

- Hoe je je path moet aanpassen is niet bepaald handig.
Hoe bedoel je ?

- Symlinks bestaan niet eens.
Inderdaad.

- De command line is stukken minder fijn.
Zelfs Powershell is ruk. Maar ja MS moest ook hier opnieuw het wiel uitvinden in plaats van Bash / zsh te implementeren. Al eens geprobeerd Cygwin te installeren maar die is niet compleet, zelfs basis commando's als `ls` ontbreken.

- Window management vind ik bij ubuntu lekkerder werken (alt+~ is geweldig).
Deze ken ik niet, alleen op macOS (schakelen tussen vensters van eenzelfde app).

Elk geval, ik draai nu ook Ubuntu op mijn Android telefoon (Termux + Andronix) als subsystem onder Android (proot-ed). Werkt prima en je hebt geen root nodig.
Ja, sommige dingen vallen op te lossen met 3rd party software, maar dat is toch wel jammer als dat moet. En daarbij wil windows toch graag zijn eigen programma's als standaard aanhouden, dus kom je er toch weer mee in aanraking.
- Bestandspaden in windows zijn gestoord.
Inderdaad die rare backslashes en partitienamen met één letter.
Dat vind ik zelf nog niet eens het ergste, veel user folders staan op rare plekken die je niet makkelijk kan achterhalen. Ook worden sommige paden afgekort (dan komt er een tilde in dacht ik).
- Hoe je je path moet aanpassen is niet bepaald handig.
Hoe bedoel je ?
Bij het installeren van sommige programmas moet je dat programma zelf toevoegen aan %PATH% om het vindbaar te maken voor andere programmas.
- Window management vind ik bij ubuntu lekkerder werken (alt+~ is geweldig).
Deze ken ik niet, alleen op macOS (schakelen tussen vensters van eenzelfde app).
Jep, bij ubuntu is dit ook wisselen tussen vensters van zelfde programma.
Ik werkte eerst zelf jaren met ubuntu als OS, en bij mijn huidige werk moet ik met windows werken.
En is virtualisatie geen optie? Virtualbox met daarin Linux als je echt niet mag liggen klooien met de computer of in het ideale geval Windows in QEMU op Linux.
- Symlinks bestaan niet eens.
Symbolic links bestaan al best lang in Windows mbv. mklink.

Ik heb ze vroeger vaak gebruikt om spellen in mijn Steam directory te verwijzen naar mijn HDD ipv SSD als de ruimte op begon te raken(en ik dat voor dat spel niet belangrijk vond). Zit er al wel een jaar of 10 in denk ik, misschien langer misschien iets korter. Er kwam op een gegeven moment een gui tool(volgens mij Steammover?) die hetzelfde deed. Later kwam er functionaliteit in Steam zelf om een game te moven naar een andere library.
Oh dat is fijn om te weten. Ik heb mij wijs laten maken dat die er niet waren, bedankt!
Geen probleem, niemand kan alles weten. Mocht je het ooit willen gebruiken: https://learn.microsoft.c...n/windows-commands/mklink
Ook al paar keer switch gedaan. Maar als uw werkgever u een Windows PC voorziet, en daar ook support op doet. Dan heeft het weinig zin de switch te doen...
Thuis heb ik me een Chromebook gekocht :-) Dat is niet om mee te werken ;-)
Zeker WSL 2 is een goed alternatief - alhoewel je systeem wel dubbel belast wordt uiteraard, met zowel Windows en Ubuntu (of andere distro). Maar het kan absoluut!
Heeft WSL2 ondertussen al IPv6 support? Iets wat met WSL 1 wel werkte.
WSL2 is echt ontzettend langzaam als je iets met git probeert te doen (of iets anders dat door veel files heengaat?). Tenminste, dat is mijn ervaring. Op het internet vindt je dan ook dat WSL1 nog sneller is, maar ook dat is nog stukken langzamer dan op linux.
Ubuntu is juist het best voor developers qua support omdat vrijwel iedereen het gebruikt en je niet met missende libraries hoeft te vechten. Wel de LTS versies, en als de nieuwste LTS uit is dan duurt het vaak wel minimaal een half jaar voordat alle devs het een beetje beginnen te adopteren.

22.04 is onderhand goed gesupport en zeer aan te raden voor developen van software.

[Reactie gewijzigd door Osiummaster op 25 juli 2024 12:01]

Ik heb voor mijn werk soms ook Windows nodig, maar het gros van de software draait tegenwoordig op Linux. Ik werk met WSL2 en dat gaat eigenlijk prima. Primair draai je dan gewoon Windows, maar je kan heel wat Linux software draaien. Niet voor iedereen, maar in sommige situaties heel goed werkbaar.
Hoe werkbaar een linux versie is voor een developer. Is denk ik vooral afhankelijk wat je ontwikkelt en wat je gewent bent.

Ik zelf, doe ik ruim 25 jaar ontwikkelwerk op Linux en vind het persoonlijk een ramp. Als het het zelfde werk op Windows moet doen. Dit is puur omdat Linux mijn voorkeur is.
Ik ben benieuwd wat dit dan betekent voor de 24.04 LTS (long term support), aangezien ze voor een LTS normaal gesproken geen grote veranderingen willen. Het was mooi geweest als de overgang naar GIMP 3.0 dan vast in een niet-LTS release had gekund.

[Reactie gewijzigd door thomas_n op 25 juli 2024 12:01]

Thomas, dat kan misschien in een snap uitvoering......
Lijkt me logisch. Er staan gewoon nog teveel dingen open en in het gunstigste geval zijn die ergens in het laatste kwartaal afgerond.
Geheel reëel; Iedere distributie heeft een deadline voor de tools en versies de ze opnemen. En ja, soms wordt dat gelicht door een versie die bijna af is toch alvast mee te nemen. Maar soms wordt dat ook andersom aangepast omdat de nieuwste versie niet helemaal past of andere afhankelijkheden heeft.
Snap het probleem niet zo. Dan stuur je een paar weken later de update.
Of je installeert iets als flatpak
Snap het probleem niet zo.
Het artikel is iets onvolledig. Er zijn nogal wat andere stukjes software welke afhankelijk zijn van GIMP. Zo'n nieuwe versie is dus niet alleen maar een verandering voor 1 stuk software, ook voor alles wat ervan afhankelijk is. De korte aankondiging bevat een link welke summier laat zien dat het niet enkel om GIMP gaat: https://release.debian.org/transitions/html/auto-gimp.html

De aankondiging geeft aan dat er 0 werk hierin is verricht. Het is dus niet werkbaar om zoiets "een paar weken later" te doen. Verder gaat dat in tegen hoe distributies gewoonlijk werken, met wat uitzonderingen (browsers) krijg je gewoonlijk alleen kleine updates van software. En dus niet iets als een nieuwe GNOME, nieuwe GIMP, etc.

Op dit item kan niet meer gereageerd worden.