Free Standards Group julkisti Linux-standardin

Noh tuota.

1) Useamman interfacen tukeminen voi olla infernaalista. Ainakin vielä vuosi sitten rpm:ssä oli aika.. mielenkiintoiset hackit bzip2-kirjaston löytämiselle, kun bz2-funktioiden nimiä vaihdettiin, syystä. Ne hackit aiheuttivat käytännössä ongelmia kuin hyötyä. Vaateita siitä, mitä pitää tukea ja miten, on kyllä paljon, mutta kovin vähän fiksejä. Yleensä pidemmällä tähtäimellä kehitystyössä on käytännössä pakko pyrkiä joissain asioissa minimoimaan oma vaivansa, jotta saa jotain aikaiseksikin.

2) Uusin "vakaaksi" luokiteltu versio sisältää yleensä myös uusimmat bugikorjaukset. (Ja uusimmat bugit.) Ja uusimmat ominaisuudet - jotkut noista ominaisuuksista jopa toisen softan ominaisuuksien kannalta ihan oikeasti välttämättömiä. Joskus uusin valmistajansa "vakaaksi" luokittelema versio ei ole oikeasti riittävän vakaa, ja joskus taas liiaksi jäljessä kehitysversiota. Tämä on tapaus- ja tilannekohtaista. (Toiselta softalta vaaditaankin erilaista vakautta kuin toiselta.) Minä luottaisin tässä järjestelmien toimittajien ja softankehittäjien harkintakykyyn enemmän kuin yksittäisten käyttäjien, jotka eivät ehkä tunne softan sisuksia yhtä hyvin.

Monipuolisin? Ja milläköhän tavalla? Tarkoitit varmasti monipuolisin hajoittamaan kaikki depencyt ja monipuolisin saamaan käyttjän kiroilemaan kun rpm-paketti vaatii taas uuden rpm-paketin jne?

Debianin pakettienhallinta on helppo, toimiva, avoin jne. Miksi pitäisi käyttää jotain vanhanaikaista systeemiä mistä ei ole muutakuin haittaa? Parempia ehdotuksia?

Man rpm. Perus pakettimanagerina ja siihen liittyvänä toiminnallisuutena se nyt vaan on kaikkia muita kirkkaasti edellä. Ei sitä huvikseen standardiksi valittu.

Se miten ne paketit on rpm:llä kasattu ei ole rpm:n ongelma. Jos ne on haluttu jostain syystä tehdä tarpeettomasti solmuun, niin ei se sitä estä. RPM on VAIN pakettimanageri, se asentaa ja poistaa paketteja sekä pitää niistä kirjaa. On paketinhallintatyökalun (ei rpm:n) tehtävä kaivaa jostain ne dependecyissä mainittavat paketit jos et itse osaa sitä tehdä.

RPM on pakettimanagerina monipuolisempi. Usko pois :). Tosin mitään automagiikkaa se ei siihen ympärille tarjoa eikä minusta ole tarpeenkaan. Se on aivan toinen tehtävä. Sekoitatte tasaiseen puurot ja vellit asian suhteen. Paketinhallintatyökaluna RPM:n päällä esim. SuSE:ssa toimii YaST, joka tekee RPM:llä sen haluamasi automagiikan.

Esimerkki. RPM:n ideologia toimii seuraavasti. RPM ei tiedä mistään muusta, kuin järjestelmässä olevista paketeista ja niiden keskinäisistä riippuvuussuhteista. RPM:n päälle rakennettavan paketinhallinnan tehtävä on pitää kirjaa ko. distribuution muista kuin asennetuista paketeista (saatavilla olevista) ja hoitaa ne tarvittaessa haluamallasi tavalla sisään. Nämä ovat kaksi eri tehtävää, ja ne on syytäkin eritellä. N

Jäi lisäämättä tuohon, että ellei näitä toiminnallisuuksia ole asiaan kuuluvasti debianissa eroteltu, sehän naittaa koko paketointijärjestelmän täysin riippuvaiseksi ko. distribuutiosta ja näin ollen vesittää täysin sen mahdollisuudet mihinkään standardin asemaan.

Usko pois, monesti näin käy, kun ei aleta SOFTASSA paikkaamaan esim. glibc:n vikaa vaan oletetaan että alla oleva versio toimii. Se kuka sen sinne libc:hen on korjannut, ON YHDEN TEKEVÄÄ KUHAN SE TOIMII.


