Linux-kysymyksiä & yleistä keskustelua Linuxista

Serverissä pyörii i5-10500, eli 6c 12t ja 16gb ram alustavsti, 256 SSD, lisälevyjä voi lyödä sitten tarpeen mukaan tod. näk eli uskoisin että tehot riittävät myös kunnon virtualisointiin. Tuo kontin käyttö, ilmeisesti dockerista puhutaan, lienee järkevin tapa aloittaa kuitenkin vaikka debian/ubutun kanssa että pääsee tosiaan alkuun tuon linux maailman kanssa, ei proxmoxikaan ihan mahdottomalta vaikuttanut parin tutorial videon perusteella mutta haitat taivat vielä ylittää hyödyt.
 
No en nyt ole ollenkaan varma että on se järkevin vaihtoehto. Noita juttuja joita luettelit voi suurinta osaa ellei peräti kaikkia ajella konttina. Virtualisointi on mielestäni aika järeän luokan toimenpide joka myös monimutkaistaa ylläpitoa jos aletaan virtuaali pömpeliä laittamaan jokaiselle pulikalle omaansa.
Sen virtualisoinnin ainut etu on se että voit helposti sen kikottimen viskata myöhemmin toiseen koneeseen pyörimään jos sattuu nälkä kasvamaan syödessä ja niitä fyysisiä koneita alkaakin ilmestyä lisää.

Pitää kuitenkin ottaa huomioon että jokainen pystytetty virtuaalikone syö resursseja vaikka olisi shared memory käytössä.
Resurssien kannaltahan tuo virtuaalikonemaailma ei ole ihan tehokkainta resurssien käyttöä mutta mielestäni se on huomattavasti helpompi oppia ja ymmärtää kuin konttien / dockerin / vastaavien ymmärtäminen ja opettelu. Kyllähän virtuaalikoneiden kanssa menee pirusti muistia ja levytilaa hukkaan kun käyttöjärjestelmät syövät saman asian moneen kertaan.

Itse ainakin opin hetkessä virtuaalikoneiden maailman mutta noiden konttien kanssa on vielä paljon opeteltavaa kun konttien luonti, konttien väliset verkot, konttien ulkopuoliset tiedostot sun muut asiat eivät ole ihan itsestäänselviä asioita ainakaan itselleni. Virtuaalikoneiden puolellahan virtuaalikone on ihan kuin oikea tietokone, se vaan on toisen tietokoneen "sisällä" ja ne toimivat ihan kuin erillinen tietokonekin.
 
Resurssien kannaltahan tuo virtuaalikonemaailma ei ole ihan tehokkainta resurssien käyttöä mutta mielestäni se on huomattavasti helpompi oppia ja ymmärtää kuin konttien / dockerin / vastaavien ymmärtäminen ja opettelu. Kyllähän virtuaalikoneiden kanssa menee pirusti muistia ja levytilaa hukkaan kun käyttöjärjestelmät syövät saman asian moneen kertaan.

Itse ainakin opin hetkessä virtuaalikoneiden maailman mutta noiden konttien kanssa on vielä paljon opeteltavaa kun konttien luonti, konttien väliset verkot, konttien ulkopuoliset tiedostot sun muut asiat eivät ole ihan itsestäänselviä asioita ainakaan itselleni. Virtuaalikoneiden puolellahan virtuaalikone on ihan kuin oikea tietokone, se vaan on toisen tietokoneen "sisällä" ja ne toimivat ihan kuin erillinen tietokonekin.

Mä tykästyin cloud-inittiin (jonka sitten lopulta disabloin, kun vm kunnossa), kun se hoitaa dokumentoinnin siinä samalla (kun pitää ne konffifilut ja loitsut vaikka gitissä). Lisäksi saa aika minimaalisia vm:iä pyörimään.
 
Mä tykästyin cloud-inittiin (jonka sitten lopulta disabloin, kun vm kunnossa), kun se hoitaa dokumentoinnin siinä samalla (kun pitää ne konffifilut ja loitsut vaikka gitissä). Lisäksi saa aika minimaalisia vm:iä pyörimään.
Tuohon cloud-init:iinkin on pitänyt jossain välissä tutustua mutta on tässä ollut niin monta muutakin asiaa että ei ole kerinnyt.
 
Proxmox on ihan hyvä vaihtoehto ja helppo asentaa. Netistä löytyy paljon ohjeita sekä videoita ihan asennuksesta sitten laajempaan konfigurointiin.

Itsellä pyörii kone Proxmoxilla, jossa pääosin ajan sitten LXC containeria, jossa pyörii sitten tarvittavat "homelab" jutut. Proxmoxissa hyvä että voit luoda vaikka erillisen VM:n tietylle asialla ja sitten vaikka LXC:n hieman kevyimmille (kuten docker jne) jutuille.

Itse proxmoxin käyttöön ei hirveästi peruskäytössä terminaalia tarvita, pitkälti kaiken voi tehdä web-käyttöliittymän kautta.

Proxmox VE Helper-Scripts näillä pääsee jo hyvin pitkälle alkuun.
 
sitten vaikka LXC:n hieman kevyimmille (kuten docker jne) jutuille.
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:
If you want to run application containers, for example, Docker images, it is recommended that you run them inside a Proxmox QEMU VM. This will give you all the advantages of application containerization, while also providing the benefits that VMs offer, such as strong isolation from the host and the ability to live-migrate, which otherwise isn’t possible with containers.
 
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:

Tarkoittaako tämä ohje nyt että pitäisi ottaa se container image ja ajaakin sitä virtuaalikoneena, vai pistää containerit ajoon virtuaalikoneen sisälle? Molemmin päin kuulostaa kohtalaisen älyttömältä suositukselta...

Yleensä niitä containereita ajetaan kun haetaan kevyempää virtualisointia eikä kaivata täyden virtuaalikoneen overheadia yms. "etuja".
 
Dockeria suositellaan ajettavaksi VM:ssä LXC:n sijaan. Keskusteluja tästä aiheesta on netti pullollaan, mutta myös Proxmoxin dokumentaatiossa sanotaan:
Juu ei kiitos.

Ensinnäkin tuossa on vielä itselle sellainen ongelma, että kun serverissä ei ole kuin erillinen gpu (intel arc) niin sen joutuisi luovuttamaan yhdelle VM:lle että saa käytettyä esim Jellyfinin/Plexin kanssa. Sitten ei olisikaan enää GPU:ta käytettäväksi muille kun tuo yksi VM söisi sen kokonaan.

Ajan mielummin unpriviledged LXC:ssä ja annan tarvittavat oikat että kontti pääsee käsiksi näyttikseen.

En nyt suoraan näe että VM olisi tässä mitenkään enemmän turvallisempi.
 
Rupesinpa päivittämään vuosia toiminutta Linux-palvelinta Debian Stretchistä Busteriin (ja siitä tuoreempiin), kun sen joutui muista syistä boottaamaan. Tässäpä nousi tie pystyyn 'apt full-upgrade':ssa:
Koodi:
# apt full-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  dh-python emacs24-nox libboost-iostreams1.67.0 libboost-system1.67.0 libcwidget3v5 liblockfile1
  libpython3.5-minimal libpython3.5-stdlib libsigc++-2.0-0v5 libssl1.0.2 libxapian30 python3-distutils
  python3-lib2to3 python3.5 python3.5-minimal
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  apt apt-utils aptitude libapt-inst2.0 libapt-pkg5.0 libcurl3 tasksel tasksel-data
The following NEW packages will be installed:
  libcurl4 libpython3.7-minimal libpython3.7-stdlib python3-distutils python3-lib2to3 python3.7
  python3.7-minimal
The following packages have been kept back:
  dmeventd
The following packages will be upgraded:
  curl dash dpkg libpython3-stdlib libudev1 python3 python3-minimal udev
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt libapt-pkg5.0 (due to apt)
8 upgraded, 7 newly installed, 8 to remove and 2 not upgraded.
Need to get 9,074 kB of archives.
After this operation, 11.7 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] no
Abort.
Tämä siis haluaisi poistaa apt:n mikä ei vaikuta hyvältä ajatukselta.
Koodi:
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt libapt-pkg5.0 (due to apt)
Jos yrittää asentaa erikseen apt:n (apt install apt):
Koodi:
The following packages have unmet dependencies:
 apt : Depends: libapt-pkg5.0 (>= 1.7.0~alpha3~) but 1.4.11 is to be installed
E: Unable to correct problems, you have held broken packages.
ja sama libapt-pkg5.0:lle
Koodi:
The following packages have unmet dependencies:
 libapt-pkg5.0 : Depends: libsystemd0 (>= 221) but 215-17+deb8u4 is to be installed
E: Unable to correct problems, you have held broken packages.

Miten tätä olisi parasta ruveta ratkomaan? Ei oikein arvaisi lähteä boottaamaan päivityksen ollessa kesken.
 
Rupesinpa päivittämään vuosia toiminutta Linux-palvelinta Debian Stretchistä Busteriin (ja siitä tuoreempiin), kun sen joutui muista syistä boottaamaan. Tässäpä nousi tie pystyyn 'apt full-upgrade':ssa:
Koodi:
# apt full-upgrade
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  dh-python emacs24-nox libboost-iostreams1.67.0 libboost-system1.67.0 libcwidget3v5 liblockfile1
  libpython3.5-minimal libpython3.5-stdlib libsigc++-2.0-0v5 libssl1.0.2 libxapian30 python3-distutils
  python3-lib2to3 python3.5 python3.5-minimal
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  apt apt-utils aptitude libapt-inst2.0 libapt-pkg5.0 libcurl3 tasksel tasksel-data
The following NEW packages will be installed:
  libcurl4 libpython3.7-minimal libpython3.7-stdlib python3-distutils python3-lib2to3 python3.7
  python3.7-minimal
The following packages have been kept back:
  dmeventd
The following packages will be upgraded:
  curl dash dpkg libpython3-stdlib libudev1 python3 python3-minimal udev
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt libapt-pkg5.0 (due to apt)
8 upgraded, 7 newly installed, 8 to remove and 2 not upgraded.
Need to get 9,074 kB of archives.
After this operation, 11.7 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] no
Abort.
Tämä siis haluaisi poistaa apt:n mikä ei vaikuta hyvältä ajatukselta.
Koodi:
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt libapt-pkg5.0 (due to apt)
Jos yrittää asentaa erikseen apt:n (apt install apt):
Koodi:
The following packages have unmet dependencies:
 apt : Depends: libapt-pkg5.0 (>= 1.7.0~alpha3~) but 1.4.11 is to be installed
E: Unable to correct problems, you have held broken packages.
ja sama libapt-pkg5.0:lle
Koodi:
The following packages have unmet dependencies:
 libapt-pkg5.0 : Depends: libsystemd0 (>= 221) but 215-17+deb8u4 is to be installed
E: Unable to correct problems, you have held broken packages.

Miten tätä olisi parasta ruveta ratkomaan? Ei oikein arvaisi lähteä boottaamaan päivityksen ollessa kesken.

Mitä kaikkea teit ennen full-upgradea ?

Tällä olen tähän asti pärjännyt, ensin vanhojen päivitys ja turhien poisto:
Koodi:
apt update -y
apt upgrade -y
apt dist-upgrade -y
apt autoremove
apt clean

Sitten bootti

sources.list muutokset versiosta uudempaan

Ja varsinainen päivitys
Koodi:
apt update -y
apt upgrade --without-new-pkgs -y
apt full-upgrade -y
 
Mitä kaikkea teit ennen full-upgradea ?

Tällä olen tähän asti pärjännyt, ensin vanhojen päivitys ja turhien poisto:
Koodi:
apt update -y
apt upgrade -y
apt dist-upgrade -y
apt autoremove
apt clean
Näistä tein update:n ja upgrade:n mutta en dist-upgrade:a. En tehnyt autoremove:a, koska mitään ei ollut roikkumassa. Missään komennoissa ei ole -y:tä.
Sitten bootti

sources.list muutokset versiosta uudempaan
Tuli bootattua pariinkin kertaan ja päivitettyä sources.list osoittamaan archive.debian.org
Ja varsinainen päivitys
Koodi:
apt update -y
apt upgrade --without-new-pkgs -y
apt full-upgrade -y
apt upgrade oli ilman --without-new-pkgs, ja se asentelikin melkoisen määrän paketteja.

Onkohan merkitystä, mutta kone oli alunperin Debian Jessie ja päivitetty siitä aiemmin Stretch:ksi. Kyse on virtuaalipalvelimesta jossain Saksassa, joten olisi hyvä jos asennuksen saisi korjattua ilman uudelleenasennusta.
 
Näistä tein update:n ja upgrade:n mutta en dist-upgrade:a. En tehnyt autoremove:a, koska mitään ei ollut roikkumassa. Missään komennoissa ei ole -y:tä.

Tuli bootattua pariinkin kertaan ja päivitettyä sources.list osoittamaan archive.debian.org

apt upgrade oli ilman --without-new-pkgs, ja se asentelikin melkoisen määrän paketteja.

Onkohan merkitystä, mutta kone oli alunperin Debian Jessie ja päivitetty siitä aiemmin Stretch:ksi. Kyse on virtuaalipalvelimesta jossain Saksassa, joten olisi hyvä jos asennuksen saisi korjattua ilman uudelleenasennusta.
Ei ole väliä vaikka olisi päivitetty aiemmin.

Jos siellä pyörii jotain joka on helppo asentaa uusiksi niin tee vaan uusi kone vanhan rinnalle ja lopuksi vaihdat ?
 
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
 
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.

Joillakin distroilla (ja käyttäjillä) todellisuus on juuri tuota. Mutta taisitkin vaan trollata niin turha tästä on enempää alkaa jauhamaan.
 
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.

Linux puolella on valinnanvaraa myös siinä päivitettävyydessä. Yksi distro on helppo päivittää, toinen ei.

Kernelin live pätsäys tuli joskus vuosia sitten ja ne distrot joissa se onnistuu niin niitä ei periaatteessa tartte bootata ikinä.
 
Jotain ongelmia saattaa tulla vastaan jos on jättänyt päivittämättä pitkäksi aikaa ja on käyttänyt siis tukematonta versiota distrosta ja sitä koittaa päivittää seuraavaan versioon tai ehkä rolling releasillakin voi tulla ongelmia tuossa tapauksessa.
 
