Tällä kertaa pääsemme käsiksi kaikkein typerimpään suunnitteluvirheeseen, mitä GNU/Linux distrojen rakentelijat AINA toteuttavat: kyseessä on kaikkien ohjelmistokomponenttien sekoittaminen /usr:än alle.
Nykyäänhän on siis tapana, että aina kun softa johonkin distroon paketiksi käännetään, niin sen tiedostot staattisesti prefixataan ja asennetaan /usr -hierarkian alle SEKAISIN BASE-SYSTEM TIEDOSTOJEN KANSSA! Voi vittu mitä sekoilua.
Ohjelmistojen kääntäminen on todella vaikeaa tällaisessa ympäristössä! Ei ole olemassa minkäänlaista tiukkaa versionhallintaa base-systemin ulkopuolisten komponenttien suhteen, koska kaikki, siis IHAN KAIKKI, komponentit ovat samassa sekavassa sillisalaatissa /usr:än alla!
Esimerkki:
Oletetaan että meillä on GNU-autotools lähdekoodipaketti. Halutaan kääntää tämä GNU/Linux distrossa, missä on LSB 2.0 yhteensopiva base-system.
Kun softan lähdekoodi konfiguroidaan kääntöä varten, löytää kääntöympäristö /usr -hierarkian alta tarvittavat komponentit linkitystietoineen ... MUTTA näiden komponenttien ABI/API on TÄYSIN DISTRON PAKETINHALLINNAN ASENTAMIEN PAKETTIVERSIOIDEN ARMOILLA! Miten vitussa TE, arvon älypäät, pystyisitte tässä tapauksessa tekemään tiukkaa versionhallintaa libraryjen ja muiden komponenttien suhteen?
HUOM: MONISSA TAPAUKSISSA VOIDAAN HALUTA KÄÄNTÄÄ OHJELMA ESIM. VANHEMPAA LIBRARY VERSIOTA VARTEN. Tällaista versionhallintaa ei missään nykyajan surkeissa GNU/Linux distroissa ole.
Ratkaisuja:
Entäpä jos base-systemin (eli tässä tapauksessa LSB standardin) ulkopuoliset ohjelmistokomponentit olisivat vaikkapa erillään /usr/local:in alla (kuten BSD:issä)?
Tämä olisi PALJON PAREMPI RATKAISU!
Tiukka versionhallinta voitaisiin toteuttaa seuraavasti:
- bind-mountataan /proc, /dev, /usr/bin, /usr/lib, /usr/share, /home ja muutama muu jonnekkin kohtaan tiedostohierarkiaa esim. sijaintiin /tmp/chroot
- chroot /tmp/chroot
Tällöin uudessa chroot-ympäristössa olisi VAIN base-systemin tarjoamat palvelut ja base-systemin linkitettävät komponentit!
- tehdään vielä: mkdir /usr/local (sisällä chrootissa)
Nyt tuonne /tmp/chroot/usr/local sijaintiin ympäristön ulkopuolelta käännetään TASAN NE VERSIOT TARVITTAVISTA KOMPONENTEISTA, MINKÄ MUKAAN OHJELMAN HALUTAAN KÄÄNTYVÄN! Tarkka versionhallinta olisi tällöin mahdollista.
Itseasiassa tätä menetelmää käytetään monissa kaupallisissa Unixeissa, ja monissa ilmaisissakin. Tällöin base-systemin tarjoama ABI ja API pysyy erillään kolmannen osapuolen paskoista, ja homma on hallinnassa! Mutta mitä tehdään GNU/Linux skenessä? Paskotaan omille jaloilleen, eikä edes suostuta kuuntelemaan järkeä!
Häpeisivät jo, voi saatana miten naurettavaa pelleilyä!
Nykyäänhän on siis tapana, että aina kun softa johonkin distroon paketiksi käännetään, niin sen tiedostot staattisesti prefixataan ja asennetaan /usr -hierarkian alle SEKAISIN BASE-SYSTEM TIEDOSTOJEN KANSSA! Voi vittu mitä sekoilua.
Ohjelmistojen kääntäminen on todella vaikeaa tällaisessa ympäristössä! Ei ole olemassa minkäänlaista tiukkaa versionhallintaa base-systemin ulkopuolisten komponenttien suhteen, koska kaikki, siis IHAN KAIKKI, komponentit ovat samassa sekavassa sillisalaatissa /usr:än alla!
Esimerkki:
Oletetaan että meillä on GNU-autotools lähdekoodipaketti. Halutaan kääntää tämä GNU/Linux distrossa, missä on LSB 2.0 yhteensopiva base-system.
Kun softan lähdekoodi konfiguroidaan kääntöä varten, löytää kääntöympäristö /usr -hierarkian alta tarvittavat komponentit linkitystietoineen ... MUTTA näiden komponenttien ABI/API on TÄYSIN DISTRON PAKETINHALLINNAN ASENTAMIEN PAKETTIVERSIOIDEN ARMOILLA! Miten vitussa TE, arvon älypäät, pystyisitte tässä tapauksessa tekemään tiukkaa versionhallintaa libraryjen ja muiden komponenttien suhteen?
HUOM: MONISSA TAPAUKSISSA VOIDAAN HALUTA KÄÄNTÄÄ OHJELMA ESIM. VANHEMPAA LIBRARY VERSIOTA VARTEN. Tällaista versionhallintaa ei missään nykyajan surkeissa GNU/Linux distroissa ole.
Ratkaisuja:
Entäpä jos base-systemin (eli tässä tapauksessa LSB standardin) ulkopuoliset ohjelmistokomponentit olisivat vaikkapa erillään /usr/local:in alla (kuten BSD:issä)?
Tämä olisi PALJON PAREMPI RATKAISU!
Tiukka versionhallinta voitaisiin toteuttaa seuraavasti:
- bind-mountataan /proc, /dev, /usr/bin, /usr/lib, /usr/share, /home ja muutama muu jonnekkin kohtaan tiedostohierarkiaa esim. sijaintiin /tmp/chroot
- chroot /tmp/chroot
Tällöin uudessa chroot-ympäristössa olisi VAIN base-systemin tarjoamat palvelut ja base-systemin linkitettävät komponentit!
- tehdään vielä: mkdir /usr/local (sisällä chrootissa)
Nyt tuonne /tmp/chroot/usr/local sijaintiin ympäristön ulkopuolelta käännetään TASAN NE VERSIOT TARVITTAVISTA KOMPONENTEISTA, MINKÄ MUKAAN OHJELMAN HALUTAAN KÄÄNTYVÄN! Tarkka versionhallinta olisi tällöin mahdollista.
Itseasiassa tätä menetelmää käytetään monissa kaupallisissa Unixeissa, ja monissa ilmaisissakin. Tällöin base-systemin tarjoama ABI ja API pysyy erillään kolmannen osapuolen paskoista, ja homma on hallinnassa! Mutta mitä tehdään GNU/Linux skenessä? Paskotaan omille jaloilleen, eikä edes suostuta kuuntelemaan järkeä!
Häpeisivät jo, voi saatana miten naurettavaa pelleilyä!
Vastaukset 22
Vanhimmat
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
"Purpose:
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy."
Tuossa selkeästi sanotaan, että /usr -hierarkian alla on ohjelmistojen käyttämiä systeemispesifisiä peruskomponentteja. Tämä hierarkia TULEE OLLA SAMANTYYPPISTEN, FHS-YHTEENSOPIVIEN SYSTEEMIEN JAETTAVISSA, EIKÄ SINNE SAA NORMAALITAPAUKSISSA KIRJOITTAA!
Eli suomeksi: /usr -hierarkia MÄÄRITTELEE JÄRJESTELMÄN BASE-SYSTEMIN, PERUSAJOYMPÄRISTÖN, BINÄÄRISEN AJOYMPÄRISTÖN! Sellaisen standardin ja tärkeän perustan järjestelmälle, mitä GNU/Linux distroissa EI OLE!
Ja tuossa sanotaan vielä, että TÄYSIN KONEKOHTAINEN JA VAIHTUVA SISÄLTÖ PITÄÄ TALLENTAA MUUALLE (kuten vaikkapa /usr/local:in alle)! Tämähän käy järkeen: /usr:än alle EI SAA PISTÄÄ DISTRON BASE-SYSTEMIN ULKOPUOLISIA OHJELMIA, KOSKA ERI OHJELMIA ASENNETAAN JA POISTETAAN JATKUVASTI. /usr/local on tätä varten
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
Että niin. Nyt kyllä tungin pullan kurkkuunne, senkin arvottomat wannabe-hakkeri harrastelijapellet. Menkää kotiinne itkemään tietämättömyyttänne ;)
Moi, olen suuren ja tunnetun nimeltämainitsemattoman distron kehittäjä. Seuraan Suomi24:n atk-palstoja säännöllisesti saadakseni uusia ideoita.
Kritiikkisi ansiosta tulemme muuttamaan koko järjestelmän rakenteen.
jaa mandraken ?
eikös se pitänyt olla ranskalainen...
ja kuitenkin osaat suomea ?
Kritiikkisi on otettu huomioon. Muutamme distromme ranskalaiseksi.
C'est ca.
>Kritiikkisi ansiosta tulemme...
Vaihdoit siis sujuvasti nickiä kun kukaan ei oikein tunnu ajatuksiasi "ymmärtävän". :)
Älä ole milläsikään, tätä sattuu näillä palstoilla tuon tuostakin. Varsin yleisesti kuvitellaan että itselleen vastaamisella jotenkin uskottavuus lisääntyisi. Vaikutus vaan valitettavasti on päinvastainen. :(
ksymikin sentään ymmärtää ironian ja sarkasmin...
Onhan meillä Windows. Täydellinen käyttöjärjestelä. Käyttäkäämme sitä. Siinä ei ole puutteita eikä virheitä. Kaikki on oikealla paikallaan, jonne jumalainen Bill on sen määrännyt.
Ja lehmät lentää ...
Win32 alustassa on ABI:n kanssa ollut vastaavia ongelmia jo kauan. DCOM:in mukaiset DLL:ät osaa aika hyvin väistellä resurssiristiriitoja, mutta silti aika isoja .exe:jä tulee kun joutuu jokaiseen käyttämäänsä rajapintaa varten kääntämään .exe:n sisään staattiset stubit.
Näinhän tuo LSB:kin toimii: LIBC ja muutamat muut core toiminallisuudet staattisesti käännetään, ja standardin ulkopuoliset komponentit toimitetaan softan mukana, ja ladataan wrapperi-skriptillä tai sitten softa lataa ne itse dynaamisesti dlopen(2) käskyllä.
Niin, monet tutkivat, monet juttelevat tai mouhoavat ja harvat saavat muutoksia aikaiseksi.
Nyt kun syyttelet ja osoitat sormella, muista, että ainakin kolme sormea osoittaa takaisin.
Ei ole pitkä aika kun maineikas Linux-aktivisti kertoi teeveessä (jonka nimeä en nyt muista), että hän mielellään juttelee pitkiäkin hetkiä aiheesta, mutta harva lähettää jo tehtyä toteutusta hänelle tai yhteisölle.
Nyt kun olet useaan otteeseen todistanut Linuxin surkeuden, voisit varmasti kehittää ideostasi koodia/valmiimman toteutuksen ja lähettää ne/sen GPL-lisensin alaisuudessa GNU-järjestelmien tekijöille, vai mitä?
Odotamme jännityksellä ksym_in ihan omaa jakelua, jossa kaikki on niin kuin diktaattori itse haluaa.
Sinä päivänä laitevalmistajat ja pelitalot alkavat tukemaan linuxia.
?
;-D
...mutta tekijöistä on puutetta. Siihen kun tarvitaan oikeasti osaamista, pelkkä uho ei riitä.
Tähänkin pätee vanha sääntö: "Ensin pitää osata soittaa ennen kuin voi alkaa säveltämään."
> Nyt kun olet useaan otteeseen todistanut
> Linuxin surkeuden, voisit varmasti kehittää
> ideostasi koodia/valmiimman toteutuksen ja
> lähettää ne/sen GPL-lisensin alaisuudessa GNU-
> järjestelmien tekijöille, vai mitä?
Kokoajan tässä ollaan kehittelemässä LSB-yhteensopivaa runtime subsystemiä, joka mahdollistaisi täysin alustavapaan ohjelmistonlevityksen.
Hieman nuo opiskelut ovat tiellä (ja elämäähän minulla Ei Ole), mutta kehitystä on luvassa.
elämä on vaikeeta. Pikku vinkki: Älä käytä Linuxia. Pysy kiltisti sen freebsd:n kimpussa. Sulla on helpompaa ja meidän ei tarvitse kuunnella (lue: lukea) noita valituksiasi. Molemmilla asiat paremmin.
Jep, tuo näyttäisi kyllä olevan ikävä kompastuskivi linuks-jakeluissa. Itsekin meinaan tuota tuskaillut muutamaan otteeseen.
Eri mieltä sitten taasen olen tuosta, ettei pysty kääntämään jotain ohjelmaa käyttämään vanhempaa/uudempaa versiota kirjastosta. Ei ole kovinkaan vaikeaa käskyttää linkkeriä käyttämään sopivaa kirjastoversiota (-L ja -l -optiot gcc:ssä). Tuo on myös toteutettu ah, niin hienoihin autoconf/automake-työkaluihin.
Jos tuo olisi niin _suuri_ ongelma, sille olisi jo tehty jotain. Vai mitä?
> Ei ole kovinkaan vaikeaa käskyttää linkkeriä
> käyttämään sopivaa kirjastoversiota (-L ja -l
> -optiot gcc:ssä).
No tämä ei yksittäisessä kääntökomennossa vaikeaa olekkaan, mutta mutta ...
> Tuo on myös toteutettu ah, niin hienoihin
> autoconf/automake-työkaluihin.
Autoconf/automake kääntötyökaluissa ei ole tietääkseni mitään kontrollia siihen, että mitä versiota librarystä halutaan käyttää kokonaisuudessaan koko kääntöprosessin ajan.
Tämä on tietysti myös alla piilevän linkkeriarkkitehtuurin ongelma: vain harvat libraryt käyttävät versiosymboleja tuotetuissa binääreissä. Libtool:in käyttämä Current:Revision:Age tiedostonimipohjainen "versiointi" olisi ihan hyvin toimiva, mutta gnu-autotools purkat eivät tällä hetkellä anna minkäänlaista komentorivipohjaista työkalua millä käännettävän sorsapaketin asetuksiin voisi merkata että minkä se linkittää ja mistä.
TAI sitten en vain tiedä tarpeeksi. Mutta itse en ole näitä ominaisuuksia gnu/autotools systeemeissä huomannut.
> Jos tuo olisi niin _suuri_ ongelma, sille olisi
> jo tehty jotain. Vai mitä?
No siis otetaan nyt huomioon, että suurin osa GNU/Linuxia koodaavista "leet-haxoreista" on perusduuneissa käyviä wannabe-hakkereita, joilta puuttuu kokonaisuuden hahmottamisen ja visioinnin kyvyt lähes kokonaan. Kernelin tekijä Linus Torvalds on ihan fiksu, ainakin kommenttiensa perusteella, mutta muista GNU/Linux skenessä pyörivistä järjestelmänsuunnittelijoista en voi samaa sanoa.
Tai siis yleensäkkin koko GNU/Linux haxxor skenessä on vikana se, että koodia kasataan kauheeta vauhtia, mutta koskaan ei katsella tarpeeksi taaksepäin tai välitetä virheistä.
Perfektionismi olisi ihan tervettä järjestelmää suunnitellessa. Kun kerralla jotain tekee, niin tekisi suoraan hyviä järjestelmäratkaisuja. GNU/Linuxeissa vaan tunnutaan vetävän mutkat suoriksi (kuten esim. tämä /usr:än spämmääminen sinne kuulumattomalla tavaralla VAIN SIKSI että gnu-autotoolsit osaa ilman erillistä käännösympäristöä kääntää uusia paketteja) ja mennään siitä mistä aita on matalin. Pienet mokat kasautuvat isoksi ennenmittaa kasaksi paskaa ...
En itse ole mikään huippuosaaja UNIX ohjelmoinnissa, VIELÄ. Enkä ole mikään super-älykäs ... mutta olen tarpeaksi älykäs huomatakseni, että jotain on vinossa näissä nykyajan GNU/Linux kehitysmalleissa jos esim. OpenSusen ns. "SuSe compliance build environment" tarvitsee 3 gigatavua kovotilaa ;D
> Ei ole kovinkaan vaikeaa käskyttää linkkeriä
> käyttämään sopivaa kirjastoversiota (-L ja -l
> -optiot gcc:ssä).
No tämä ei yksittäisessä kääntökomennossa vaikeaa olekkaan, mutta mutta ...
> Tuo on myös toteutettu ah, niin hienoihin
> autoconf/automake-työkaluihin.
Autoconf/automake kääntötyökaluissa ei ole tietääkseni mitään kontrollia siihen, että mitä versiota librarystä halutaan käyttää kokonaisuudessaan koko kääntöprosessin ajan.
Tämä on tietysti myös alla piilevän linkkeriarkkitehtuurin ongelma: vain harvat libraryt käyttävät versiosymboleja tuotetuissa binääreissä. Libtool:in käyttämä Current:Revision:Age tiedostonimipohjainen "versiointi" olisi ihan hyvin toimiva, mutta gnu-autotools purkat eivät tällä hetkellä anna minkäänlaista komentorivipohjaista työkalua millä käännettävän sorsapaketin asetuksiin voisi merkata että minkä se linkittää ja mistä.
TAI sitten en vain tiedä tarpeeksi. Mutta itse en ole näitä ominaisuuksia gnu/autotools systeemeissä huomannut.
> Jos tuo olisi niin _suuri_ ongelma, sille olisi
> jo tehty jotain. Vai mitä?
No siis otetaan nyt huomioon, että suurin osa GNU/Linuxia koodaavista "leet-haxoreista" on perusduuneissa käyviä wannabe-hakkereita, joilta puuttuu kokonaisuuden hahmottamisen ja visioinnin kyvyt lähes kokonaan. Kernelin tekijä Linus Torvalds on ihan fiksu, ainakin kommenttiensa perusteella, mutta muista GNU/Linux skenessä pyörivistä järjestelmänsuunnittelijoista en voi samaa sanoa.
Tai siis yleensäkkin koko GNU/Linux haxxor skenessä on vikana se, että koodia kasataan kauheeta vauhtia, mutta koskaan ei katsella tarpeeksi taaksepäin tai välitetä virheistä.
Perfektionismi olisi ihan tervettä järjestelmää suunnitellessa. Kun kerralla jotain tekee, niin tekisi suoraan hyviä järjestelmäratkaisuja. GNU/Linuxeissa vaan tunnutaan vetävän mutkat suoriksi (kuten esim. tämä /usr:än spämmääminen sinne kuulumattomalla tavaralla VAIN SIKSI että gnu-autotoolsit osaa ilman erillistä käännösympäristöä kääntää uusia paketteja) ja mennään siitä mistä aita on matalin. Pienet mokat kasautuvat isoksi ennenmittaa kasaksi paskaa ...
En itse ole mikään huippuosaaja UNIX ohjelmoinnissa, VIELÄ. Enkä ole mikään super-älykäs ... mutta olen tarpeaksi älykäs huomatakseni, että jotain on vinossa näissä nykyajan GNU/Linux kehitysmalleissa jos esim. OpenSusen ns. "SuSe compliance build environment" tarvitsee 3 gigatavua kovotilaa ;D
> Ei ole kovinkaan vaikeaa käskyttää linkkeriä
> käyttämään sopivaa kirjastoversiota (-L ja -l
> -optiot gcc:ssä).
No tämä ei yksittäisessä kääntökomennossa vaikeaa olekkaan, mutta mutta ...
> Tuo on myös toteutettu ah, niin hienoihin
> autoconf/automake-työkaluihin.
Autoconf/automake kääntötyökaluissa ei ole tietääkseni mitään kontrollia siihen, että mitä versiota librarystä halutaan käyttää kokonaisuudessaan koko kääntöprosessin ajan.
Tämä on tietysti myös alla piilevän linkkeriarkkitehtuurin ongelma: vain harvat libraryt käyttävät versiosymboleja tuotetuissa binääreissä. Libtool:in käyttämä Current:Revision:Age tiedostonimipohjainen "versiointi" olisi ihan hyvin toimiva, mutta gnu-autotools purkat eivät tällä hetkellä anna minkäänlaista komentorivipohjaista työkalua millä käännettävän sorsapaketin asetuksiin voisi merkata että minkä se linkittää ja mistä.
TAI sitten en vain tiedä tarpeeksi. Mutta itse en ole näitä ominaisuuksia gnu/autotools systeemeissä huomannut.
> Jos tuo olisi niin _suuri_ ongelma, sille olisi
> jo tehty jotain. Vai mitä?
No siis otetaan nyt huomioon, että suurin osa GNU/Linuxia koodaavista "leet-haxoreista" on perusduuneissa käyviä wannabe-hakkereita, joilta puuttuu kokonaisuuden hahmottamisen ja visioinnin kyvyt lähes kokonaan. Kernelin tekijä Linus Torvalds on ihan fiksu, ainakin kommenttiensa perusteella, mutta muista GNU/Linux skenessä pyörivistä järjestelmänsuunnittelijoista en voi samaa sanoa.
Tai siis yleensäkkin koko GNU/Linux haxxor skenessä on vikana se, että koodia kasataan kauheeta vauhtia, mutta koskaan ei katsella tarpeeksi taaksepäin tai välitetä virheistä.
Perfektionismi olisi ihan tervettä järjestelmää suunnitellessa. Kun kerralla jotain tekee, niin tekisi suoraan hyviä järjestelmäratkaisuja. GNU/Linuxeissa vaan tunnutaan vetävän mutkat suoriksi (kuten esim. tämä /usr:än spämmääminen sinne kuulumattomalla tavaralla VAIN SIKSI että gnu-autotoolsit osaa ilman erillistä käännösympäristöä kääntää uusia paketteja) ja mennään siitä mistä aita on matalin. Pienet mokat kasautuvat isoksi ennenmittaa kasaksi paskaa ...
En itse ole mikään huippuosaaja UNIX ohjelmoinnissa, VIELÄ. Enkä ole mikään super-älykäs ... mutta olen tarpeaksi älykäs huomatakseni, että jotain on vinossa näissä nykyajan GNU/Linux kehitysmalleissa jos esim. OpenSusen ns. "SuSe compliance build environment" tarvitsee 3 gigatavua kovotilaa ;D
JA MIKSI VITUSSA TUO VITUN SUOMI24 FOORUMISOFTA PISTI VIESTINI 3:EEN KERTAAN TUOHON?????
AARGH!
>FOORUMISOFTA PISTI VIESTINI 3:EEN KERTAAN TUOHON?????
Jep jep. Pisti vielä ihan luettavat eri otsikot niihin. On se viisas vehje kun joku wannabehaxori postailee. :)
> Autoconf/automake kääntötyökaluissa ei ole
> tietääkseni mitään kontrollia siihen, että mitä
> versiota librarystä halutaan käyttää
> kokonaisuudessaan koko kääntöprosessin ajan.
Noissa yleensä kyllä on mahdollisuus käskyttää, mistä oikea kirjasto löytyy vrt. --with-feature=
Toinen tapa on käyttää LDFLAGS-ympäristömuuttujaa (ja myös LIBS).
Kertaakaan ei ole (vielä) tullut vastaan tilanne, jossa jotain autoconf:lla tehtyä ohjelmaa ei olisi saanut asentumaan. Tosin kokemusta on lähinnä ei-linuks ympäristöistä ;)
> No siis otetaan nyt huomioon, että suurin osa
> GNU/Linuxia koodaavista "leet-haxoreista" on
> perusduuneissa käyviä wannabe-hakkereita, joilta
> puuttuu kokonaisuuden hahmottamisen ja visioinnin
> kyvyt lähes kokonaan.
Jep, mutta täytyy muistaa, että pelissä on myös kaupallisia yrityksiä (IBM, RedHat, ...). Jos
asia siellä häiritsisi niin siihen puututtaisiin. Ja nuo tyypit saavat palkkaa tosta.
Mutta en rupea enempää puolustelemaan kun ei ole kokemusta niin paljon linuks-puolesta.
> Noissa yleensä kyllä on mahdollisuus käskyttää,
> mistä oikea kirjasto löytyy vrt. --with-feature=
Tuo on kyllä totta.
Mutta silti siirtymiskynnys jollekkin Win32 koodarille on helvetin suuri, koska itse joutuu huolehtimaan softan käännösvaiheessa oikeasta linkityksestä.
Olen kehittelemässä jonkinlaista suljettua käännösympäristöä, millä olisi mahdollista eristää LSB-standardin ulkopuoliset komponentit käännösaikana, jolloin sitten voi erikseen päättää mitä käännetään ja minkä versioisina.
> Kertaakaan ei ole (vielä) tullut vastaan
> tilanne, jossa jotain autoconf:lla tehtyä
> ohjelmaa ei olisi saanut asentumaan.
> Tosin kokemusta on lähinnä ei-linuks
> ympäristöistä ;)
Linuxissa tosiaan spämmätään /usr:ää täysin sinne kuulumattomalla tavaralla, että saadaan jokainen autotools-paketit kääntymään "suoralta kädeltä", ja että pakettien tekijöiden ei tarvitsisi määritellä tarkkaa porttaus standardia (kuten esim. FreeBSD:ssä), vaan pakettien tekijät saa kääntää softansa miten haluavat ...
Leväperäisyys on perseestä. Erityisesti jos käyttöjärjestelmistä puhutaan ;)
Tällainen tapahan meinaa sitä, että käännettyjen softien ABI synkataan tietyn järjestelmän buildin kanssa. Ei sikäli huono juttu ... MUTTA kun jokainen GNU/Linux kehittää systeeminsä ABI:a täysin toisistaan riippumatta, niin homma kusee tosi lahjakkaasti.
> Jep, mutta täytyy muistaa, että pelissä on myös
> kaupallisia yrityksiä (IBM, RedHat, ...). Jos
> asia siellä häiritsisi niin siihen
> puututtaisiin. Ja nuo tyypit saavat palkkaa
> tosta.
Eivät nuo oikeasti GNU/Linuxia koskaan ole halunneetkaan käyttää mihinkään TODELLISEEN. GNU/Linux systeemit on kaupallisille tahoille vain kiinnostavia "leluja", joiden avulla voidaan pyöritellä PR-maailmaa ;D
- IBM kauppaa Linuxia saadakseen omat WebSphere sovelluksensa kaupaksi, myyvät monesti vielä erikseen s390/x rautaa omalla X/OS käyttiksellään kylkiäisiksi.
- Novell haluaa vain PR:ää
lupailemalla Netware-servereiksi Linuxeja, mutta mitään ei ole vielä saatu aikaiseksi. Anyway, Novell on kohtapuoliin kuollut ...
- RedHat on kyllä poikkeus. Pärjää kohtuullisesti serverimarkkinoilla. Mutta heidän Desktop -tuotteensa vajoavat paskaan jo pelkästään sen myötä, ettei GNU/Linuxeille voi ostaa softaa suoraan kaupan hyllyltä (olemattoman ABI:n takia)
Että näin. Olen kyyninen, mutta sehän on vain hyvä piirre.
Käytän muuten pääasiassa Debiania =)
miten configure toimii, niin säästyisit itkuilta.