Totta ihmeessä. Syystä jota sanoin yllä. ÄLKÄÄ NYT HYVÄT IHMISET tehkö softaanne niin, että se on riippuvainen jostain rikkinäisestä antiikkisesta kirjastosta..


Ei, vaan niiden kanssa on vähemmän, ne kun piru toimivat kuten alun perin OLI TARKOITUS. ELI: jos teet rikkinäisen toteutuksen päälle oman softasi, niin olet TASAN NAIMISISSA siihen rikkinäiseen versioon, koska olet sen puutteita paikannut OMASSA SOFTASSASI. Oletko koskaan yrittänyt tehdä tuolla 2.95.3 release-gcc:llä töitä ?!? Se ei toimi vähääkään ilman niitä satoja patchejä. NE EI OLE SIELLÄ HUVIN VUOKSI.

rpm -q gcc;
gcc-2.95.3-136

rpm -q gdb;
gdb-5.1-17

rpm -q glibc;
glibc-2.2.4-64

Niin muut kuin ne, jotka käyttävät ko. systeemiä johonkin kriittiseen.

Olen samaa mieltä, softan toimesta ajatusten lukeminen on syvältä, JOS sitä ei voi tarvittaessa kiertää. Mikäli se toimii, eikä minun tarvitse mihinkään koskea, tilanne on optimi ja juuri mitä haluan. Jos se saa tiedot suoraan järjestelmästä, ei minulla ole mitään sitä vastaan ettei se ala minulta tietoja turhaan tivaamaan.

No oletko lukenyt BugTraqqia viimeaikoina ;) ?

Hmm. Aloitit puheen korjauksilla glibc:hen.

Jos jokainen valmistaja tekee omat fixinsä, ja fixien fixit, ja arvaukset siitä, milloin fixin fixi on paikoillaan ja milloin ei, softankehitys jo melko lyhyelläkin aikavälillä sekä vaikeutuu että monimutkaistuu niin, että käyttäjillä on käytännössä huonosti toimivaa tai toimimatonta softaa käsissään. Tällaiset asiat voi vallan mainiosti hoitaa monissa tapauksissa ilmoittamalla esim., että tuetut versiot jostain kirjastosta tai alustasta ovat nämä ja nämä, tai että jotain alustaa ei tueta siksi että se on rikki tavalla X.

Todellisuus on tietenkin jotain tällaisen semianarkistisen "mikään ei voi toimia joten varaudutaan vähän kaikkeen"- ja idealistisen "kun kaikki puhaltaa yhteen hiileen niin elämä on kivaa ja kaikkialla on kukkasia ja perhosia"-ajattelun väliltä.

Yksi erittäin hyvä kysymys on, mikä versio on "standardi". Määritteleekö softan kirjoittaja (vaikkapa GCC:n kehitystiimi), järjestelmäjulkaisija (esim. RedHat), vai ehkäpä jokin yhteinen standardi sen version?

ANSI tai ISO C ei riitä vastaukseksi. Ei ainakaan niin kauan, kun RedHatin oma koodi ei ole kaikkialla standardinmukaista.

Vaan rikkinäisestä uudemmasta kirjastosta? Uusi kirjasto voi olla rikki tai ei-rikki. Luulisin, että huomattavasti pienempi määrä ihmisiä on kykeneviä arvioimaan ko. asiaa kovin hyvin kuin mitä jotkut tahtoisivat ajatella.

Ei se poista sitä käyttäjän ongelmaa, että jokin softa ei toimi. Kuten sanoin, suurin ongelma tässä asiassa oli tiedotus: käyttäjiä ei varoitettu siitä, että kääntäjä eroaa useimmista muista kääntäjän versioista, ja siitä, että kääntäjä on nyt (f)rigidimpi ja jättää väärin tehdyn koodin mahdollisesti kääntämättä kokonaan.

Voisitko kirjoittaa nämä kaksi toteamusta jotenkin vähän konkreettisemmin auki?

OpenBSD:n kääntäjäversio on melko lähellä -releasea.

Tu-tuota noin. Ei tässä nyt ole kysymys mistään hengenvakavasta asiasta. Kumpikaan meistä ei uskoakseni suunnittele punahatun softia, vaan antaa niiden laadusta lähinnä palautetta. Siksi voisi olla paikallaan opetella caps lock -näppäimen paikka.

Onko RedHatin mielivaltaisesti valitsema oma julkaisunumerointi siis jossain suhteessa siihen, mitä standardilta systeemiltä voi edellyttää.

Miksi nämä ihmiset eivät sitten huomanneet ldconfig:sta puuttuvaa PGP-sigiä?

Mitä nämä ihmiset oikein tekivät sinä aikana kun tuo sigi puuttui?

Hmm. En oikein ymmärrä, mistä konkreettisisista asioista puhut. Minulle on jotenkin niin itsestäänselvää, ettei asioita, jotka voi päätellä käyttäjältä kysymättä, kysytä, etten osaa mieltää, missä tilanteessa sellaisia asioita sitten kysyttäisiin.

Mainitsemani järjestelmäthän kysyvät hyvin vähän - levyn osiointi, purettavat paketit melko lyhyestä ja selkeästä listasta, jne. Ne ovat huomattavasti nopeampia käyttää, kun ei tarvitse ihmetellä jollain graafisella kilkkeellä, mitä kilke on nyt päättänyt minun haluavan.

Ei bugtraq ole minkään valtakunnan mittari. Siellä julkaistu materiaali on usein tasoa "sain non-setuid ohjelman coredumppaamaan, tämä on selvä tietoturvariski!" tai "jos pääset tietokoneeseen fyysisesti käsiksi, voit ottaa sen haltuusi!".

Montako remote exploittia default-installissa on ollut RedHattiin viimeisen neljän vuoden aikana? Entä montako Debianiin?

Viittasin nimenomaan gnu:n toteutukseen.

Kuuleppas kun ne fixit esim glibc:hen eivät ole rakettitiedettä. On suhteellisen triviaalia sanoa, mikä on vika ja mikä ei. Näin ollen korjaaminenkin on sitä; tarkoituksena valmistajakohtaisilla patcheillä on NIMENOMAAN poistaa triviilit bugit joita esiintyy release-versioissa aina.

Aivan. TÄSTÄ SYYSTÄ älä ihmeessä tee dependencyä rikkinäiseen kirjastoon Y, vaan oleta että alusta toimii. Tätähän yritin alusta alkaen selittää.

Kyllähän sinä nyt komeasti koetat vetää savua ja peilejä yksinkertaisen asian eteen.

C:stä ja C++:sta meillä on standardit. Se määrittelee miten itse kielen kuuluisi toimia, ei GCC:n kehitystiimi tai yksittäinen distro. Toisekseen kun ongelmana on SUORANAISET RÄJÄHDYKSET kehitysvaiheessa, lienee sanomattakin selvää että kyseessä on VIRHE JOKA ON KORJATTAVA. Koeta tehdä sillä release gcc:llä jotain ja tule sitten selittämään ;)

En käsitä. Toiset korjaa asioita, niin sinä siitä vielä valitat ;) ?

Huh huh. Siihen se pyrkii, ihan turhaa vääntelet ja kääntelet asiaa. Mitään salaliittoteoriaa ei ole, ei siellä yritetä tehdä mitään distrokohtaisuuksia. Ainakin allekirjoittaneen tapauksessa SuSE ja RedHat ovat kummatkin tehneet esimerkillistä työtä tällä rintamalla tehden vaativamman kehitystyön EDES MAHDOLLISEKSI linuxille. Näiden välillä, kun homma toimii, kehitystyö on mahdollista kummallekin alustalle VAKAASTI eikä isompia erikoisuuksia esiinny. Miksi pitäisi olla riippuvainen siitä antiikkisesta rikkinäisestä glibc:stä ? En käsitä vieläkään.

Hei. Teen tätä työkseni. Tiedän asiantilan tarkalleen. Pääsääntö vaan tuntuu olevan että uudemmat versiot korjaavat huomattavan paljon enemmän entisten puutteita kuin tuovat uusia. Mistä muutenkaan saisit tukea vanhalle versiolle ? GCC:n kehitysremmikin toteaa tukea kysyessäsi, 'olemme korjanneet asian, herra on hyvä ja päivittää'. En edes halua koettaa (enää) tehdä itseäni naurunalaiseksi ja kysellä sieltä suunnalta moisia.

Se, että taasen ehdotat sovelluksen korjaavan alustan bugeja, tuo käsillemme sellaisen sillisalaatin, etten haluaisi koskea siihen pitkällä tikullakaan. Jos kehitystä tehtäisiin mainitsemallasi tavalla, windowsin dll-hell olisi kevyttä verrattuna linuxin vastaavaan.

Selitetty yllä.

Ok. Otetaan yksi monithreadinen C++ applikaatio jossa STL on käytössä ja ajetaan. Hyvinkö toimii cross-platform (sama koodi kääntyisi ja toimisi usealla alustalla) jos olet tehnyt sinne riippuvuuksia alla oleviin rikkinäisiin paketteihin ? Kuinkas toimii threadien debuggaus tuolla gcc/gdb versiolla ? Minkä threadin coren saat vakiona (vinkki: se heittää nopalla ;) ? Mitä toteaa 'info threads' muuta kuin kaboom ? Kuinkas toimii 'next' (vinkki: tekee step:n) ? Entäs mitä tapahtuu, kun koetat stepata STL:n mapin sisälle katsomaan mitä tapahtuu (vinkki: print hajoittaa koko roskan) ?

Mahdat olla oikeassa, mutta kyllä minä suunnittelen softaa linuxille ihan työkseni. En punahatulle, suselle, debianille vaan toimivalle linuxille.

Ei tuo ole mielivaltainen. Ihan se on sama kaikissa RPM pohjaisissa (standardin mukaisissa ;) järjestelmissä. Yllä oleva on SuSE 7.3:sta.

No kuinkas asentuu skannerisi mitään kysymättä debianiin ? Sieltä USB väylästä saa kyllä ihan suoraan tiedot mitä siellä majailee, että sanen konffit pystyyn vaan sen mukaan. Mitä tuota suotta käyttäjältä tivaamaan.

Koetas YaST:ia. Siitä on ei-graafinen versiokin (YaST1) joka ei oleta kerta kaikkiaan mitään.

Juu onhan siellä tuotakin. Vaan paljon on puhdasta asiaakin.

Eipä vastaa nyt securityfocuksen stats. Redhat ei kyllä noissa ole menestynyt SuSE:n tai debianin tasolle, mutta toisaalta, sen käyttäjäkuntakin on moninkertainen. OpenBSD:lle ei myöskään ole löytynyt juuri mitään, kun ei-juuri-ketään ko. järjestelmä desktop käyttöön kiinnostakaan.

Hmm. Nyt, kun luin viimeisimmän vastaukseksi, aloin tajuta, että puhumme ehkä hieman eri asioista.

Minullekin standardeja noudattava, puhtaan korrekti ohjelma on ensisijaisen tärkeää.

Mutta minusta korjauksien sykli RedHatista ja Susesta tai erinäisiltä mailing-listoilta "viralliseen" julkaisuun on liian pitkä. Minusta nämä korjaukset pitäisi olla jossain julkisessa repositoryssa, jossa on vain ja ainoastaan ne korjaukset, kuvauksineen. Eri valmistajat voisivat esimerkiksi merkata korjauksia hyväksytyksi (esimerkiksi vain importoimalla ne myös omikseen), jolloin myös ne korjauksia lukevat, jotka eivät ymmärrä koko ohjelman rakennetta, voisivat arvioida, kuinka tarpeellisia ne ovat.

Korjausten etsiminen mailing-listoilta on työlästä muun keskustelun seasta. Eri paketeille näitä valmistajakohtaisia korjauksia etsineenä (integroidakseni niitä tarpeen mukaan toiseen järjestelmään) voin sanoa, että jokaisen valmistajan patchien läpikäynti on huomattavan työlästä, varsinkin, kun on vaikeaa sanoa, mikä on yleinen korjaus, ja mikä on korjaus jollekin tietylle alustalle. Jotkut valmistajat tekevät enemmän yhteistyötä suoraan kehitystiimiin (erityisesti ainakin punahattu, suse ja debiili, joiden kehittäjistä osa on suoraan kytköksissä gnu-kehitystiimeihin), ja joskus kaikilla valmistajilla on osapuilleen samat korjaukset, mutta suinkaan aina näin ei ole.

Tämä on melko olennaista open source -kehityksen kannalta. En tarkoita suinkaan sitä, että valmistajat eivät saisi forkata omia tekeleitään - tämähän on päinvastoin yksi open sourcen päämääristä. Yleensä ei kuitenkaan ole kyse tarkoituksesta forkata yhtään mitään, vaan tarjota jokin olennainen korjaus tai ominaisuus. Puhun siitä, että open source rakentuu sen pohjalle, että kaikki muutokset softaan ovat kaikkien käytettävissä, ja kilpailuedut pohjautuvat muihin asioihin kuin näihin muutoksiin (kuten esimerkiksi valmistajan muihin, kaupallisiin softiin, tuen tarjontaan, jne.)

Siis: minusta on hassua, että joku gcc-kehittäjäksi luokiteltava ihminen tarjoaa kriittisen fixin työnantajansa julkaisuun, muttei julkaise mitään "virallista" yleistä korjausta itse gcc:hen.

Minusta http://www.openpackages.org olisi jonkinlainen vastaus näihin ongelmiin. Ehkä ei, ehkä tarvitaan jotain muuta. Nykytilanteen kehittyessä eteenpäin meillä on joka tapauksessa kohta vastaava tilanne kuin kaupallisilla Unix-markkinoilla on ollut varsinkin jossain vaiheessa: kaikki hiihtelevät omia latujaan, eikä perustavanlaatuisia ongelmakysymyksiä hoideta yhdessä. (Nimenomaan tarkoittaen korjauksia, en uusia ominaisuuksia.)

Kuinka triviaalia on sanoa, milloin vian "korjaus" rikkoo toisen paikan isossa ohjelmistossa? Joskus on, joskus ei. Kyllä ihan oikeasti monia triviaalinnäköisiä vikoja on jouduttu paikkaamaan moneenkin kertaan kun on huomattu että tietyissä tilanteissa ne eivätkään ole enää triviaaleja. (Esimerkkejä esim. prosessin traceaminen tai säikeet.)

Olen ihan samaa mieltä tästä periaatteellisella tasolla, mutta käytännössä tilanne niillä valmistajilla, jotka haluavat tai joutuvat tukemaan useita alustoja, on se, että _tällä hetkellä_ joudutaan varautumaan siihen, että kirjasto on korjattu tai sitten ei. Juuri tämä tilanne on minusta väärä. Olennaisten korjausten pitäisi olla julkisia, koska varsinkin GNU-porukan patchien julkaisusykli on aivan liian tahmainen tai olematon. Fixejä ei julkaista yksitellen vaan isoissa kasoissa.

No, kyllä mä olen kääntänyt sillä kokonaisen käyttöjärjestelmän useita satoja kertoja. Olennainen ero tässä on ehkä se, että ko. järjestelmä ei nojaa kovin vahvasti säikeisiin sen enempää kuin oma ohjelmointikaan, koska ohjelmani eivät vaadi säikeitä (enkä periaatteessa käytä niitä ellei niitä vaadita).

Itse asiassa, minä korjaan asioita julkiseen repositoryyn. En ehkä niin paljon, kuin pitäisi, kun elämässäni on muutakin, ja koko päivää ei jaksa tehdä työnluonteisia asioita, vaikka osa niistä laskettaisiinkin enemmän harrastukeksi.

Valitan niin kauan kuin ihmiset uskovat että valmistajakohtaiset korjaukset ja korjausten korjaukset ovat välttämättömiä, koska se pitkällä aikavälillä kasvattaa jokaisen työtaakkaa, ja tekee käyttämästäni softasta bugisempaa, juuri noiden "arvataanpa-onko-tässä-tämä-korjaus"-klugejen vuoksi.

Eikä tämä ole suinkaan ainoa paikka, jossa valitan, mutta paikka tämäkin. Ehkäpä tämänkin tekstin lukija äityy kirjoittamaan palautetta järjestelmänsä toimittajalle.

Tämä ei ole oikeastaan asia-argumentti. Kyllä mä kerron ihan avoimesti, jos epäilen, ettei joku tiedä, mistä tämä puhuu. Ei syytä huoleen. :-) En kyseenalaista asiantuntemustasi omalla alallasi, mutta olen eri mieltä ajamiesi toimintamallien vaikutusta softankehitykseen yleisemmin.

Minulla on toisenkinlaisia kokemuksia. Kuten sanoin, tämä riippuu kovasti softasta - ja tietysti aikajänteestä. Eiväthän ei-triviaalit ongelmat yleensä löydy hetkessä, koska ne ovat tyypillisimmillään juuri niitä ongelmia, jotka eivät tule esille helposti, ja joita on vaikea toistaa.

