Linux-kysymyksiä & yleistä keskustelua Linuxista

Tässä joku aika sitten tuli hyvä esimerkki kun koitin tutustua arch linuxiin ja koitin tietenkin asentaa virallisen ohjeen perusteella. Tuossa oli joku kohta mikä ei mennytkään enää ohjeen mukaan Tätä kun googlailin niin valitettavan usein siellä oli liuta vastauksia "read the official installation instructions" tai parhaassa tapauksessa pelkkä linkki niihin vaikka aloittaja selvästi kertoi viestissään että tätä kohtaa ohjeistuksessa ei ole.

Tämä on myös yksi koko opensource maailman ongelma. Dokumentaatio, jos sitä edes on, ei usein ole ajan tasalla. Sitten kun joutuu googlettelemaan niin kyllähän netistä löytyy valtavasti aina aikaisempia kyselyitä ja keskusteluja, mutta ainakin itse olen huomannut sen että oikeastaan paria vuotta vanhempia ohjeistuksia on ikävä koittaa kokeilla kun monesti tuntuu että joku on muutettu ja homma tökkää sitten siihen että olet puolittain räpeltänyt jotain joka voi sitten myöhemmin taas estää jotain muuta.
Ihan samanlaisia ongelmia kyllä löytyy windowsinkin puolelta, homma ei vaan toimi vaikka on orjallisesti noudattanut asennusohjetta. Erään suuren laitevalmistajan konfigurointiohjelma vaan ei suostu toimimaan kaikissa tuettujen listassa olevien windowsien kanssa suoraan ja tekninen tukikin vaan jankkaa "Onhan sinulla tuettu Win-versio? Olethan asentanut asennusohjeen mukaan?". Ja todellisuudessa kun aikansa kaiveli, syynä oli puuttuva dll-kirjasto jota ei asennuspaketissa ollut mukana eikä missään ollut mitään mainintaa asiasta.

Vastaavia juttuja on tullut vastaan muistakin win-softista, varsinkin jos käsketään muuttamaan jotain windowsin asetusta niin yllättäen sitä asetusta ei löydykään sieltä mistä asennusohjeen mukaan pitäisi löytyä kun windowsissakin on asiat siirtyneet eri paikkaan jopa saman major-version sisällä.

Toki osassa linux-softiakin dokumentaatio on aika ohkaista mutta yleensä vian jäljille sentään pääsee jos vähän osaa esim järjestelmän lokeja lueskella, windowsissa kun ei yleensä niistä lokeistakaan löydä mitään järkevää. Se on kyllä totta että eri linuxeissa on asiat vähän eri paikoissa ja eri tavalla, joten jos ei ihan mainstream-linux-jakeluita käytä niin ongelman tullessa vastaan sen selvittely ei välttämättä ole ihan helppoa, ainakaan vähän kokemattomammalle käyttäjälle.

Valitettavasti joissakin piireissä asenne on vähän ilkeää aloitteleville käyttäjille ja vastaukset ovat "RTFM" -tasoa mutta tuo on tässä vuosien varrella vähentynyt malkoisen paljon. Noissakin jutuissa Ubuntu/Fedora sun muissa suuremmalla yleisölle tarkoitetuissa jakeluissa tuntuu asenne olevan "asiakaspalvelussa" parempi, ei ihan heti lytätä kysyjää maanrakoon.
 
Noissakin jutuissa Ubuntu/Fedora sun muissa suuremmalla yleisölle tarkoitetuissa jakeluissa tuntuu asenne olevan "asiakaspalvelussa" parempi, ei ihan heti lytätä kysyjää maanrakoon.

Debianilla ja Ubuntulla voisi sanoa olevan kummallakin aito online-manuaali, siinä missä Archilla ja johdannaisilla on käytännössä pelkkä wiki. Jälkimmäisestä löytyy kyllä vastaus moneen kysymykseen, mutta vastuu tiedon omaksumisesta ja etsimisestä jää käyttäjälle. Linux-aloittelijalle wiki ei välttämättä ole se paras neuvonantaja koska käsi kaipaisi vielä pitelyä.
 
Jaa millä tavalla? Saisiko jotain konkreettisia esimerkkejä miten esim Fedoraa käyttävä on jatkossa maksava asiakas?
No siis, koska Ubuntu on Debian:in maksullinen versio ja Fedora:n pro-käyttäjien on tarkoitus maksaa lopulta RHEL:ista, koska heillä ei ole aikaa community version bugihallintaan yms. Luultavasti melko harva ammattikäyttäjä käyttää lopulta community versioita, jotka ovat paremmin soveltuvia kotikäyttäjille yms. epäviralliseen. Kaupalliselle yritykselle ei yleensä ole paha rasti maksaa siitä, että joku muu manageroi ohjelmistoja, koska järjestelmän downtime yms. maksaa rahaa.
 