Minusta tätä upgrade mahdollisuutta rummutetaan aika paljon liikaa verrattuna siihen että ongelmia vaikuttaa näkyvän aika paljon.
Voisi sitä joskus kuitenkin kokeilla itsekkin ja silloin koe-eläimeksi voisi hyvin valita jonkun virtuaalipalvelimen koska snapshotin kun ottaa ennen päivitystä niin epäonnistuminen ei ole mikään ongelma kun vaan palauttaa snapshotin ja mitään ei ole menetetty.
 
Itse asensin Kubuntun uuteen työpöytäkoneeseen 2015 ja sitä olen päivitellyt siitä asti uuteen versioon. Jotain joskus hajoaa, ei siis päivityksen kesken, vaan joku ei asia ei toimikaan enää uudessa versiossa, mahdollisesti tuon pitkään jatkuneen päivittelyn takia, kun ei sellaista varmaan testata. Ja kloonaan levystä aina kopion ennen asennusta jos tulee suurempaa häikkää. Mutta kaikenlaista säätöä on homen ulkopuolellakin, niin ei kiinnosta uusi päivitys. Toki noi muutokset voisi pitää gitissä ja home omalla osiollaan, niin noinkin uuden version kokonaan uudelleen asennus olisi varmaan aika vaivaton homma.
 
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Näin se on, tämäkin on asennettu kai v. 2016 ja kerran päivitetty Jessie->Stretch. Boottaamaankin joutuu yhtenään, nytkin oli uptime vain yli 900 päivää. Tätä boottia tosin ei oikein voi pistää Linuxin piikkiin, koska kone piti ajaa alas virtualisointialustan lahottua ajan myötä.

Hätäilyä tämä versiopäivityskin oli, jatkettu tuki Stretch:lle jatkuu vielä kesään 2027 saakka:
Minusta tätä upgrade mahdollisuutta rummutetaan aika paljon liikaa verrattuna siihen että ongelmia vaikuttaa näkyvän aika paljon
Se, että jatkettu tuki on olemassa kertoo siitä, että versiopäivitykset eivät aina ole ongelmattomia. Samasta varoittaa myös Debian itse Release Noteissa.

Toisaalta ongelmien näkyminen on myös osittain harhaa: kukapa onnistuneista päivityksistä mihinkään kirjoittaisi.
 
Eikä ongelma ole pelkästään siinä, että se versiopäivitys saattaa mennä pieleen. Saattaa siinä se oma sovellus myös hajota, kun softat päivittyy.

Siksi kait on suhteellisen yleistä, että ei rikota sitä mikä toimii. Sitten kerran kymmeneen vuoteen asennellaan uusiksi. Jos palvelinta ajelee omalla raudalla, niin onhan se kymmenen vuoden jälkeen ihan asiallista päivittää rautakin samalla. Virtuaalikoneessa on sitten vieläkin helpompaa asennella se uusi versio uuteen instanssiin ja vaihtaa se tuotantoon kun on testattu toimivaksi.
 
Kun keskusteluja useasta paikasta seurannut, tuntuu isoin valitus linuxista olevan työpöytäkäyttö. Ongelma ratkeaa helposti sillä, että ajaa linuxia, esim. ubuntu server headlessinä vaikka virtuaalikoneessa ja ssh:llä yhteys. Komentorivi ja sen työkalut ainakin itselle tärkein asia siinä, eikä se, onko työpöytä gnome/kde/xfce/joku muu. Vähentää kummasti säätöä :)
Mistä ne tarkalleen valittaa?
Itse en ole ainakaan Redditissä huomannut mitään varsinaista valitusta työpöytäympäristöistä. Ihan Windows-maisia hyvässä ja huonossa KDE Plasma 6.2 ja GNOME on IMO. Lagaa ja vituttaa vaan vähemmän. Oikeen mitään en ole jäänyt kaipaamaan nyt kun kaikki koneet yhtä lukuun ottamatta pyörittää Linuxia.

Itse en käytä terminaalia kuin johkin scriptien/aliaksien luomiseen/ajamiseen ja softien asentamiseen. Vähän poikkeava ympäristö, kun pari näyttöä on jaettu useammalle koneelle, niin sammuttelen/disabloin jne. terminalin kautta näyttöjä :D

Pari oudompaa ongelmaa on nostanut päätään välillä, mutta suht nopsaan niistä on selvitty. Tällä hetkellä miniPC kadottaa 1440p-natiivireson ja pudottaa jostakin syystä ihan randomille resoluutiolle. Joku päivitys pisti sekasin.
inotifystä loppu tila yhdessä vaiheessa.
Synergyn kanssa tulee tapeltua, kun typeryyksissäni pistin Synergy 3:n takas, kun oletin, että siinä olis jo Wayland-tuki, kun kerran tukevat jo Linuxia natiivisti. Synergy 1/Input Leap sentään käynnistyy ja toimii Waylandilla, kolmonen ei ees käynnisty. Kuulemma tuki on tulossa...VMP. Backspace ei toimi hiirestä remote-koneilla, samoin näppisleiskojen kanssa on ongelmaa, esim osassa ei toimi at-merkki tai AltGr noin yleensäkään. Rasittavinta on, että noi tuntuu toimivan välillä ja Synergyn antamat korjausehdotukset ei oikeen pelitä.
Pelimyllyssä sai hetken säätää ja etsiä, että löytyi mukavat työkalut alikellotteluun, tuulettimien hallintaan, lämpöjen monitorointiin (CPU vaati Zenpower3:n), RGB:n hallintaan ja ettö sai kaikki MangoHUDiin.
 
Näissäkohtaa muistuu aina mieleen kuinka joskus rummutettiin kuinka linuxin päivitys on niin paljon helpompaa kuin windowsin, koskaan ei mene mikään mönkään ja aikoinaan kehuttiin jopa sillä ettei tarvitsisi edes uudelleenkäynnistää konetta. Vitsiä vedetiin vuosittaisesta windowsin uudelleen asennuksesta. Todellisuus taitaa (taaskin) olla vähän eri.
Ja joissakin tapauksissa (minä) Windowsia ei ole ikinä tarvinnut asentaa uudelleen, pistänyt vaan 2010 asennetun seiskan päälle kympin ja mennyt sillä, kunnes vaihdoin Linuxiin. Toisella myllyllä kloonasin vaan oletus-winkkuasennuksen uudelle SSD:lle, kun päivitin nopeampaan. Siitäkin nyt 6-7 vuotta.
Sama Linuxilla; päivittänyt nyt kahdesti major version Nobarasta (38-39-40), vaihtanut GNOMEsta KDE:hen kertaalleen ja päivittänyt Pulseaudion Pipewireen ilman minkään hajoamatta.
Paha sanoa onko tää vaan tuuria vai oikeat ohjeet.
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.

:facepalm:

Mistä sä revit tämmöstä juttua ?
Napin painalluksella päivittyy niin järjestelmä kuin kaikki ohjelmatkin.

Kuvakaappaus_20241105_144642.png
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
En nyt ihan suoraan lähtisi vertaamaan työpöytäkäytössä olevaa Windowsia ja (tässä mainitussa tapauksessa) Debiania jossa muutenkin tulee ns. vakaa versio ulos ~2 vuoden välein ja sitten jos jätetään yksi versio päivittämättä (kuten esim servereissä on useasti tapana, ei niitä päivitetä uusimpaan heti vaan vasta ehkä sitten kun tietoturvapäivitykset loppuu).

Normaalit "työpöytä-Linuxit" päivittyy kyllä ihan samalla tapaa graafisesti nappia painamalla jos niikseen haluaa.
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
Jolla kaikki asennetut ohjelmat päivittyvät?

Tosin ei sitä tapahdu Linux:llakaan, jos osaa ohjelmista ei ole pakattu distrolle.
 
Jolla kaikki asennetut ohjelmat päivittyvät?

Tosin ei sitä tapahdu Linux:llakaan, jos osaa ohjelmista ei ole pakattu distrolle.
Riippuu distrosta ja käytetystä pakettienhallinsta. Joku oli mikä päivittä samalla käyttiksen paketit, snapit ja flatpakit.

Olisko ollu Manjarossa tai jossain toisessa arch pohjaisessa oletuksena käytössä.
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
Ei taida Windowssissa mikään kolmannen osapuolen ohjelma päivittyä samalla, kun Windows päivittyy? Linuxissa tämä on edes teoriassa mahdollista, jos ohjelmat on asennettu distron repoista.

Enkä kyllä usko muutenkaan, että kukaan valitsee käyttöjärjestelmää sillä perusteella, että sitä on helppo päivittää. Vähän sama, kuin ostaisi auton siksi, että sitä on helppo tankata.
 
Riippuu distrosta ja käytetystä pakettienhallinsta. Joku oli mikä päivittä samalla käyttiksen paketit, snapit ja flatpakit.

Olisko ollu Manjarossa tai jossain toisessa arch pohjaisessa oletuksena käytössä.
Manjaron tekemä Pamac paketinhallintaohjelmisto, tämän saa päivittämään AUR, flatpak ja snap paketit samalla. Tämän saa käyttöön AUR pakettina mihin tahansa Arch pohjaiseen distroon. Itse käytän tätä Archin kanssa koska on vaan niin käytännöllinen.
Ei taida Windowssissa mikään kolmannen osapuolen ohjelma päivittyä samalla, kun Windows päivittyy? Linuxissa tämä on edes teoriassa mahdollista, jos ohjelmat on asennettu distron repoista.

Enkä kyllä usko muutenkaan, että kukaan valitsee käyttöjärjestelmää sillä perusteella, että sitä on helppo päivittää. Vähän sama, kuin ostaisi auton siksi, että sitä on helppo tankata.
Kyllä minulle yksi isoimmista syistä valita Arch on juuri se että repot+AUR+flatpak sisältää jokaisen linuksille tehdyn ohjelmiston mitä on osannut kaivata, yhtä ainutta ohjelmaa ei ole tarvinnut ladata paketinhallinnan ulkopuolelta, ja kaikki asennetut ohjelmistot päivittyy yhdellä napin painalluksella.
 
Taas sellainen mielessä, että kokeilisi Linuxia normikäytössä kotona. Kaivaako verta nenästänsä, jos tarkoitus pelaillakin jonkun verran ja näyttiksenä rtx 4070? Fedoran ajattelin asennella, mutta muistaakseni viimeksi oli jotain ongelmia 165Hz näytön kanssa useammalla distrolla (tai oikeastaan ongelmaksi se muodostui sen takia kun toinen näyttö oli 60Hz ja toinen 165Hz).
Vaihtoehtona olisi tietty joku passthrough viritys näyttikselle ja virtualisoida winukka. Siihen pitäisi kyllä hommata toinen näyttis ilmeisesti, kun 5600x ei integroitua ole.
 
Kyllä minulle yksi isoimmista syistä valita Arch on juuri se että repot+AUR+flatpak sisältää jokaisen linuksille tehdyn ohjelmiston mitä on osannut kaivata, yhtä ainutta ohjelmaa ei ole tarvinnut ladata paketinhallinnan ulkopuolelta, ja kaikki asennetut ohjelmistot päivittyy yhdellä napin painalluksella.
Syy ei siis ollut päivittämisessä, vaan pakettienhallinnan laajuudessa (ja sitten siinä, että niitä paketteja on helppo päivittää).

Vai olisitko valinnut Archin, jos pakettienhallinnan kautta olisi saatavilla vain kerneli, jota on helppo päivittää?
 
Viimeksi muokattu:
Taas sellainen mielessä, että kokeilisi Linuxia normikäytössä kotona. Kaivaako verta nenästänsä, jos tarkoitus pelaillakin jonkun verran ja näyttiksenä rtx 4070? Fedoran ajattelin asennella, mutta muistaakseni viimeksi oli jotain ongelmia 165Hz näytön kanssa useammalla distrolla (tai oikeastaan ongelmaksi se muodostui sen takia kun toinen näyttö oli 60Hz ja toinen 165Hz).
Vaihtoehtona olisi tietty joku passthrough viritys näyttikselle ja virtualisoida winukka. Siihen pitäisi kyllä hommata toinen näyttis ilmeisesti, kun 5600x ei integroitua ole.
AMD:n näyttis ja käytössä OpenSuse Tumbleweed KDE Plasmalla, 240 Hz + 60 Hz näytöt toimii ongelmitta. Mutta Linuxilla käsittääkseni voi olla isojakin eroja toiminnassa näyttiksen valmistajasta riippuen joten ehkä joku Nvidian omistaja osaa sanoa siitä puolesta paremmin.

Vaihdoin tuossa vähän aikaa sitten koneen buuttaamaan vakiona Linuxiin Windowsin sijaan, molemmat kuitenkin pysyy vielä asennettuna. Loppujen lopuksi pelit saa toimimaan hyvinkin kivuttomasti, Steamista kaikki toimii käytännössä napin painalluksella ja sitten vaikkapa Lutris hoitaa loput. Toki en juurikaan pelaa kilpailullisia moninpelejä, noissa on käsittääkseni enemmän ongelmia kun huijauksenesto-ohjelmat eivät tue Linuxia.
 
Viimeksi muokattu:
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
Ei tossa nyt ihan hirveesti tavaraa ole. Eikä pahemmin tarvi ajatella mitään, jos ei halua. Ja tämä siis isommassa versiopäivityksessä, Softat ja kernelit jne. päivittyy normisti Update-napista.
 
Syy ei siis ollut päivittämisessä, vaan pakettienhallinnan laajuudessa (ja sitten siinä, että niitä paketteja on helppo päivittää).

Vai olisitko valinnut Archin, jos pakettienhallinnan kautta olisi saatavilla vain kerneli, jota on helppo päivittää?
Ei nuo poissulje toisiaan, se että kaikki paketit löytyy repoista tekee päivittämisestä helppoa. Ei se päivittäminen olisi helppoa jos se päivittäisi vain kernelin ja kaikki muut ohjelmistot pitäisi kaivaa päivitykset ties mistä.
 
Saako esim. Fedoran asennettua niin, että oletuksena se käynnistyy ilman graafista käyttistä, ts. on mahdollisimman kevyt ja vähävirtainen ja sitten tarvittaessa hallinnointia varten saisi GUI:n käyntiin? Tarkoitus siis aiemmin mainittu mini-PC -asennus kotiautomaatioskriptejä ja verkkolevypalvelimeksi mediatoistimelle. Suurimman osan ajasta tuo voisi pyöriä ilman mitään turhaa virtaa kuluttavaa (ja kaappia lämmittävää) tauhkaa.
 
Saako esim. Fedoran asennettua niin, että oletuksena se käynnistyy ilman graafista käyttistä, ts. on mahdollisimman kevyt ja vähävirtainen ja sitten tarvittaessa hallinnointia varten saisi GUI:n käyntiin? Tarkoitus siis aiemmin mainittu mini-PC -asennus kotiautomaatioskriptejä ja verkkolevypalvelimeksi mediatoistimelle. Suurimman osan ajasta tuo voisi pyöriä ilman mitään turhaa virtaa kuluttavaa (ja kaappia lämmittävää) tauhkaa.

Saahan sen. Mutta tuohon tuskin tarvitsee mitään täyttä työpöytäympäristöä vaan riittää joku kevyempi tyyliin i3, Sway tai LXQt. Ei juuri näy vaikka jättää pyörimäänkin.

Toisaalta taas tuollaiseen tarpeeseen itse laittaisin ihan vaan Fedoran serveriasennuksen ilman graafisia kikkareita, ja hoitelisin hallinnan etänä. Jos sitä ei jatkuvasti katsele niin miksi edes laittaa sitä.
 
Saako esim. Fedoran asennettua niin, että oletuksena se käynnistyy ilman graafista käyttistä, ts. on mahdollisimman kevyt ja vähävirtainen ja sitten tarvittaessa hallinnointia varten saisi GUI:n käyntiin? Tarkoitus siis aiemmin mainittu mini-PC -asennus kotiautomaatioskriptejä ja verkkolevypalvelimeksi mediatoistimelle. Suurimman osan ajasta tuo voisi pyöriä ilman mitään turhaa virtaa kuluttavaa (ja kaappia lämmittävää) tauhkaa.
Eiköhän se normaaliasennuskin vaihda tekstiin (tulevissa booteissa), jos
Bash:
sudo systemctl set-default multi-user.target
Lennossa voi sitten vaihtaa graafiseen:
Bash:
sudo systemctl isolate graphical.target

... mutta ... "hallinnointia varten saisi GUI" ... miksi? Kai sen hallinnoi vähintään yhtä tehokkaasti ilman GUI:ta.
Ja jos GUI:ta ei tarvitse, sitten sitä ei kannata edes asentaa. Näytti joku "netinst" asennuskuva antavan valita.
 
Fedoralta löytyy ihan Server versio

Tai sitten vähän erilaiseen käyttöön Fedora CoreOS

 
Manjaron tekemä Pamac paketinhallintaohjelmisto, tämän saa päivittämään AUR, flatpak ja snap paketit samalla. Tämän saa käyttöön AUR pakettina mihin tahansa Arch pohjaiseen distroon. Itse käytän tätä Archin kanssa koska on vaan niin käytännöllinen.
On myös hyvä jos haluaa paskoa Arch asennuksena, pamac on siinä varsin hyvä 😁
 
On myös hyvä jos haluaa paskoa Arch asennuksena, pamac on siinä varsin hyvä 😁
Haluisin kuulla lisää, viis vuotta käyttäny Archia eikä se oo sen jälkeen menny päivityksessä rikki kun heitti grubin hiiteen ja EFIstub tilalle. Nykyään Archinstall antaa valita tuon jo asennusvaiheessa. Pamacin kanssa ei ole ongelmia ollut, viikon välein päivitän.
 
Haluisin kuulla lisää, viis vuotta käyttäny Archia eikä se oo sen jälkeen menny päivityksessä rikki kun heitti grubin hiiteen ja EFIstub tilalle. Nykyään Archinstall antaa valita tuon jo asennusvaiheessa. Pamacin kanssa ei ole ongelmia ollut, viikon välein päivitän.
Se osaa rikkoa mm dependencyt suhteellisen helposti, etenkin jos Pacman päivittyy ja sattuu sopivasti päivittämään.

Ja onhan se jo varmaan 3 vai 4 kertaa dossannut AURn kumoon näin yleisesti.

En kyllä itse nää tuolle mitään tarvetta kun voi käyttää sitten vaikka yay tai paru:a jolla saa koko systeemin päivitettyä.

Mut hyvä jos toimii. Itse vaan en periaatteelisistakaan syistä koske mihinkään mikä edes etäisesti liittyy Manjaroon
 
Saako esim. Fedoran asennettua niin, että oletuksena se käynnistyy ilman graafista käyttistä, ts. on mahdollisimman kevyt ja vähävirtainen ja sitten tarvittaessa hallinnointia varten saisi GUI:n käyntiin? Tarkoitus siis aiemmin mainittu mini-PC -asennus kotiautomaatioskriptejä ja verkkolevypalvelimeksi mediatoistimelle. Suurimman osan ajasta tuo voisi pyöriä ilman mitään turhaa virtaa kuluttavaa (ja kaappia lämmittävää) tauhkaa.


Tuossa hyvä ohje.

Eli käytännössä siis puljataan näillä kahdella:
Koodi:
To switch to runlevel 3, run the following command.
# systemctl isolate multi-user.target

To change the system to runlevel 5, type the command below.
# systemctl isolate graphical.target
 
Niin, no, windowsin päivittämiseen ei yleensä tartte mitään 100 sivuisia ohjeita olla tai ohjeita ylipäätään kun käyttäjän kannalta se on vain napin painallys.
Tässä on vähän puurot ja vellit sekaisin. Normaali päivitysten asennus toimii (ainakin vakiintuneissa distroissa kuten Debian) kuin junan vessa: "apt-get update; apt-get upgrade" ja tämä päivittää kaiken pakettienhallinnan kautta asennetun distron tuoreimpiin versioihin.

Se, minkä kanssa voi olla haasteita, on käyttöjärjestelmän sukupolvipäivitys, eli päivitetään esim. Debian Buster Bullseyeksi. Hätäisimmillään tämä tulee Debianilla eteen parin vuoden välein ja hitaimmillaan kerran vuosikymmenessä, jolloin olisi mielekästä päivittää kerralla useampi sukupolvi.

Windows-puolella tätä voi verrata esim. Win7:n päivittämiseen Win10:ksi. Ei taida aina mennä ilman haasteita?
 
Se osaa rikkoa mm dependencyt suhteellisen helposti, etenkin jos Pacman päivittyy ja sattuu sopivasti päivittämään.

Ja onhan se jo varmaan 3 vai 4 kertaa dossannut AURn kumoon näin yleisesti.

En kyllä itse nää tuolle mitään tarvetta kun voi käyttää sitten vaikka yay tai paru:a jolla saa koko systeemin päivitettyä.

Mut hyvä jos toimii. Itse vaan en periaatteelisistakaan syistä koske mihinkään mikä edes etäisesti liittyy Manjaroon
No täytyy kyllä myöntää se että jos pamac ei oo saanut jotain dependencyjä jostain syystä selvitettyä päivittäessä niin olen ajanut päivitykset yaylla.
 
Eli käytännössä siis puljataan näillä kahdella:
Koodi:
To switch to runlevel 3, run the following command.
# systemctl isolate multi-user.target

To change the system to runlevel 5, type the command below.
# systemctl isolate graphical.target
Noilla saa "sillä kertaa" graafisen käyttöliittymän joko pois päältä tai takaisin päälle.
Kun haluat määrittää kumpaan tilaan kone seuraavissa booteissa järjestää itsensä, tarvitaan vähän erilainen komento:
Koodi:
# systemctl set-default multi-user.target    # bootataan jatkossa ilman GUIta kunnes toisin käsketään
tai
# systemctl set-default graphical.target    # bootataan jatkossa GUIn kanssa kunnes toisin käsketään
 
Noilla saa "sillä kertaa" graafisen käyttöliittymän joko pois päältä tai takaisin päälle.
Kun haluat määrittää kumpaan tilaan kone seuraavissa booteissa järjestää itsensä, tarvitaan vähän erilainen komento:

Se oli kyllä siinä linkkaamassani ohjeessa...
 
Ei nuo poissulje toisiaan, se että kaikki paketit löytyy repoista tekee päivittämisestä helppoa. Ei se päivittäminen olisi helppoa jos se päivittäisi vain kernelin ja kaikki muut ohjelmistot pitäisi kaivaa päivitykset ties mistä.
Juuri se oli pointti, että et ottaisi distroa tai muuta käyttöjärjestelmää pelkän päivittämisen helppouden vuoksi, jos sillä ei voisi tehdä (helposti) mitään muuta.

Eli jos ne sulkisi toisensa pois, niin varmasti priorisoisit niitä paketteja (lue muita ominaisuuksia), etkä sitä että päivittäminen on helppoa, mutta muuta ei sitten pystykään tekemään.
 
Windows-puolella tätä voi verrata esim. Win7:n päivittämiseen Win10:ksi. Ei taida aina mennä ilman haasteita?
Mitäs haasteita tässä on? Updaten kautta päivitys pyöriin. Ei sillä että Linuxissa sen vaikeempaa nykyään olisi
 

Statistiikka

Viestiketjuista
261 063
Viestejä
4 530 667
Jäsenet
74 735
Uusin jäsen
peteokuopassa

Hinta.fi

Back
Ylös Bottom