Miksi sä sitä GCC:ltä kyselet? Kysele siltä, joka sen GCC:n sulle on toimittanut. Tämä asia on useasti ollut esillä: valmistajien omat versiot GCC:stä pitää merkitä valmistajien versioiksi, ja niille pyydetään tukea valmistajalta eikä suoraan GCC:ltä. Muutenkin on minusta luonnollista, että tukea haetaan juuri kaupalliselta tai muuten tukea lähtökohtaisesti tarjoavalta taholta, ei GCC-kehitystiimiltä.

Ehkä sitten kyseinen taho toimittaa myös sen päivityksen tai tarjoaa selityksen, miksi vanha versio on huonompi. Ehkä kyseinen taho tulee ajatelleeksi, että olisi hyvä tarjota tämäntyyppisiä korjauksia noin ylipäätään.

Niinhän nyt tehdään. En mielestäni sanonut, että niin _pitäisi_ tehdä, vaan että joissain tilanteissa, ja nimenomaan nykytilanteessa, se on käytännössä välttämätöntä, ja oli se hyvä tai ei, niin tehdään. Eri asia on se, mihin pitäisi pyrkiä, ja edistääkö asiaa yhtään se, että todetaan "tämä valmistaja on hyvä ja tämä huono, käyttäkää tämän valmistajan fixejä".

Hmh. En ole missään vaiheessa tarkoittanut riippuvuuksia rikkinäisiin paketteihin, vaan sitä, että tällä hetkellä on pakko tarjota korjaukset myös rikkinäisiin paketteihin, vaikka haluttaisiinkin tukea vain yhtä alustaa.

Kuinka monta ohjelmaa uusin devel-gcc, jossa pitäisi olla myös uusimmat valmistajien fixit (tai, jos ei ole, niin miksiköhän?), kääntää? Koska siinä on muutakin kuin nuo korjaukset, ei välttämättä montaakaan.

En punahatulle, suselle, debianille vaan toimivalle linuxille.

Tarkoitin lähinnä sitä, että ei meistä kumpikaan työskentele näille valmistajille. Vähemmän kiihtyneellä keskustelulla saa aikaan ehkä sentyylisen synteesin, jonka taakse voi asettua useampikin ihminen - vaikkapa sellaiset ihmiset, jotka antavat palautetta GNU-kehitystiimeille tai järjestelmätoimittajille. Ja näihin tehoaa myös asiallinen, vähemmän kiihtynyt palaute. ("Ongelmani on tällä hetkellä.." on toimivampi kuin "senkin hirviöt, olette taas kädettäneet, ettekö osaa mitään".) Ainakin minä pystyn helpommin kaivamaan sen itse korjattavan asian ensimmäisenmallisesta viestistä helpommin.

No, minä hoitaisin asian niin, että ohjelma kertoo, että tällaiset asetukset on sieltä löydetty, ja kysyy, ovatko ne korrektit. Jos Debian ei näin tee, se luultavasti (skannereita ja ko. tapausta sen enempää tuntematta) tekee sen sitten väärin.

Mutta onko se siis jotenkin olennaisesti _parempi_ kuin mainitsemani järjestelmät? Täytyy kokeilla, mutten usko siitä olennaisesti voitavan itseni kaltaiselle käyttäjälle parantaa.

Toki, mutta pitää muistaa, että suinkaan kaikki ongelmat eivät päädy sinne, ja että yksittäinen kämmi jossain asiassa, joka ei aiheuta remote roottia, ei ole välttämättä yhtä kriittinen kuin kymmenen remote roottia, vaikka se yksittäinen kämmi olisikin näennäisesti triviaali.

Kyllä OpenBSD:hen murtautuminen houkuttaisi monia juuri sen tarjoaman maineen vuoksi. Vaikka käyttäjäkunnan suhteen olet oikeilla suunnilla (ennemmin tosin tuo "moninkertainen" kuin "ei-juuri-ketään"), pitää muistaa, että sitä käytetään palvelimissa kuitenkin ihan kohtuullisesti, varsinkin korkeakouluissa. Ja jos murtautuminen kiinnostaisi, pääasiallinen päämääräni olisi kyllä palvelin, ei jonkun työasema tai kotikone. (Vaikka riittävän montaa sellaistakin välietappina voi pitää välttämättömänä.)

Viime aikojen esimerkkejä:
- KDE 2.2.2, SuSE, noin 3h (2.2.2-1 release)
- XF86 4.2.0, SuSE, -12h ennen virallista julkaisua
- GDB 5.1, ensimmäinen releasattu 5.1-17, kaksi päivää julkistuksen jlk
..

Sorsat on. Aja niille diffi jos kiinnostaa.

Ne löytyvät ihan suoraan valmistajien FTP saiteilta sitä mukaa kun tulevat.

Releasea ei pakiteta, vaan ne korjaukset löytyy sieltä GCC:n CVS puusta kyllä ihan nätisti. Tästä syystähän ne kaikilla niillä joita asiat kiinnostaa on täsmälleen samat..

Starttaapas gdb ja ala tehdä sillä release vermeellä jotain.. :)

Koska ne ovat yksiä ja samoja ihmisiä. Katos ylle.

Tutkippas mitä sieltä CVS:stä löytyy.

Toistaiseksi kaiken, mitä rikkinäinen versio ei tee. Eivätkä ne rikkinäisen version käännökset myöskään kääntyessäänkään toimi.

Niin siis samat openssh aukot siellä on kuin linukassakin. Not a big deal.

Ja nämä pitää kaivaa Suselta.

Sorsat voivat tai voivat olla olematta CVS:ssä eri ohjelmien kohdalla. diff ei ole mikään dokumentointityökalu.

Ja osa niitä on korjauksia sille omalle platformille, jotka korjaukset eivät toimi muualla, osa on distribuution vaatimia muutoksia, jotta softa toimisi kuten distribuutio sen haluaa toimivan, ja osa on sitten niitä "oikeita" korjauksia. Miksi ihmeessä pitää käydä kaikkien valmistajien FTP-saitit erikseen läpi, säännöllisesti? Ladata sadoista softista SRPM:t huomatakseen "ai, kas, tämähän onkin vain uudelleenkäännös kirjastoa X vasten". Miksi asioista pitää tehdä vaikeita? Miksi valmistajat haluavat sooloilla?

Tai sitten eivät. Kaikki eri valmistajien korjaukset eivät suinkaan löydy kovinkaan pian GCC:n CVS-puusta mm. jo siitä syystä, että se, että saat tehtyä paperit, joilla luovutat muutoksiesi tekijänoikeudet GNU:lle, voi kestää pahimmissa tapauksessa vuoden.

Toinen syy tälle on se, että GCC-tiimillä ei ole intressiä saattaa sellaisia korjauksia puuhun, jotka on tehty uudempaa kehitysversiota vasten, ja joiden tekeminen riliissiä vasten on siis työlästä. Valmistajilla voi olla.

Kriittisimpien patchien tarjoaminen pelkästään CVS:llä on sekin työlästä. Eivätkä GNU-projektit osaa käyttää CVS:ää oikein, vaan käyttävät Changelogia lokimerkintöihin, eivätkä tule ajatelleeksi että ehkä sen Changelogin voisi tehdä CVS:n omista lokeista.. Yksittäisen fileen yksittäisen muutosten annoteaminen on GNU-projekteissa usein mahdotonta.

En käytä säikeitä, kuten sanoin. Muita ongelmia sen kanssa ei ole ollut.

Voivat olla tai olla olematta. Tässä ei edelleenkään ole kysymys yhdestä tai kahdesta distribuutiosta. Sitä paitsi vastaus kysymykseen gcc-kehittäjille "mun gcc:ssä on tämmöinen ongelma" on varmasti aivan erilainen kuin vastaus samaan kysymykseen distribuution toimittajalle, jonka pitäisi tarjota kaupallista tukea, olivat vastaajat samoja ihmisiä tai eivät. Toinen kertoo, että voit hakea uusimman version täältä, ja toinen, että käyttämällä tätä päivitystyökalua saat korjauksen ongelmaasi - jos kertoo.

GNU:n CVS:ssä ei todellakaan ole kaikkien valmistajien muutoksia millään tageillä, jos on valmistajien muutoksia ollenkaan.

Ja julkaisutageista:

http://gcc.gnu.org/bugs.html#dontwant
http://gcc.gnu.org/ml/gcc/2001-03/msg01178.html

Eihän se välttämättä edes käänny itse, käynnisty, tai tee edes jaettuja kirjastoja.

Mitä nyt jokin käyttöjärjestelmä.

Etsi se remote-reikä vakioasennuksessa ja lähetä osoitteeseen <deraadt@openbsd.org> tai <bugtraq@securityfocus.com>. Siihen asti väitteesi ovat sisällyksettömiä. Aukon ja aukon välillä on ero.