Viimeksi muokattu:
No siis, koska Ubuntu on Debian:in maksullinen versio ja Fedora:n pro-käyttäjien on tarkoitus maksaa lopulta RHEL:ista, koska heillä ei ole aikaa community version bugihallintaan yms. Luultavasti melko harva ammattikäyttäjä käyttää lopulta community versioita, jotka ovat paremmin soveltuvia kotikäyttäjille yms. epäviralliseen. Kaupalliselle yritykselle ei yleensä ole paha rasti maksaa siitä, että joku muu manageroi ohjelmistoja, koska järjestelmän downtime yms. maksaa rahaa.
No on aika kapea kuva kyllä.

Ensinnäkään Ubuntu ei ole Debianin "maksullinen versio". Sellaista ei ole olemassa. Ja miksi debiania käyttävä siirtyisi käyttämään Ubuntua? Tai että maksaisi tästä "canonicalin tuesta" (mitä se ubuntu pro nykyisin maksaakaan). Sama fedoran osalta, jos desktop käyttäjä käyttää fedoraa niin en kyllä näe todellisena skenaariona että yhtäkkiä päätettäisiin siirtyä käyttämään maksullista RHEL:iä.

Mutta sä taidat asiaa katsella jostain kapeasta serverinäkökulmasta tai korporaatiopuolelta jossa näin voikin olla. Mutta desktop käytössä, saati pelikäytössä (josta tämäkin keskustelu taas lähti) niin ei.
 
Vastaavia juttuja on tullut vastaan muistakin win-softista, varsinkin jos käsketään muuttamaan jotain windowsin asetusta niin yllättäen sitä asetusta ei löydykään sieltä mistä asennusohjeen mukaan pitäisi löytyä kun windowsissakin on asiat siirtyneet eri paikkaan jopa saman major-version sisällä.
Jokin aika sitten boottasin läppärin windowsiin enkä osannutkaan enää kirjautua ulos. Sign out oli jostain syystä pitänyt siirtää jonnekin tree dot menun taakse piiloon, on kai niin advanced toiminto. Olohuoneen pöytäkoneella se näyttää tällä hetkellä olevan ihan suoraan näkyvissä, onko se sitten välillä piilotettu ja tuotu taas takaisin..?

Se on kyllä poikkeus jos jokin netistä löytynyt ohje windowsin asetusten muokkaamiseen on enää ajan tasalla.
 
Linux ei myöskään ole käyttöjärjestelmissä erityisen ansiokas tai teknisesti paras, mutta se on monesti "good enough" käytäntöön.

Pro-käyttäjä voisi haluta L4-mikrokernelin yms., mutta useimmille ihmisille ne eivät tuota suurta eroa.

Itseä kyllä ärsyttää, että koko Debian jäätyy, jos jokin ohjelma, kuten FreeCAD tai Code kaatuu.
 
Eikös tuo Fedora ole vähän sellainen beta testipenkki RHEL:ille. Tai näin olen jotenkin ymmärtänyt.

Ja mitä työpöytäkäyttöön tulee, niin mikähän lie Linuxin osuus työpöytäkäytössä yrityspuolella?
 
Fedorahan on Red Hatin testialusta. Eli ei sieltä käyttäjät siirry RHEL:iin, mutta koodi siirtyy. Samalla tavalla OpenSuse on Susen testipenkki. Ubuntu sitten poikkeaa vähän linjasta, sillä Ubuntu on Canonicalin päätuote.

Debianilla ja Ubuntulla voisi sanoa olevan kummallakin aito online-manuaali, siinä missä Archilla ja johdannaisilla on käytännössä pelkkä wiki. Jälkimmäisestä löytyy kyllä vastaus moneen kysymykseen, mutta vastuu tiedon omaksumisesta ja etsimisestä jää käyttäjälle. Linux-aloittelijalle wiki ei välttämättä ole se paras neuvonantaja koska käsi kaipaisi vielä pitelyä.
Tässä on se ero, että Archin taustalla ei ole korporaatiota, kuten Ubuntulla, Fedoralla ja OpenSusella. Wiki sopii oikein mainiosti sen kehitysmalliin.
Debian on toki myös yhteisö-distro, mutta Debian onkin vanhempi keksintö kuin wikit.
 
Itseä kyllä ärsyttää, että koko Debian jäätyy, jos jokin ohjelma, kuten FreeCAD tai Code kaatuu.
Tuskin se koko Debian jäätyy, eiköhän se ole vain työpöytäympäristö. Jos haluat ratkaisuehdotuksia, niin kerro toki mitä Debiania ja työpöytäympäristöä siinä ajat, niin on jotain mihin tarttua.
 
Linux ei myöskään ole käyttöjärjestelmissä erityisen ansiokas tai teknisesti paras, mutta se on monesti "good enough" käytäntöön.

Pro-käyttäjä voisi haluta L4-mikrokernelin yms., mutta useimmille ihmisille ne eivät tuota suurta eroa.

Itseä kyllä ärsyttää, että koko Debian jäätyy, jos jokin ohjelma, kuten FreeCAD tai Code kaatuu.
Mikrokernelit oli yleinen puheenaihe joskus 20 vuotta sitten, vieläkö niistä jauhetaan?
 
Tuskin se koko Debian jäätyy, eiköhän se ole vain työpöytäympäristö. Jos haluat ratkaisuehdotuksia, niin kerro toki mitä Debiania ja työpöytäympäristöä siinä ajat, niin on jotain mihin tarttua.
No edes näppäimistön valot eivät enää toimi tuolloin. Debian 12 ja KDE Plasma.
Mikrokernelit oli yleinen puheenaihe joskus 20 vuotta sitten, vieläkö niistä jauhetaan?

Mutta yleinen käsitys vaikuttaa olevan, että Hurd kehittyy erittäin hitaasti ja useimmille käyttäjille sen edut eivät ole kehitysvaivan arvoisia. Tuo arkkitehtuuriongelma näkyi mm. myös Firefox:issa, joka vaihtui multi-process -malliin.
 
No edes näppäimistön valot eivät enää toimi tuolloin. Debian 12 ja KDE Plasma.
No sitten kuulostaa aika tiukalta jumilta. Saako ctrl+alt+f4:llä tty:n auki, että pääsisi lukemaan logeja? Jos ei, niin veikkaan jotain ajuriongelmaa. Varsinkin jos on uudempaa rautaa, niin Debianin kerneli saattaa vain olla liian vanha.
 
No sitten kuulostaa aika tiukalta jumilta. Saako ctrl+alt+f4:llä tty:n auki, että pääsisi lukemaan logeja? Jos ei, niin veikkaan jotain ajuriongelmaa. Varsinkin jos on uudempaa rautaa, niin Debianin kerneli saattaa vain olla liian vanha.
Vai kone liian vanha? Yleensä mikään näppäimistössä ei toimi tuolloin. Tuulettimet vaan huutaa. Se, että se kaatuu juuri Code:ssa ja FreeCAD:issa voisi viitata näytönohjainajureihin.
 
Vai kone liian vanha? Yleensä mikään näppäimistössä ei toimi tuolloin. Tuulettimet vaan huutaa.
Yleensä vanha rauta on paremmin tuettu, mutta joltain rautayhteensopivuusbugilta tuo minusta kuulostaa. Näitä joskus osuu kohdalle ja vaatii logien lueskelua, että saa vinkkiä miten korjata. Tai sitten vaan vaihtaa eri distroon. Kun konfiguraatio on eri, niin ongelma ei välttämättä tule esiin.
 
Eikai sitä tarvitse ymmärtää, käyttää sitä mitä itse haluaa.

Vähän sama kuin "mihin omassa käytössäni tarvitsen debiania kun saan kaiken parempana Fedoralla tai Archilla"
 
Vai kone liian vanha? Yleensä mikään näppäimistössä ei toimi tuolloin. Tuulettimet vaan huutaa. Se, että se kaatuu juuri Code:ssa ja FreeCAD:issa voisi viitata näytönohjainajureihin.
Oletko varma, ettei muisti lopu? Mulla käy joskus niin, että joku ohjelma "vähitellen" ottaa kaiken muistin käyttöön, jonka jälkeen mikään ei toimi (eli ei voi esim. ssh:lla ottaa yhteyttä kyseiseen koneeseen, eikä Ctrl+Alt+F4 jne. toimi). Jos ei halua väkisin bootata konetta, niin jonkin ajan kuluttua tilanne todennäköisesti korjaantuu ja out-of-memory-tilanne on näkyvissä esim. dmesg:ssa, mutta tähän tilanteen korjaantumiseen voi pahimmillaan kulua tunteja.

Olen huomannut, että jos muistin loppuminen on "selvempää" siten, että yrittää vaikka allokoida muistia kymmenkertaisen määrän koneen muistiin nähden, niin yleensä silloin ohjelma sammuu saman tien ja koneen käyttöä voi jatkaa normaalisti.

edit: Havainnot perustuvat ainakin Ubuntun versioihin 16.04-20.04. Muistaakseni uudemmillakin olen havainnut samaa, mutta en ole ihan varma.
 
Eikai sitä tarvitse ymmärtää, käyttää sitä mitä itse haluaa.

Vähän sama kuin "mihin omassa käytössäni tarvitsen debiania kun saan kaiken parempana Fedoralla tai Archilla"
No koska distrot kilpailevat. Mielestäni Arch epäonnistuu kuitenkin arkki-maalissaan, koska Arch on liian epävakaa ja liian barebones. Sillä voi tehdä custom-palvelimia, mutta se on harvinainen käyttötapaus. Joidenkin mielestä RR on tuotantoympäristöihin turha.
 
Viimeksi muokattu:
No miksi sitten esimierkiksi pelikäyttöön tupataan tuota arch linuxia suosittelemaan ja toisaalta näitä yleisiä distroja ei siihen suositella? Nykypäivänä pelaamisen kun ei pitäisi olla mitenkään erikosita käyttöä.
Itse ainakin suositelen Arch pohjaisia mutta en puhdasta Achia. Noissa johdannaisissa on monesti eroja puhtaaseen Archiin. Jos asentaa CachyOSin tai EndavourOSin niin kannattaa ensin katsoa niiden omat wikit ja ohjeet kun jotain pitää säätää tai johonkin apua tarvii. Lisäksi niiden omat yhteisöt on myös paljon ystävällisempiä aloittelijoille ja endavourilla on jopa suomenkielinen osio forumilla.

Cachyssä on monia täysin omia juttuja joita ei voi arch wikistä löytää ja ne olisi hyvä tietää. Näistä esimerkkinä oma perfomance mode peleille ja perinteisesti käytettyä gamemodea ei suositella edes käytettävän.

P.S. kieliosiot näköjään poistettu endavour forumilta. Tervehdys!
 
Viimeksi muokattu:
koska Arch on liian epävakaa ja liian barebones
Suurimman osan Archin epävakaudesta saa suoraan jo pois kun ei asenna sitä Grub:lla vaan vaikka systemd-boot:lla. Grub on ainakin archin osalta "low-maintenance" eikä sitä juuri suositella käytettäväksi. Tietysti vanhalla raudalla joka ei UEFI tue tuo on tietysti ainoa vaihtoehto, mutta sille löytyy AUR:sta muutama pikkusovellus jotka helpottaa tuon kanssa elämistä ja mahdollisia päivityksiä.

Barebones taasen on hyvä juttu, ja nykyisin ISOssa tulee mukana archinstall jolla saa erittäin helposti graafisen ympäristöön tarvittavat asiat valmiiksi heti ekalla bootilla. Ja sitten jos haluaa tarkempaa syynäystä niin saat asennettua juurikin vain ne paketit (+ dependecyt) mitä itse haluat.
 
No koska distrot kilpailevat. Mielestäni Arch epäonnistuu kuitenkin arkki-maalissaan, koska Arch on liian epävakaa ja liian barebones. Sillä voi tehdä custom-palvelimia, mutta se on harvinainen käyttötapaus. Joidenkin mielestä RR on tuotantoympäristöihin turha.
Useamman vuoden Archia käyttäneenä en ole kyllä minkäänlaista epävakautta huomannut. Ainoa mikä on rikkonut bootin on juurikin kys. GRUB ja sitä valitettavasti käyttää edelleen useimmat distrot. Se vaihtui kyllä nopeasti systemd-bootiin ja nykyään suoraan EFIstub käytössä, mitä sitä turhia pitää bootloaderia välissä kun UEFI hoitaa. Barebones on tässä vaiheessa jo hyvä asia kun tietää mitä haluaa niin jää kaikki ylimääräinen pois, aloittelijalle toki huono.
Barebones taasen on hyvä juttu, ja nykyisin ISOssa tulee mukana archinstall jolla saa erittäin helposti graafisen ympäristöön tarvittavat asiat valmiiksi heti ekalla bootilla. Ja sitten jos haluaa tarkempaa syynäystä niin saat asennettua juurikin vain ne paketit (+ dependecyt) mitä itse haluat.
Juuri näistä syistä käytän nykyään Archia, aikasemmin Manjaroa ja EndeavourOS käyttäneen. Nykyään archinstall antaa jo asennusvaiheessa laittaa bootloaderin sijaan EFIstub ja tekee UEFI:in boot valikon määrityksen valmiiksi niin sitäkään ei tarvi efibootmgr:llä itse tehdä. Myös UKI vaihtoehto löytyy archinstallista niin saa splash screeninkin ilman että tarvii itse muuta tehdä kuin käydä muokkaamassa /etc/kernel/cmdline quiet bgrt_disable niin splash myös pysyy. Sitten jos haluaa secureboot niin on valmiiksi jo UKI jonka voi signata sbctl. On se archinstall tullut huimasti eteenpäin.
 
Siis Archin epävakaus on, että yksikin väärä paketti tai versio voi rikkoa koko asennuksen, ja kun RR:ssa tulee uusimpia versioita vähemmän testattuna.
 
Siis Archin epävakaus on, että yksikin väärä paketti tai versio voi rikkoa koko asennuksen, ja kun RR:ssa tulee uusimpia versioita vähemmän testattuna.
Ja näitä kun ei tapahdu juurikaan, ellei satu bootloaderina olemaan GRUB. Suurin osa näistä on vaan jäänyt kummittelemaan sieltä alkuajoista.

Tärkeämmät paketit viettävät kuitenkin useamman päivän testing puolella joten kernel tms ongelmat kyllä jäävät nykyisin kiinni.
 
Tämä threadi on näemmä jäänyt unholaan:
 
Ja näitä kun ei tapahdu juurikaan, ellei satu bootloaderina olemaan GRUB. Suurin osa näistä on vaan jäänyt kummittelemaan sieltä alkuajoista.

Tärkeämmät paketit viettävät kuitenkin useamman päivän testing puolella joten kernel tms ongelmat kyllä jäävät nykyisin kiinni.
Tuossa tapauksessa archista voisi olla muuhunkin. Monesti sanotaan kuitenkin, että RR ei voi olla vakaa, ellei kyseessä ole installaatio, jota ei päivitetä. Debianissa ollen Unstable en näe kuitenkaan suurta syytä käyttää muita.

Ajattelin itselleni myös Arch:in tilalle FreeBSD:iä, jossa on oikeasti jotain etuja, mutta lopulta ainakin Debian 12:sta jälkeen olen ollut sitä mieltä, että Debian:issa on itseasiassa kaikki variantit. FreeBSD:iä voisi edelleen käyttää johonkin Jails:attuihin erikoispalvelimiin, mutta monessa jutussa en koe, että se oikeastaan tuokaan lisää Debianiin, vaikka se onkin paremmin koodattu.

Itseasiassa mielestäni elämme aikoja, jolloin kernelien sijaan tulisi keskittyä sovellusten ohjelmointiin. Joku Vulkan on poikkeus.

Tosiaan, Linuxin huonoin puoli on ohjelmistojen puute.
 
Viimeksi muokattu:
Oletko varma, ettei muisti lopu? Mulla käy joskus niin, että joku ohjelma "vähitellen" ottaa kaiken muistin käyttöön, jonka jälkeen mikään ei toimi (eli ei voi esim. ssh:lla ottaa yhteyttä kyseiseen koneeseen, eikä Ctrl+Alt+F4 jne. toimi). Jos ei halua väkisin bootata konetta, niin jonkin ajan kuluttua tilanne todennäköisesti korjaantuu ja out-of-memory-tilanne on näkyvissä esim. dmesg:ssa, mutta tähän tilanteen korjaantumiseen voi pahimmillaan kulua tunteja.

Olen huomannut, että jos muistin loppuminen on "selvempää" siten, että yrittää vaikka allokoida muistia kymmenkertaisen määrän koneen muistiin nähden, niin yleensä silloin ohjelma sammuu saman tien ja koneen käyttöä voi jatkaa normaalisti.

edit: Havainnot perustuvat ainakin Ubuntun versioihin 16.04-20.04. Muistaakseni uudemmillakin olen havainnut samaa, mutta en ole ihan varma.
Tätä varten voi asentaa OOM-killerin, esim. systemd-oom:n ja muitakin vaihtoehtoja on. Ne tappaa jollakin algoritmilla ohjelman tai ohjelmia, jotta ei aloiteta swappaamaan.
 
Itseasiassa mielestäni elämme aikoja, jolloin kernelien sijaan tulisi keskittyä sovellusten ohjelmointiin. Joku Vulkan on poikkeus.

Tosiaan, Linuxin huonoin puoli on ohjelmistojen puute.
Jos käyttää jotain tällä hetkellä 5 vuotta vanhaa rautaa, niin ehkäpä näin voi ajatella. Vaan kun Kernelin kehityksestä valtaosa liittyy rautatukeen, niin ei sitä työtä voi lopettaa. Muuten ei kohta oo rautaa millä ajella niitä ohjelmistoja, kun ei oo yhteensopivaa kerneliä.
 
Suurimman osan Archin epävakaudesta saa suoraan jo pois kun ei asenna sitä Grub:lla vaan vaikka systemd-boot:lla. Grub on ainakin archin osalta "low-maintenance" eikä sitä juuri suositella käytettäväksi.

Ihan täyttä sontaa. Grub on VAIN bootloader jolla on ikää jo lähes 30v ja Grub 2 ollut lähes 10v jo käytössä. Ihmettelisin suuresti jos tuossa ajassa ei olisi epävakautta aiheuttavia mahdollisia bugeja pystytty korjaamaan. Lisäksi käyttö on varsin laajaa. Koska se on vain bootloader niin se ei kyllä mitenkään pysty tekemään mistään distrosta epävakaata. Itte käyttänyt Grub aika pitkälti sen julkaisusta lähtien, eli siitä asti kun redhat vaihtoi lilosta grubiin ja joskus on ollut ongelmia mutta kyllä ne on tgainnu olla ihan user error. Edelleen on grub käytössä eikä ole löytynyt mitään syytä miksi siitä pitäisi hankkiutua eroon.

Jos nyt kuitenkin faktana tiedät että grub tekee linuxista epävakaan, niin laitappa lähteet kehiin josta me muutkin voidaan käydä ihmettelemässä asiaa.
 
Ihan täyttä sontaa. Grub on VAIN bootloader jolla on ikää jo lähes 30v ja Grub 2 ollut lähes 10v jo käytössä. Ihmettelisin suuresti jos tuossa ajassa ei olisi epävakautta aiheuttavia mahdollisia bugeja pystytty korjaamaan. Lisäksi käyttö on varsin laajaa. Koska se on vain bootloader niin se ei kyllä mitenkään pysty tekemään mistään distrosta epävakaata. Itte käyttänyt Grub aika pitkälti sen julkaisusta lähtien, eli siitä asti kun redhat vaihtoi lilosta grubiin ja joskus on ollut ongelmia mutta kyllä ne on tgainnu olla ihan user error. Edelleen on grub käytössä eikä ole löytynyt mitään syytä miksi siitä pitäisi hankkiutua eroon.

Jos nyt kuitenkin faktana tiedät että grub tekee linuxista epävakaan, niin laitappa lähteet kehiin josta me muutkin voidaan käydä ihmettelemässä asiaa.
Samaa mieltä, itse olen ensimmäisiä kertoja käyttänyt linuxia joskus 1999 ja viimeiset noin 20v ihan "daily driverinä" ja käytössä on ollut lilo, grub ja grub2 (ja joku muukin mitä oli joskus aikanaan käytössä) ja jos jotain niihin liittyvää ongelmaa on ollut niin se on ollut vahvasti user error. Edelleen itsellänikin on grub2 käytössä koska se on tullut oletuksena automaattisesti enkä ole nähnyt mitään syytä ruveta käsin siitä eroon pääsemään.
 
Eipä osaa grub2 bootata zfs:ltä jos on liikaa ominaisuuksia (esim salaus) käytössä. En tiedä lasketaanko se sitten epävakaudeksi.
 
Eipä osaa grub2 bootata zfs:ltä jos on liikaa ominaisuuksia (esim salaus) käytössä. En tiedä lasketaanko se sitten epävakaudeksi.
En laskisi tuota epävakaudeksi vaan pikemminkin puuttuvaksi featureksi. Tosin, itselläni moinen ei ole tullut vastaan kun zfs:ää taitaa olla käytössä kahdessa koneessa ja jos joku niihin fyysisesti pääsee käsiksi niin on suurempiakin huolenaiheita. Tosin, salattuja levyjä itselläni on käytössä vain liikkuvissa laitteissa eli lähinnä läppäreissä.
 
Ihan täyttä sontaa. Grub on VAIN bootloader jolla on ikää jo lähes 30v ja Grub 2 ollut lähes 10v jo käytössä. Ihmettelisin suuresti jos tuossa ajassa ei olisi epävakautta aiheuttavia mahdollisia bugeja pystytty korjaamaan. Lisäksi käyttö on varsin laajaa. Koska se on vain bootloader niin se ei kyllä mitenkään pysty tekemään mistään distrosta epävakaata. Itte käyttänyt Grub aika pitkälti sen julkaisusta lähtien, eli siitä asti kun redhat vaihtoi lilosta grubiin ja joskus on ollut ongelmia mutta kyllä ne on tgainnu olla ihan user error. Edelleen on grub käytössä eikä ole löytynyt mitään syytä miksi siitä pitäisi hankkiutua eroon automaattisesti.

Jos nyt kuitenkin faktana tiedät että grub tekee linuxista epävakaan, niin laitappa lähteet kehiin josta me muutkin voidaan käydä ihmettelemässä asiaa.
Puhuin lähinnä Archista jossa grub on suurin ongelma näiden hajoamisen osalta. Sitä kun ei Aechin puolelta juuri ylläpidetä, toisin kuin systemd-bootin osalta jolle löytyy valmiit hookit jolla bootloaderin päivitys onnistuu. Samat löytyy Grubille mutta ne vaatii esim AUR pakettia jne

Ja tässä oli nyt kyse siitä että Archilla on muutaman kerran bootti hajonnut kun Grub ei ole päivittänyt itseään ja sen lataajia päivityksen yhteydessä.

Ihan vapaasti voit grubia käyttää ei ole keneltäkään pois, tietysti Fedorassa ei suoraan muita vaihtoehtoja olekaan. Ovat kuitenkin joutuneet tuota pätsäämään aika tuhottomasti ja siltikin Fedora Atomic illat ollut aika paljon ongelmia tuon kanssa, ongelmat tietysti enemmän Atomocissa kuin itse Grubissa mutta kuitenkin.

Aivan turha alkaa rageemaan asiasta.
 
Viimeksi muokattu:
Puhuin lähinnä Archista jossa grub on suurin ongelma näiden hajoamisen osalta. Sitä kun ei Aechin puolelta juuri ylläpidetä, toisin kuin systemd-bootin osalta jolle löytyy valmiit hookit jolla bootloaderin päivitys onnistuu. Samat löytyy Grubille mutta ne vaatii esim AUR pakettia jne

Mä nyt hiukan googletin asiaa ja toihan on aika selvästi paketin ylläpitäjän ongelma että ei ole viitsinyt rakentaa hookkia että grub2-install ajetaan sen jälkeen kun grub paketti päivitetään.
Ilmeisesti arkin tapauksessa "hajonneita" asennuksia oli tullut kun päivitetyllä grubilla oli sitten vedetty grub2-mkconfig joka oli taas tehnyt sellaisen conffit jota bootilla ollut grub ei osannutkaan enää tulkita, koska vanha versio.

Edelleen toi ei ole grubin syytä mitenkään ja se grub ei siitä distrosta tee epävakaata kuten väitit, vaan kyseessä on paketin ylläpitäjän error.
 
Ihan vapaasti voit grubia käyttää ei ole keneltäkään pois, tietysti Fedorassa ei suoraan muita vaihtoehtoja olekaan

Höps. Fedora on tukenut systemd-bootia ainakin 32:sta lähtien. Muistaakseni 39:ssä voi jo asentaa suoraan systemd-bootilla ilman mitään arkeologisia sötöstyksiä.
 
Arch hajoaa sen takia, että jokin uusi päivitys tai paketin päivitys muuttaa jotain aiempia paketteja jolloin aiempia paketteja lakkaa toimimasta uuden päivityksen seurauksena, koska RR-järjestelmää ei testata eikä voida testata dependency conflictien yms. varalta, koska sen voi konfiguroida liian monella tavalla. Esimerkiksi jos jokin uuden version paketti poistaa ominaisuuksia, vaihtaa tiedostopolkuja tai vaihtaa vaikkapa funktioiden nimiä tai argumentteja. Kaikki paketit eivät nimittäin takaa taaksepäinyhteensopivuutta. Repoihin voi silti hyvin päätyä sellaista, jota ei ole testattu tai jossa pitää myös osata lukea jokin pikkupräntti kuten "Will break packages: ...".

Debian stablella tuota ei tapahdu käytännössä koskaan, koska repossa ei voi olla sellaista, mikä hajottaisi järjestelmän, eikä järjestelmään voi asentaa ohjelmia, jotka käyttävät dependencyjä, joita ei ole repossa.
 
Ei se nyt ihan noinkaan mene todellisuudessa, lähinnä vaan internet-keskusteluissa näitä aina leviää.

Archin päärepoihin päätyvät paketit testataan paketoijan toimesta ja isommat päivitykset menee aina testing-repon kautta (kernelit, DE:t, pythonit jne). Eli mitään "järjestelmää rikkovaa" siellä ei kyllä juuri stableen pääse.

Se, että joku kirjastopäivitys rikkoo jonkun AUR paketin tai kolmannen osapuolen sovelluksen kun joku palikka muuttuu on sitten toinen juttu, mutta se ei riko koko järjestelmää.

Juuri tuossa pari päivää sitten Archissa päivittyi Python versio (sellaiset reilu ~150kpl paketteja) ja eipä siellä järjestelmä hajonnut, ja nekin mitkä hajosi oli lähinnä AUR paketteja, jotka eivät ole virallisia paketteja. Nuokin vaati lähinnä puhtaan kääntämisen uusiksi, jotta saivat linkitykset jne kuntoon.

Se että Arch on "rolling release" ei tarkoita sitä, että siellä pusketaan kama suoraan upstreamista stable repoihin.

Mutta tätä on varmaan parempi jatkaa täällä Linux distrokeskustelu
 
No kyllä se minulla on hajonnut juurikin pacmanin updaten seurauksena, jonka jälkeen aloin varomaan pacmanilla -Syu -päivityksiä, ENNEN kuin olen lukenut, että muut ovat asentaneet sen ilman ongelmia.

Siitä on jokin aika kun käytin Archia viimeksi tosin. Voi olla, että Arch stable toimii kuten muutkin stablet, mutta toisaalta se luultavasti invalidoi RR-distron edut, jotka liittyvät yleensä unstable repojen käyttöön. Koska jos ne olisivat stable paketteja, niin ne saataisiin melko samaan aikaan vaikkapa Debianiinkin.
 
Viimeksi muokattu:
No kyllä se minulla on hajonnut juurikin pacmanin updaten seurauksena, jonka jälkeen aloin varomaan pacmanilla -Syu -päivityksiä, ENNEN kuin olen lukenut, että muut ovat asentaneet sen ilman ongelmia.

Siitä on jokin aika kun käytin Archia viimeksi tosin. Voi olla, että Arch stable toimii kuten muutkin stablet, mutta toisaalta se luultavasti invalidoi RR-distron edut, jotka liittyvät yleensä unstable repojen käyttöön. Koska jos ne olisivat stable paketteja, niin ne saataisiin melko samaan aikaan vaikkapa Debianiinkin.
Kukaan ei väitä etteikö se olisi mahdollista vaan kyse olikin siitä että se on lähinnä todella harvinaista, etenkin nykyisin.
 
Miksi jotkut eivät pidä binääriyhteensopivuutta maalina?

Minusta se on erittäin olennainen, mutta sen olemattomuus johtaa siihen, että eri distrot ovat tosiaankin eri distroja.

Vai ehkä binääriyhteensopimattomuus on vain seurausta siitä, että ihmiset eivät halua olla samaa mieltä, kuten POSIX:ikin nähdään liian rajoittavana.

Jokin dokumentoitu rajapinta olisi hyvä olla kuitenkin, kuten GitHub - jart/cosmopolitan: build-once run-anywhere c library
 
Viimeksi muokattu:
Miksi jotkut eivät pidä binääriyhteensopivuutta maalina?

Minusta se on erittäin olennainen, mutta sen olemattomuus johtaa siihen, että eri distrot ovat tosiaankin eri distroja.

Vai ehkä binääriyhteensopimattomuus on vain seurausta siitä, että ihmiset eivät halua olla samaa mieltä, kuten POSIX:ikin nähdään liian rajoittavana.

Jokin dokumentoitu rajapinta olisi hyvä olla kuitenkin, kuten GitHub - jart/cosmopolitan: build-once run-anywhere c library
Tuosta syystä aikoinaan kokeilin freebsd:tä ja olin siitä muutenkin kiinnostunut, mutta käytännössä linux kuitenkin toimii hyvin.
 
Tuosta syystä aikoinaan kokeilin freebsd:tä ja olin siitä muutenkin kiinnostunut, mutta käytännössä linux kuitenkin toimii hyvin.
Joo no itse olen kanssa näiden välillä ja rajasin omat intressini Debian:iin ja FreeBSD:hen. Mikään muu ei kiinnosta. FreeBSD antaa minulle sen mitä Arch tai vaikkapa Gentoo. Linuxulator on Debian:in näkökulmasta hyödyllisin.
 

Statistiikka

Viestiketjuista
262 706
Viestejä
4 563 220
Jäsenet
75 011
Uusin jäsen
Pro

Hinta.fi

Back
Ylös Bottom