[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Versionsnummershysteri (Was: Re: Re: Nån utvecklare här... Designfels-ex



On Tue, Aug 06, 2002 at 02:04:56PM +0200, frepe@bredband.net wrote:
> Jag förstår fortfarande inte vad som menas med att släppa "i tid". (Jo, det 
> gör jag, för kommersiella distros som RedHat, men inte för Debian.)

"i tid" än innan grunden till systemet är så gamal att den inte fungerar
längre, i d.v.s. innan innan föregånde version känns för mycket
outdated. Klart det är subjektivt, men efter som mycket rör på sig
(grafikkort, cpu:er, bussar hårddiskar etc. Om stable inte går att få
igång på några nyare maskiner känns det som om det inte kommit en ny
version i tid.

> Ja, och jag förstår fortfarande inte vad som är fel med att cyklerna är långa.

Det tar mer tid att underhålla och testa koden. Du måste backpatcha
lösningar till problem (så länge som man tänker hålla upp support på
den stabikla versionen.)

> > Jag vet inte om du är medveten
> > om det men ju mer man pillar och ju längre tid som går, ju mer kostar
> > det att hålla uppe kvaliteten. 
> Men det där är ju inte sant! Det skulle ju betyda att om man 
> putsar ("pillar"?) mindre på ett programpaket, och lägger 
> färre timmar på det, då skulle kvaliteten på det öka? 

Nej, man man inför inte heller nya problem, ju mer man gör ju mer måste
testas, ju mer tid tar just detta testande. Och gör amn om det mesta
mellan två test-cykler kommer det att finnas ett antal nya problem. Ju
mer man gör om mellen testander ju mer kan gå fel. Alltså destå fler nya
fel får man. Han man något helt och inte pillar på det är det mindre
chans att det går sönder.

> Ja, i så fall kostar det naturligtvis mindra att upprätthålla 
> den nivån, eftersom den är lägre. 

Nej, jag pratat i prinsip bara om det jobber som går åt för att testa
systemet. Den ökar otroligt mycket.

> Jag tycker också att det är bra med ständigt förbättrad kod och 
> jag kan inte se annat än att det går till precis så i Debian.

Då vorde det dags att titta på hur andra löser sina problem, var det har
för för och nackdelar. Mycket nedlaggt tid och jobb i Debian har kommit
just på grund av den växnade cykeln.

> När satte Debian upp mål som de inte nådde upp till och som 
> blev utfasade för något annat? (Jag antar att du menar att man 
> slösar bort en massa arbete som blir "obsolete".)

Jag har för mig att t.ex. dselect var ett sak som helt skulle tas bort
och skrivas om till "Woody". Har för mig att även dpkg var på tapeten
att bytas ut, och skrivas om helt. Men det var så länge sedan.

> 
> > För att visa på attt det fungerar titta lite på hur OpenBSD har sin
> /.../
> 
> Nu är det ju säkert mycket enklare för OpenBSD-utvecklarna
> att proklamera ett bygge som "stabilt", eftersom de inte har 
> en bråkdel så många paket att hantera som Debian. Kom ihåg 
> att Debian är (eller var i alla fall väldigt länge) den i särklass 
> största Linuxdistributionen. Och dessutom ska det vara 
> stabilt på långt fler arkitekturer än OpenBSD behöver vara.

En eller 0 fler arkitkturer (Ibland räknar Debian samman två två MIPS
varianterna) OpenBSD stöder 10 arkitekturer, Debian 10 eller 11, jag
tror inmte det är den stora stötestenen. Debian är dessutom till antalet
folk och testare otroligt mycket större än OpenBSD så de borde orka med
det större antalet packet. (Någon skriver ju faktiskt dem.) Men vist det
är mer paket i Debian, destå större anledning att hålla test och
verifierings jobbet minimalt. 

> Det är klart, att det vore en idé att släppa hela arkivet på CD 
> en gång i kvartalet eller så, men det låter som en så självklar 
> grej att jag skulle bli förvånad om det inte redan görs.

Det görs inte riktigt så, 

> 
> > För det är väll ingte många som under det senaste året
> > rekomenderat någon att välja potato? Dessutom att underhålla gammal kod
> > kräver mycjket extra arbete, specillt för säkerhets patchar etc. Något
> > soöm tar resurser från annat som kunde gjort större framsteg.
> 
> Jag har kört Potato på en brandvägg hemmavid i drygt ett år. 
> Om någon frågat mig under den tiden vilket som var det bästa 
> OS-et för en hemmabrandvägg så skulle jag svarat Potato 
> utan att tveka.

Där håller jag inte med, OpenBSD, skulel bli mitt svar klart med stuibl
och mycket bättre brandväggs kod (imho). Men för de flesta lägen så har
inte Potato varit det bästa valet, detta för att för mycket i den
distributionen visserligen fungerat men inte varit.

> Jag tror inte att säkerhetspatcharna till Potato har tagit speciellt 
> många mantimmar från t.ex. Woody-releasen. När t.ex. en 
> buffer overflow upptäcks så är det ju ett snabbt åtgärdat 
> problem. Och med apt-get så är det ju en extremt smal sak 
> för såna som mig att hämta patchen också.

Mitt minne för delajer är i sig inte 100 men det har funnits problem där
upstream bara fixat hålet till nyare versionen och dessa fixat av debian
behövt backporteras till en gamal version. Frågan är om detta alltid är
bra, om man missar andra prolem. Dessutom tar det garanterat tid att
göra. Det är den främsta anledningen till att de flesta anda försöker
hålla sina versioner inärhetet av leverantörens versioner. Då slipper
man att göra deras backpatchnings jobb. (Men mycket fler packet kommer
detta att bli ett allt större jobb.)

> > > Själv känner jag starkt för Debian, och en av anledningarna är just
> > > att man vare sig vill, kan (hehe!) eller behöver klämma ur sig
> > > pressmeddelanden om nya versioner. Det är befriande, intelligent och
> > > pragmatiskt.
> > Men många stpra nackdelar, det är enklare att inte i varje gång försöka
> > göra revolution. 
> Jag har inte talat om att göra revolution. 

Att sätta mål att alltid omstörta stora delar av grunden till systemet
är nära en revolution i alla fall. Annars just detat som du pratar om
burkar också ses som *BSD:s styrka trors det så kommer nya versioner som
en klocka. Skillanden är att där gäller det kanske mer innehållet.

> > Personliget tycker jag bättre som en evulution mot bättre
> > programvara, lämna säkra stabila avtryck då och då, se till att det
> > fungerar. 
> Om NÅGON i Linuxvärlden "ser till att det fungerar" så är det 
> Debian, det vill jag bestämt påstå!
> 
> Dessutom lämnar man faktiskt stabila "avtryck", med ett 
> par års mellanrum.

Det senaste nu jag, ett par års melen urm ser jag som mycket stort
mellean rum, Innan Woody flöt det mycket smidigare, ingen versioan av
debian har varit så sen som Woody, varför? Är det bra, Woody skulle ha
kommit till långt tidigare, finns det någon anledning att man får samma
delay till nästa release. (Så att det blir en 4.0 och inte en 3.1?) Inte
för att det är något fel att planera för 4.0 men man kan ju hålla ångan
uppe till 3.1 ett tag. (Målet som kanske hade kunnat nås var att släppa
Woody i Februari 2001.) Detta har sedan reviderat i många setg, ett bra
mail är till Deval-annonce från februari 2001, om problem med Potato och
Woody och ett försök till att sätta någon form av ordnig:
http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200102/msg00014.html
Detta är från när man började se att Woody hll på att falla i bitar
första gången.

> var ju inte stabilitet som jag förstod det utan att man inte 
> hade en fungerande struktur för säkerhetsuppdateringar. 
> (Rätta mig om jag har fel.)

Förta problemet var att boot-floppies inte ville vara med på alla
arkitekturer som man hade lovat skulle fungera. SÅ man sket i att släppa
woody då. (DÅ var woody stabilt på i prinsip allt utom någon
arkitektur.)

> Och som sagt... 3.1, 3.2 osv... jag tror inte riktigt på det. Det är 
> nästan 10000 paket som ska synkas ihop och det är väl 
> arbetsamt att göra det en gång i halvåret. 

Man man hela tiden håller sig syncas slipper man det jättejobbet, det
just det som min argumentation bygger på. Se till att man i prinsip
alltid har en testet och uppdaterad version så blir det inte så jobbit
att synca allt.

/ Balp
-- 
      o_   Anders Arnholm,               HiQ - Consultant
 o/  /\    anders@arnholm.nu             Phone  : +46-703-160969
/|_, \\    http://anders.arnholm.nu/     http://www.hiq.se
/
`

Attachment: pgpsP_d3cLkwO.pgp
Description: PGP signature


Reply to: