KDE bliver nødt til at vælge mellem Flatpak-pakker og snap-pakker

KDE-logo

For et par dage siden så vi, hvordan KDE-udviklerne lancerede snap-pakker af deres applikationer, som var en af ​​skrivebordene til at dykke ned i dette format. Men lige da vi alle troede, at det ville være KDE's foretrukne format, læste vi et par ord på en KDE-udviklers blog, som varsler et fremtidigt problem for KDE- og Plasma-brugere.

Dyderne ved denne type pakke er indiskutable, og den pågældende udvikler, Sebastian Kugler, han tvivler ikke på det, men han bekræfter, at i fremtiden bliver KDE nødt til at vælge mellem et eller andet format for at optimere indsatsen og arbejdsbelastningen.

Så i en ikke alt for fjern fremtid, KDE bliver nødt til at vælge mellem at frigive pakker i Flatpak eller Snap-pakker. Et dilemma, som flere og flere udviklere står over for, og som nogle desktops som Gnome hurtigt løste.

Flatpak kunne være det foretrukne format for det meste af KDE-fællesskabet

Kugler ind Hans artikel Han hævder, at skrivebordet burde vælge Flatpak på grund af dets cross-distro crossover, men det er rigtigt, at udviklingen på Snap i øjeblikket er mere avanceret end på Flatpak. Under alle omstændigheder er KDE-fællesskabets interesse fordi skrivebordet være tilgængelig i så mange distributioner som muligt, noget der synes mere muligt med Flatpak end med snap-pakker, som kræver værktøjer skabt af Canonical.

Hele KDE-fællesskabet har endnu ikke talt om det, men som Kügler siger, kan de lide det eller ej, de bliver nødt til at vælge et eller andet format. Jeg tror personligt på, at valgets øjeblik vil komme, men Kubuntu er et meget aktivt fællesskab, og de vil helt sikkert få snap-pakken til at leve videre i KDE, ligesom KDE-brugere af OpenSUSE og Fedora vil med Flatpak-formatet, så uanset valg, vil der altid være nogen i KDE, der vedligeholder begge formater, men Hvilke brugere vil de vælge?


Efterlad din kommentar

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *

*

*

  1. Ansvarlig for data: AB Internet Networks 2008 SL
  2. Formålet med dataene: Control SPAM, management af kommentarer.
  3. Legitimering: Dit samtykke
  4. Kommunikation af dataene: Dataene vil ikke blive kommunikeret til tredjemand, undtagen ved juridisk forpligtelse.
  5. Datalagring: Database hostet af Occentus Networks (EU)
  6. Rettigheder: Du kan til enhver tid begrænse, gendanne og slette dine oplysninger.

  1.   Luis sagde han

    Hvilken nonsens nyhed er det her?
    Der er tusinder og atter tusinder af programmer, der er pakket af samarbejdspartnere/arbejdere af distributionerne, hvilken forskel gør det, hvis KDE stopper med at distribuere det ene eller det andet eller begge dele?
    Det giver en følelse af, at man gerne vil skabe frygt og polemik blandt læserne for at få besøg, og jeg vil ikke sige, at det forekommer mig dårligt, men i dette tilfælde er der ingen steder at tage det.

    1.    Charles sagde han

      Det er blot en vurdering af valget af en større ramme frem for officielle pakker.

      Forståelse af driften af ​​de nye teknologier tilskynder dybest set til distribution af applikationer, der skal bevilges direkte af deres udviklere, og derfor er "pakkevedligeholderne", som vi forstår dem i dag, udeladt. Fx ville X-pakken i Flatpak-format være den samme, som officielt distribueres af KDE på Fedora og OpenSUSE. Ellers ville det være at miste initiativet og gå tilbage til business as usual (unødvendigt ekstra arbejde)

  2.   fladtrykt sagde han

    Det er, at det nye pakkesystem åbner mulighed for, at udvikleren kan lave pakkerne og holde dem opdateret. Så striden giver god mening. Hvis KDE beslutter at distribuere i ét format, bliver andre bidragydere nødt til at oprette hinandens, hvis de er interesserede. Og selvfølgelig vil de altid være bagud.

  3.   Charles sagde han

    Det blev for nylig annonceret, at KDE Discover vil understøtte både Flatpak og Snap-pakker (fordelene ved appstream, packagekit osv.). Men i betragtning af, at deres nye flagskibsdistro er KDE Neon, som er baseret på Ubuntu, er det meget nemmere at implementere Snap og endda blandet Snap/Flatpak-understøttelse på systemet.

    Modulariteten, brugervenligheden og uafhængigheden af ​​Flatpak giver det en stor fordel i forhold til Snap, og jeg forstår ikke, hvor de får fra i artiklen, at Snap i øjeblikket er mere avanceret end Flatpak i dag, da det er det modsatte. Selv efter begges forandringshistorie, har Snap gradvist ændret sin vision efter de samme parametre, som Flatpak har foreslået som en løsning, og som "besynderligt nok" blev kritiseret af dem i starten.

    Jeg gætter ikke på en vinder, men jeg har set mere arbejde og interesse omkring Flatpak.