K3b ble sluppet i betaversjon i går. Dette vil ventelig være den eneste betaen og den endelige versjonen skal ifølge utviklerne lanseres i slutten av måneden.
Blant nyhetene i betaen er støtte for blu-ray, ikonsett fra Oxygen-teamet og åpning av prosjekt/"image"-filer direkte i K3b.
I tillegg er en rekke bugs fikset.
QtanJ 1. februar 2010 - 21:12
Åja, er k3b framleis alpha/beta. K3b er eit av dei programma eg aldri har opplevd feil i. Eg har vore dum og øydelagd ein cd-brennar av å trykkje på eit val som var merkt farleg(overbrenning, brenn utover kapasiteten til cd-en), men det er ein feil frå min side, ikkje frå k3b si side. Dessutan var dette i <=k3b-0.11.24.
No kan eg for så vidt ikkje seia at eg verkeleg har testa k3b, men eg har brukt han til vanleg bruk over sju gonger sidan eg oppgraderte frå k3b-1.0.5 til alpha-versjon. Ingen feil.
K3b-alpha3-4 i KDE4.3.x fungerer betre for meg enn plasma og kontact i 4.3.x. K3b fortener i alle fall å vera i extra-gear slik at dei kan gje ut nye versjonar når dei er klare for det i staden for å måtte skynda seg med versjonar for å passa inn i ein seks-månader syklus.
Eg vil heller ha ny versjon kvar månad, kvar sjuande månad, eller av og til, enn at utviklarane er hindra av ein syklus som ikkje passar dei. No vil eg ikkje seia at alle prosjekt tapar på ein seks-månaders syklus, men dei må innstille seg på syklusen, og ha eit prosjekt som har forutseieleg utvikling. Når utviklaren sjølv vel å stå utanfor er det nok ein god grunn til det.
omaha 1. februar 2010 - 21:44
Sebastian Trueg (ansatt hos Mandriva) fikk i oppgave å ferdigstille K3b for KDE 4 slik at den var klar i Mandriva 2009.0. Så i praktiske henseende har den vært klar for KDE 4 i snart 1 år.
Da blir det er vel kanskje litt paradoksal - at det var lanseringssyklusen til Mandriva (6mndr) som var drivkraften ;)
Det finnes nok mye med "released" status som er værre enn K3b. Jeg har ihvertfall aldri hatt problemer med den, og jeg har kjørt svn-versjon det siste året.
Trueg er sentral i semantic search også, og Mandriva har vel den beste implementeringen av Nepomuk også (mht b.la integrasjon med applikasjoner). Faste sykluser er ikke nødvendigvis negativt - og det er ikke nødvendigvis positivt. Det kommer helt an på hvor godt strukturert prosjektet er.
Nå sier ikke jeg på noen måte at KDE 4 er perfekt, men distroenes håndtering har jo en god del å si så.... Jeg opplever ikke plasma og kwin som spesielt trøblete - med unntak av applikasjoner/plasmoids osv som er kompilert med/for "feil KDE/Qt-versjon"...
QtanJ 1. februar 2010 - 22:16
Poenget var ikkje å kritisera plasma og kontact, det har eg gjort nok frå før av, men å rose k3b.
Eg er svært fornøgd med statusen til kbluetooth og k3b, nettopp fordi dei gjev inntrykk av at den lause syklusen er ein fordel for dei.
Det er sant at faste syklusar ikkje treng vera eit problem, men det passar ikkje for alt og alle. Alle må få lov til å velje den syklusen dei sjølv meiner er fornuftig uavhengig om han er fast eller laus.
Poenget med å rose k3b for denne lause syklusen er fordi eg tenkjer k3b er meir eit program for KDE enn av KDE. Små uavhengige program har vore viktig for linux slik eg brukar systemet. Eg liker rett og slett mentaliteten bak extra-gear fordi dei for det fyrste vert distribuert uavhengig og er enkle å velje bort i alle distribusjonar. For det andre får dei oppdatera seg i sitt eige tempo. No trur eg dei programma som faktisk er i KDE har klart å tilpassa seg syklusen, men KDE er stort. Eg kunne aldri tenkje meg å installera heile KDE. Her er kanskje problema som oppstår også.
Eg oppdaterer systemet mitt litt kvar veke. Fordi det av og til inneber at eg må tenkje under oppgraderingene er det fint at ikkje alt kjem på ein gong. Difor er eg svært glad i uavhengige prosjekt som oppdaterer seg når dei er klare for det i staden for at alt skjer samtidig.
Det gjer dessutan livet enklare for distribusjonsutviklarar. Dersom ein oppdaterer litt om gongen vert det enklare å finna ut når og kvar feilen ligg i staden for å sjå alle feila på ein gong.
Alle bibliotek er utvikla med tanke på nylege versjonar av biblioteka dei krev. Dersom alle skulle oppdatert seg samtidig hadde det vore vanskelegare å oppdaga konfliktar mellom dei i tide. Eg er overbevist om at ulike syklusar er viktig for linux slik utviklinga er i dag. Det hadde vore upraktisk om alle utviklarar måtte bruka scm-versjon av alle program for å kunna halda fram. Ulike syklusar gjer dette enklare. Distribusjonar som har ulike versjonar mot same bibliotek gjer dessutan biblioteka meir robuste ved at feil på grunn av denne ulikskapen vert retta.
omaha 1. februar 2010 - 22:41
Prosjektene velger selv hvor tett de ønsker å knyttes mot - i dette tilfellet KDE SC - og det synes jeg er helt greit. De som mener det er bedre for dem å være en del av SC gjør det om kode/funksjon duger. Trives de bedre utenfor - ja så er det der de bør være.
Jeg synes også Extragear er praktisk på mange måter.
Årsaken til at jeg nevner implementering generelt er at jeg mener å huske at du har påpekt slik problematikk i Gentoo i forbindelse med overgang fra 3.5.x til 4.x
...på den annen side anvender jeg fortsatt WicD fremfor Knetworkmanager/plasmoid... ;)