Linux-kysymyksiä & yleistä keskustelua Linuxista

Onko näin, että (K)Ubuntussa (22.04 LTS) ei saa esiasennettua Firefoxia asetettua oletusselaimeksi vastaamalla "Allow" ja "Yes" ainakun sitä kysytään? Ja eikö tosiaankaan esiasennettu Firefox (ilmeisesti snap-paketti) päivity kun vedän onelinerin: sudo apt update && sudo apt upgrade && sudo apt dist-upgrade? On pakko päivittää FF erikseen komennolla sudo snap refresh firefox?

Mitä v...ua?

Älkää käsittäkö väärin, pidän Ubuntusta paljon (palvelimena), mutta nyt on tässä suht lähiaikoina alkanyt vituttamaan nuo yllämainitut ongelmat, joita ei ollut silloin kun tämän Kubuntun asensin tähän koneeseen... Niin onko tämä vain Kubuntun ongelma, vai Ubuntun ongelma yleisesti?
En Ubuntussa firefoxia käytä että oletusselaimesta en osaa sanoa mutta kyllä se näyttää päivittyvän samalla kun ubuntu muutenkin
 
Jos snapcrapit ärsyttää niin Linux Mint (ubuntupohjainen) on ottanut tiukan linjan ja poistanut sen käytöstä. Lisäksi nykyään tekevät itse Firefoxista päivittyvää deb-pakettia (itse käytän kylläkin Vivaldia (vanhan kunnon Operan tekijältä) kun se on ainoa selain jota ei "tyhmennetä" koko ajan vaan tulee uusia toimintoja jatkuvasti, mistä seuraa myös sellainen hyvä sivuvaikutus, että joutuu käyttämään vain ihan muutamaa addonia (bitwarden, cookie autodelete, ublock origin). Suosittelen.
 
Onko foorumilla SSH Public Key Authenticationista kokemusta?

Minulla on ihan mystinen ongelma. Sisäverkossa kaksi Linux-konetta, loin ensimmäiseen avainparin ja lisäsin luodun Public Keyn authorized_keys tiedostoon. Tsekkasin .ssh kansion ja allaolevien tiedostojen oikeudet kuntoon, käynnistin sshd:n uudestaan ja homma toimi.

Mutta toisen koneen kohdalla ei toimikkaan. Kokeilin alkuun tehdä uuden avainparin ja toistaa ylläolevan prosessin, ei toiminut. Ajattelin, että sössin jotain avainparia luodessa ja käytin testiksi tuota toimivaksi todettua edellisen koneen kanssa, ei toimi. Kokeilin luoda kertaalleen vielä uuden avainparin, ei toimi.

sshd_config on kaikilta oleellisilta osilta identtinen (ensimmäisestä koneesta poistin PasswordAuthenticationin käytöstä, kun en sitä enää halua käyttää), käyttisversio on täysin sama (Ubuntu 20.04.4). Virheilmoitukseksi tulee aina vaan alla oleva:
Koodi:
ssh debug1: read_passphrase: can't open /dev/tty: No such file or directory

Minun silmään näyttää oikeuksiin liittyvältä ongelmalta, mutta jos vertaan ls -la komennolla noiden kansioiden oikeudet koneiden välillä, ne ovat täysin identtiset.

Ideoita?

E: Pari tuntia kaivamista ja etsimistä ja kyllä sieltä vaan löytyi yksi kansio, jossa oikeudet olivat väärin ja aiheuttivat ongelman. Nyt Public Keyt toimivat taas. Jos sitä joskus oppisi elämään näiden oikeuksien kanssa ja vaan jaksaisi lukea jokaisen kansion oikeudet huolella...
 
Viimeksi muokattu:
.ssh kansion oikeudet pitää olla 600 tai ssh ei suostu avaamaan avaimia sieltä. Se on itsellä ainakin aihauttanut vastaavan tilanteen.
 
.ssh kansion oikeudet pitää olla 600 tai ssh ei suostu avaamaan avaimia sieltä. Se on itsellä ainakin aihauttanut vastaavan tilanteen.

Oikeat oikeudet on .ssh hakemistolle 700 ja privaattiavaimelle 600. Jos .ssh hakemistolle laittaa 600 niin mikään tiedosto sen alta ei aukea vaikka niissä olisi oikeudet kunnossa koska execute bitti puuttuu. Samoin vastaanottavassa päässä authorized_keys tiedosto pitää olla 600.
 
En Ubuntussa firefoxia käytä että oletusselaimesta en osaa sanoa mutta kyllä se näyttää päivittyvän samalla kun ubuntu muutenkin

Nyt on pari viimeisintä versiota tullut vain kun on erikseen käyny komentamassa
Koodi:
sudo snap refresh firefox
. Aikaisemmin en muista, että tuota ois pitäny tehdä. Outoa...
 
Jos snapcrapit ärsyttää niin Linux Mint (ubuntupohjainen) on ottanut tiukan linjan ja poistanut sen käytöstä. Lisäksi nykyään tekevät itse Firefoxista päivittyvää deb-pakettia (itse käytän kylläkin Vivaldia (vanhan kunnon Operan tekijältä) kun se on ainoa selain jota ei "tyhmennetä" koko ajan vaan tulee uusia toimintoja jatkuvasti, mistä seuraa myös sellainen hyvä sivuvaikutus, että joutuu käyttämään vain ihan muutamaa addonia (bitwarden, cookie autodelete, ublock origin). Suosittelen.

Itellä ei oo mitään Firefoxia vastaan, vaan pidän selaimesta paljon. Pitää tutkia tuo löytyykö Ubuntullekin deb-versio FF:stä.
 
Oikeat oikeudet on .ssh hakemistolle 700 ja privaattiavaimelle 600. Jos .ssh hakemistolle laittaa 600 niin mikään tiedosto sen alta ei aukea vaikka niissä olisi oikeudet kunnossa koska execute bitti puuttuu. Samoin vastaanottavassa päässä authorized_keys tiedosto pitää olla 600.
Näinhän se oli! En tarkistanut, vaan kommentoin muistista. Kiitos korjauksesta.
 
Mintin käyttäjille: eilisen ja tämänpäivän aikana tullut päivitykset itse update manageriin (mintupdate) ja nyt tänään tuon toisen jälkeen siitä softasta on mennyt pakettien autopäivitys päälle itsekseen.. tai ainakin heti alle minuutin päästä sen päivityksen jälkeen on automaattisesti taustalla päivittänyt paketteja! Ihmettelin kun katosi kernel päivitys siitä listalta (huono aika päivittää, ei voi bootata) ja huomasin tuon pakettien autopäivityksen menneen päälle asetuksista (spices ja flatpak autopäivitykset pysyivät pois päältä). Ja kirsikkana kakun päälle, meni tuo paske nyt asentamaan jopa blacklistaamani nvidian ajuriversion. Nyt sitten pitää googlata ja säätää, että saa takaisin vanhemman version takaisin joka toimii parhaiten (kellään nopeaa vinkkiä?). Huoh. Ei ole mintti mitään tällaista perseilyä aiemmin tehnyt.
 
Pitäisi olla korjattuna mintupdate 5.8.4 versiossa joka on just julkaistu. Mutta jos kerkesitte päivittää 5.8.3:seen niin käykää laittamassa pakettien autopäivitykset pois päältä asetuksista (jos siis haluatte manuaalisesti päivittää paketteja).
 
Onko kellään mitään tietoa tästä? Googletuksella saa vähän epämääräisen kuvan/eriäviä selostuksia mitä tuo tekee.
Historialliset syyt nimenomaan. Ei tarvi välittää noista jos et esim. aja japanilaista softaa winen avulla. Vaikuttaa siihen miten terminaali tulkitsee eri merkistöjä. UTF-8 on se jota haluat käyttää. Tietokannoissa (esimerkkinä mariadb) latin1_swedish_ci (collation) tai utf8mb4 on aika turvallinen merkistökoodaus.
 
Viimeksi muokattu:
Olen nyt Nginx:ää säätäessäni saanut jotenkin koneeni resolvconfin (tai jotain muuta) menemään kai sekaisin.

Säädin Nginx:llä Let's Enrypt sertifikaatit paikallisille sisäverkon palveluille. Nyt kun kurkkasin routerin DNS-logeja niin huomasin, että palvelin soittelee muutamaan vanhaan subdomainiin muutaman sekunnin välein. Vanhat subdomainit ovat peruja siitä, kun aiemmin tein itse sertifikaatit sisäverkkoon. Mikään noissa muutaman subdomainin palveluissa ei enää viittaa noihin vanhoihin osoitteisiin. Vanhat sertifikaatit olen mielestäni kaikkialta jo siivonnut ja mielestäni mikään ei niitä edes käytä. DNS tarjoilee näille tietenkin NXDOMAIN-vastausta, mutta olisi kiva saada tuo järkyttävä spämmi DNS:lle loppumaan.

Mistä tätä kannattaisi lähteä avaamaan?

E: Jälleen korjattu, kun vaan etsi tarpeeksi pitkään. Löysin palvelun joka noihin vanhoihin domaineihin soitteli.
 
Viimeksi muokattu:
Heippa linux-hemmot! Onko /var/tmp turvallista laittaa kokonaan excludeen Timeshiftin snapshoteista? Ihmettelin kun tyhjän tilan määrä tipahti kummallisesti. Syypääksi osoittautui Audacityn tmp-tiedostot (~30GB) jotka menivät Timeshiftin snapshottiin. Tuolla var-tempissä näyttäisi olevan vain tuo ja jotain flatpak cachea.

Luulisin, että olisi turvallista laitta excludeen mutta ajattelin varmistaa kerta linux mintin tiimi ei ole sitä defaulttina lisännyt Timeshiftiin vaikka paljon muuta siellä exclude-listalla on, myös jotain var-kansiosta, mutta ei tuota tmp-kansiota.
 
Heippa linux-hemmot! Onko /var/tmp turvallista laittaa kokonaan excludeen Timeshiftin snapshoteista? Ihmettelin kun tyhjän tilan määrä tipahti kummallisesti. Syypääksi osoittautui Audacityn tmp-tiedostot (~30GB) jotka menivät Timeshiftin snapshottiin. Tuolla var-tempissä näyttäisi olevan vain tuo ja jotain flatpak cachea.

Luulisin, että olisi turvallista laitta excludeen mutta ajattelin varmistaa kerta linux mintin tiimi ei ole sitä defaulttina lisännyt Timeshiftiin vaikka paljon muuta siellä exclude-listalla on, myös jotain var-kansiosta, mutta ei tuota tmp-kansiota.

Mielestäni Linuxissa tmp sisältöä, oli se /tmp taikka /var/tmp tulee käsitellä niin että niiden sisältöä ei esim. bootin jälkeen enää ole. Mikäli joku softa ei tykkää siitä että sen jotain sontaa ei sieltä seuraavassa bootissa löydy, niin se ohjelma on silloin rikki.
Eli kyllä voit huoletta laittaa excludeen /tmp ja /var/tmp

Esim. monet distrot nykyään käyttää /tmp hakemistossa tmpfs mounttia, eli se mountataan rammiin. Tästä syystä KANNATTAA olla myös jonkinkokoinen swappi käytössä, koska silloin jos joku softa sattuu kovasti tykittämään tmp ryönää niin se menee automaattisesti swappiin eikä pysyvästi syö muistia.
 
Mielestäni Linuxissa tmp sisältöä, oli se /tmp taikka /var/tmp tulee käsitellä niin että niiden sisältöä ei esim. bootin jälkeen enää ole. Mikäli joku softa ei tykkää siitä että sen jotain sontaa ei sieltä seuraavassa bootissa löydy, niin se ohjelma on silloin rikki.
Eli kyllä voit huoletta laittaa excludeen /tmp ja /var/tmp

On noissa se ero että /var/tmp:n sisältö FHS speksin (5.15. /var/tmp : Temporary files preserved between system reboots) mukaan pitäisi säilyttää boottien yli.
 
Joo mutta se on silti tmp eli ei mitään elintärkeää pitäisi sieltä löytyä. Korkeintaan jotain cacheja jotka voidaan luoda uudelleen mikäli ne puuttuu.
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).
 
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).

Kaiken järjen mukaan ei. Tietyissä tilanteissa ihan ok säilöä väliaikaisia tiedostoja bootinkin yli jos se esim. nopeuttaa softan käynnistystä, kun ei tarvitse generoida uudestaan. Jos taas softa säilöö jotain oikeasti toiminnan kannalta tarpeellista temppidirrikassa niin se on jo surullista.
 
Saattaisikohan olla niin, että jos tuota tmp-kansiota ei otettaisi snapshottiin niin saattaisi tulla joku konflikti jos joku palauttaisi snapshotin jossa flatpakit muuttuisivat mutta tuolla tmp:ssä olevat flatpak cachet eivät? No, täytyy laittaa tuo pelkkä audacityn tmp-kansio excludeen (käyttää kyllä ihan tajuttomasti tilaa kun vähän editoi jotain äänitiedostoa).

Tuolle /tmp:n sisällön säilymiselle ei anneta mitään takeita, FHS speksaa jopa että sen ei taata säilyvän edes peräkkäisten ohjelman ajokertojen välillä.

Ja kuten mainittu, on usein tmpfs mounttina RAM-muistissa, joten sille voidaan ajella
jotain tmpreaperin tapaista joka tyhjää sitä milloin tahansa tarvittaessa. Joten jos softa laittaa sinne toimintansa kannalta olennaista, oli sitten flatpak tai ei, niin katselisin jotakin toista softaa.

Vaikka /var/tmp:lle lupaillaankin säilymistä boottien yli ja suositellaan siivottavaksi vähemmän aggressiivisesti, niin ei sinnekään mitään kriittistä ole järkevä laittaa.
 
FLATPAK_SYSTEM_CACHE_DIR
The location where temporary child repositories will be created during pulls into the system-wide installation. If this is not set, a directory in /var/tmp/ is used. This is useful because it is more likely to be on the same filesystem as the system repository (thus increasing the chances for e.g. reflink copying), and we can avoid filling the user's home directory with temporary data.

Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.
 
Githubissa joku 5 vuotta auki ollut issue noista flatpak cacheista kun eivät aina siivoudu automaattisesti.

Harmillisesti ei käy ilmi koskeeko tuo flatpakia yleisesti, vaiko joillakin tietyillä distroilla tai erityisiä käyttötapauksia. Luulisi että sille olisi tehty jotakin jos se olisi yleisempikin ongelma.

Ainakin systemd pohjaisissa distroissa todennäköisesti käytetään systemd-tmpfilesiä temppihakemistojen hanskaukseen ilman erillisiä tmpreapereita tai vastaavia.

Siinä näyttäisi oletuksna olevan /var/tmp konfiguroitu siivottavaksi 30 päivää vanhemmasta tauhkasta (pl. abrt ja systemd:n private tmpit). Ellei siis tuota ole jotenkin konfiguroitu eri tavalla distrossa tai flatpak käy käpistelemässä vanhojakin cachejaan tämän tästä, ettei noin pääsisi silloin käymään.


Mutta jos flatpak käyttää tuota oikein pelkkänä cachena uusien imagejen hakemisessa niin ei pitäisi olla ongelmaa vaikka snapshotista se puuttuisikin kokonaan. Jos on niin flatpak lienee rikki tältä(kin?) osin.
 
Mutta jos flatpak käyttää tuota oikein pelkkänä cachena uusien imagejen hakemisessa niin ei pitäisi olla ongelmaa vaikka snapshotista se puuttuisikin kokonaan. Jos on niin flatpak lienee rikki tältä(kin?) osin.
Jep. Pitää laittaa nuokin excludeen. Ja lisäksi vielä ajastus noiden poistamiseen, pitää vain varmistaa, että flatpak ei ole ajossa samaan aikaan kuten tuolla issuessakin varoitettiin.
 
Jep. Pitää laittaa nuokin excludeen. Ja lisäksi vielä ajastus noiden poistamiseen, pitää vain varmistaa, että flatpak ei ole ajossa samaan aikaan kuten tuolla issuessakin varoitettiin.

Tuostahan voisi myös katsoa onko se temppfilejen siivous konffattu järkevästi distrossa. Jos siinä ei ongelmaa mutta siivousväli liian pitkä niin noillehan voi lisätä oman säännön lyhyemmällä ajalla. Toki voi myös tutkiskella sen cachen sisältöä että onko siellä vanhallakin roinalla mtime, atime tai ctime suhteellisen tuore joka voisi hämätä tuon ikään perustuvan siivoamisen. Lisäksi ainakin systemd-tmpfiles mahdollistaa tuon vanhenemisen määritykseen käytettävän timestampin valinnan.

Riippuu toki mielenkiinnon ja viitsimisen asteesta, noin itse lähtisin sipulia kuorimaan pääasiassa siksi että minulle tulee sankkeri tämänkaltaisista synkistä häkeistä ja välttelisin mikäli mahdollista.
 
Tuostahan voisi myös katsoa onko se temppfilejen siivous konffattu järkevästi distrossa. Jos siinä ei ongelmaa mutta siivousväli liian pitkä niin noillehan voi lisätä oman säännön lyhyemmällä ajalla.
En jaksa noin syvälle sukeltaa kyllä nyt. EDIT: En oikein tietäisi mistä aloittaa.. toki jonkun journalctl:n koon osaan katsoa (1.1GB näyttäisi olevan). Ainoastaan yhdessä flatpak-cache-kansiossa oli tavaraa n. 4GB verran ja tiedostot näytti olevan helmikuun tienoilta. Eli ei taida mitään distron autosiivousta olla ainakaan noihin. Laitan siivouksen samaan omaan skriptiini jolla hallinnoin flatpak päivityksiä (osa automaattisesti, osasta vain ilmoitukset, jne.), se riittää mulle tällä kertaa.

EDIT2: Se olikin viesti nro 2000.. paljon on aikaa täälläkin tullut vietettyä. :)
 
Heips taas. Kirjoittelin tänne hiljattain locale-asioista ja tarkemmin LC_COLLATE:n muuttamisesta. Tein silloin muutoksen komennolla sudo update-locale LC_COLLATE=fi_FI.UTF-8 ja boottauksen jälkeen kaikki näytti olevan ok. Nyt eilen huomasin, että tiedostosorttaus näytti taas ääkköset ennen a:ta ja vilkaisu locale-komennolla paljasti, että LC_COLLATE on automaattisesti mennyt jossain vaiheessa takaisin "en_US.UTF-8"-arvoksi.

Milläs saan tuon varmasti pysyväksi? Lisäämällä jotain ~/.bashrc-tiedostoon?
 
Heips taas. Kirjoittelin tänne hiljattain locale-asioista ja tarkemmin LC_COLLATE:n muuttamisesta. Tein silloin muutoksen komennolla sudo update-locale LC_COLLATE=fi_FI.UTF-8 ja boottauksen jälkeen kaikki näytti olevan ok. Nyt eilen huomasin, että tiedostosorttaus näytti taas ääkköset ennen a:ta ja vilkaisu locale-komennolla paljasti, että LC_COLLATE on automaattisesti mennyt jossain vaiheessa takaisin "en_US.UTF-8"-arvoksi.

Milläs saan tuon varmasti pysyväksi? Lisäämällä jotain ~/.bashrc-tiedostoon?
Pistä /etc/locale.conf tai /etc/default/locale tuo LC_COLLATE=fi_FI.UTF-8 ja sitten aja locale-gen (mahdollisesti sudolla)

e: Enpä olekkaan varma onko tuo oikea ratkaisu, pikagooglaus taisi mennä mönkään. Mutta ehkä antaa suuntaa :D
e2: ehkä nyt
e3: Ubuntu/Debian käyttää /etc/default/locale
 
Viimeksi muokattu:
Ja jottei mene pelkästään voittopuoleisesti avun pyytämiseksi tässä ketjussa vierailu, tässä vinkki miten jonkun GUI-softan voi avata niin, että sen ikkunaan tulee fokus ja se laitetaan "always on top" tilaan. Testattu linux mintissä.

Esimerkissä avataan gnome-calculator:

bash -c 'gnome-calculator & PIDVAR=$!; sleep 0.3; WINDOWIDVAR=$( wmctrl -lp | grep $PIDVAR | tail -1 | cut -d " " -f 1 ); wmctrl -i -a "$WINDOWIDVAR"; wmctrl -i -r "$WINDOWIDVAR" -b toggle,above'

Aiemmin käytin vähän yksinkertaisempaa tapaa avata kalkkulaattori "on-top"-tilaan mutta se ei toiminut jos avasi enemmän kuin yhden laskimen, tuo yllä oleva ratkaisu toimii vaikka avaa kuinka monta laskin-ikkunaa. Sen pitäisi myös toimia sellaisten softien kanssa jotka avaavat uuden ikkunan saman PID:llä (esim. mintin tiedostohallintasofta Nemo). Sleep-komennon arvoa saattaa joutua muuttamaan isommaksi jos kone/levy on hitaampi kuin minulla, itsellä toimi 0.2 sekunnin asetus mutta laitoin varmuudeksi pikkaisen isomman tauon, että toimii varmasti omalla koneella. Sleep-komento on tarpeellinen, muuten sitä seuraava komento ei toimi kunnolla ja kaikki loputkin komennot feilaa.

Tuon voi laittaa sitten vaikka näppäimistö-shortcutiksi, esim. jos näppäimistöstä löytyy laskin-nappi.
 
Ja tämän muokkaus jää varmasti pysyväksi, ettei taas revertoidu jossain myöhemmässä vaiheessa kun OS tekee/päivittää jotain?
apt kysyy päivittäessä jos löytää ristiriitoja konffifiluissa ja kysyy kumpi versio pidetään. En kyllä suoriltaan osaa sanoa että koskisiko mikään tuohon filuun vai ei. Voit myös vaihtoehtoisesti laittaa käyttäjäkohtaisesti sen tiedostoon ~/.bash_profile:
Koodi:
LC_COLLATE=fi_FI.UTF-8
export LC_COLLATE
 
Voit myös vaihtoehtoisesti laittaa käyttäjäkohtaisesti sen tiedostoon ~/.bash_profile
Mulla ei tuota löydy. .profile tiedosto löytyy. Siellä sanotaan alussa näin:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.

Eli varmaankin .profile loppuun mainitsemasi komennot?
 
~/.pam_environment myös löytyy ja siellä on jo:

Koodi:
LC_NUMERIC=fi_FI.UTF-8
LC_TIME=fi_FI.UTF-8
LC_MONETARY=fi_FI.UTF-8
LC_PAPER=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
PAPERSIZE=a4
LANGUAGE=en_US
LANG=en_US.UTF-8

Ihmeen monimutkainen juttu (moneen paikkaan kait voi muuttaa mutta ne saattaa toimia eri tavalla/tilanteissa?) miten tän sais pysyvästi muutettua.
 
Ihmeen monimutkainen juttu (moneen paikkaan kait voi muuttaa mutta ne saattaa toimia eri tavalla/tilanteissa?) miten tän sais pysyvästi muutettua.

Oletko kokeillut vain sudo localectl set-locale LC_COLLATE=fi_FI.UTF-8? Pitää muistaa myös että vaikka järjestelmän localen asettaakin jiiriin niin nuo internetin velhojen shellien profiilien ja rc filejen puukotukset joissakin tilanteissa ylikirjoittaa järjestelmätason asetukset. Luonnollisesti ei välttämättä kaikissa.
 
Oletko kokeillut vain sudo localectl set-locale LC_COLLATE=fi_FI.UTF-8?
En muista nyt enää kokeilinko tuota silloin aiemmin. Täytyy kokeilla (myöhemmin tänään, nyt ei pysty hetkeen boottaamaan). Kyselen vain tarkasti näistä nyt kun aiemmin sudo update-locale LC_COLLATE=fi_FI.UTF-8 ei ollutkaan pysyvä muutos vaikka ensimmäisen bootin jälkeen toimikin.

internetin velhojen shellien profiilien ja rc filejen puukotukset joissakin tilanteissa ylikirjoittaa järjestelmätason asetukset
Joo, tiedossa on, kiitos kuitenkin muistutuksesta. Olen pari muutosta .bashrc:hen tehnyt (terminaalin ikkunoiden titlet muuttanut ja laittanut completion-ignore-case päälle) mutta ne eivät tähän asiaan vaikuta.
 
Olen asentamassa linux mint ja kysyisin tosta nvidian ajureista onko vaikeaa saada ajurit asennettua? korttina 3060
 
Olen asentamassa linux mint ja kysyisin tosta nvidian ajureista onko vaikeaa saada ajurit asennettua? korttina 3060
Eipä ne vaikeita ole, tosin jos on yhtään tuoreemmalla raudalla varustettua konetta niin asentaisin ihan jotain muuta kuin Mint:n.
 
Okei, miksi? prossu ryzen 5 3400g ja gtx 3060
Yksi syy voisi ainakin olla se, että Linux Mint käyttää yleisesti vanhaa kerneliä, johon on käännetty kaikki mahdollinen roska mukaan moduleina. Uudesta raudasta tunnetusti saa enemmän irti uusilla ja/tai optimoiduilla kerneleillä.

Myös softa on käytännössä aina vanhaa Mintissä, mutta tämä nyt ei välttämättä liity mitenkään nopeuteen, mutta yleiseen käyttökokemukseen kylläkin.
 
Yksi syy voisi ainakin olla se, että Linux Mint käyttää yleisesti vanhaa kerneliä, johon on käännetty kaikki mahdollinen roska mukaan moduleina. Uudesta raudasta tunnetusti saa enemmän irti uusilla ja/tai optimoiduilla kerneleillä.

Myös softa on käytännössä aina vanhaa Mintissä, mutta tämä nyt ei välttämättä liity mitenkään nopeuteen, mutta yleiseen käyttökokemukseen kylläkin.
Näyttäisi siltä että uusimmassa Mint 21 versiossa on kyllä kerneliversio 5.15 mikä on aika tuore. Tuo prossu on vuodelta 2019 joten tuskin ainakaan sen kanssa tulee mitään ongelmia.
 
Näyttäisi siltä että uusimmassa Mint 21 versiossa on kyllä kerneliversio 5.15 mikä on aika tuore. Tuo prossu on vuodelta 2019 joten tuskin ainakaan sen kanssa tulee mitään ongelmia.
Kyllä, mutta jos katsotaan tilannetta Mint 21 tukiajan lopussa 2027, niin 5.15 kerneli ei olekaan enää niin tuore. Tuskin tosiaan yhteensopivuus ongelmia on minkään raudan kanssa, koska Linux Mint käyttäjä saa toki tuen kaikelle mitä kernelistä löytyy. Tällä on toki kääntöpuolensa, koska tämä hidastaa konetta huomattavasti. Myös uudempi rauta (prossu, emolevy, ulkoiset laitteet jne.) hyötyy toki aina eniten kernelin kehityksestä. Uskon, että Ryzen prossut tulevat saamaan huomattavasti enemmän kehittäjien aikaa seuraavan viiden vuoden aikana, kuin vaikka Athlon prossut, vaikka molemmat on tuettuja.
 
Itsellä käytössä Debian/Stable, joka on tunnettu vanhoista sovellusversioista, mutta on myös sen vuoksi erittäin vakaa, niin siihen saa backporttauksen kautta jo 5.18 kernelin. Uusimman kernelin saa siis yleensä muutamien kuukausien viiveellä, mikä on toisaalta ihan hyväkin vakauden kannalta. Ei ole ollut ongelmia uusien rautojen kanssa. Empä usko, että yksikään Debian-jakeluun pohjautuva toinenkaan jakelu tekee tähän suurta poikkeusta (esim. Mint).

Toki optiona on aina asentaa Debian/Unstable (Sid) versio, niin siinä on sitten kaikki huonosti testatut viimeisimmät kotkotukset mukana. Ja sitten on yleensä (ei aina) mahdollisuus käännellä niitä softia itsekin jos jotain puuttuu. Näin saat sitten sen viimeisimmänkin Kernelin vaikka heti. Riippuen tekijästä tässä saattaa joskus olla sitten vähän enempi sitä jumppaa :rofl: ja proprietary softat on sitten pois laskuista.

Itse päädyin aikoinaan Debianiin, koska aika monet muut distrot pohjautuu siihen. Eikä syyttä ;) Eikä tuo jakelu ole Phoronixin nopeustesteissäkään ihan huonosti pärjäillyt. Sanoisin, että oikein hyvä Daily Driver käyttis. Dokumentaatio ja muu sosiaalisen median tukihan on myös erittäin kattava.

Asennuksen jms. käytön helppoudesta en sitten lähde analysoimaan, kun itsellä on tuota Linux-taustaa jo 90-luvun puolelta lähtien (=paatunut CLI-henkilö), niin saatan nähdä ja kokea asioita vähän eri valossa, kuin ehkä joku tuoreempi tapaus... ATK-neitsyyskin meni jo 80-luvun alussa.
 
Viimeksi muokattu:
Täällä Linux Mint Cinnamon 20.3 (ensiasennus taisi olla 20.0), rautana peliläppäri jossa Nvidian RTX2060. Ihan tyytyväinen olen, paitsi Nvidian linux ajureiden laatuun. Käsittääkseni kuitenkin jos haluaa nitistää viimeiset tehotipat raudasta peleihin niin dual-boottiin winkkari. Olen muutamaa peliä pelannut linux-puolella (lähinnä 3rd person point&click seikkailut + yksi kevyt FPS) ja vaativammat pelit on pyörinyt dual bootin win10:ssä josta olen kiristänyt kaikki turhat pois (esim. virustorjunta pois kokonaan). Hibernate-toiminto linuxin puolella on toiminut lähes täydellisesti (ainahan joskus on jotain snägää kaikessa, suurin syypää Nvidian ajuri tässäkin asiassa, mutta jos löytää hyvän version niin ei ole ongelmia) joten boottaus winkkariin ja takaisin on nopea toimenpide nvme-levyn kanssa.

Linux Mintin Update Managerin kerneleiden hallinnointi:

mint.jpg


Toki ei varmaan ole taattua, että 100% toimii uudetkin kernelit, mutta aina voi koittaa.

Lisäksi Mintistä on "Edge"-versio.
This image ships with newer components to be able to support the most modern hardware chipsets and devices.
 
Täällä Linux Mint Cinnamon 20.3 (ensiasennus taisi olla 20.0), rautana peliläppäri jossa Nvidian RTX2060. Ihan tyytyväinen olen, paitsi Nvidian linux ajureiden laatuun. Käsittääkseni kuitenkin jos haluaa nitistää viimeiset tehotipat raudasta peleihin niin dual-boottiin winkkari. Olen muutamaa peliä pelannut linux-puolella (lähinnä 3rd person point&click seikkailut + yksi kevyt FPS) ja vaativammat pelit on pyörinyt dual bootin win10:ssä josta olen kiristänyt kaikki turhat pois (esim. virustorjunta pois kokonaan). Hibernate-toiminto linuxin puolella on toiminut lähes täydellisesti (ainahan joskus on jotain snägää kaikessa, suurin syypää Nvidian ajuri tässäkin asiassa, mutta jos löytää hyvän version niin ei ole ongelmia) joten boottaus winkkariin ja takaisin on nopea toimenpide nvme-levyn kanssa.

Linux Mintin Update Managerin kerneleiden hallinnointi:

mint.jpg


Toki ei varmaan ole taattua, että 100% toimii uudetkin kernelit, mutta aina voi koittaa.

Lisäksi Mintistä on "Edge"-versio.
5.4 on vuodelta 2019 joten jo hiukan vanhempi, mutta jos kaikki toimii niin eipä sitä nyt välttämättä ole mitään syytä päivittää. Tuo on kuitenkin LTS versio ja se tulee saamaan security päivityksiä vielä pitkään.
 
Olen muutamaa peliä pelannut linux-puolella (lähinnä 3rd person point&click seikkailut + yksi kevyt FPS) ja vaativammat pelit on pyörinyt dual bootin win10:ssä...
Oletkos kokeillut Linuxissa Bottles zydeemiä ?
Itsellä on ollut tuosta hyvät kokemukset. Valitsemalla sovellustyypiksi "gaming", niin se luo Wine-ympäristön mikä on "räätälöity" pienemmillä latensseilla ja muilla asiaan liittyvillä ominaisuuksilla mm. pelaamiseen. Itse en pelaile, mutta olen käyttänyt tuota graafisten sovellusten kanssa, ja saanut niitä toimimaan huomattavasti jouhevammin vrt. normaali Wine-asennus. Samaan siis varmaan pääsee, kun tietää mitä tekee Winen kanssa (asetukset, muut viritykset), mutta Bottlesista on se etu, että siellä on kehitystiimi joka tekee sen puolestasi. Sisältää muuten vaihtoehtoina mm. Proton GE:n.
 
5.4 on vuodelta 2019 joten jo hiukan vanhempi, mutta jos kaikki toimii niin eipä sitä nyt välttämättä ole mitään syytä päivittää. Tuo on kuitenkin LTS versio ja se tulee saamaan security päivityksiä vielä pitkään.
Joo, ei ole mulla ole ollut mitään tarvetta uudempaa kernelia kokeilla. Ja tuohon 5.4:seen tulee koko ajan päivityksiä, eikä ole pelkästään turvapäivityksiä (changelogit monesti todella pitkiä... käyn niitä aina läpi sellaisella harvahampaisella kammalla :) ).
 
Viimeksi muokattu:
Oletkos kokeillut Linuxissa Bottles zydeemiä ?
En vielä, on ollut jonkun aikaa todo-listalla tuo koko wine-homma ja tuo Bottles joka alkuvilkaisulla näytti ihan kätevältä. Mulla on aika verkkainen tahti tässä mun win->linux-siirtymässä, paljon on vielä todo-listalla asioita. Viimeksi selvitin Nemon Actions-toiminnot ja tein hiiren oikean napin valikkoon pari omaa juttua (aiemmin oli "Scripts"-alivalikossa, Actions parempi kun näkyy heti siinä "pää"valikossa, ja sai ikonitkin laitettua). Lisäksi tutkin mimetyyppejä ja tein checksum-tiedostoille custom mimetyypin ja oletussoftan/skriptin joka ajetaan kun sellaista tiedostoa tuplaklikataan (= checksum tsekkaus omalla skriptillä (taustalla rhash-softa) terminaali-ikkunassa).
 
Yksi syy voisi ainakin olla se, että Linux Mint käyttää yleisesti vanhaa kerneliä, johon on käännetty kaikki mahdollinen roska mukaan moduleina. Uudesta raudasta tunnetusti saa enemmän irti uusilla ja/tai optimoiduilla kerneleillä.

Myös softa on käytännössä aina vanhaa Mintissä, mutta tämä nyt ei välttämättä liity mitenkään nopeuteen, mutta yleiseen käyttökokemukseen kylläkin.

Ja sillähän nyt ei ole yhtään mitään merkitystä että on kaikki mahdollinen "roska" käännetty kernel moduuleina mukaan. Ainut "ongelma" on että ne vie hiukan tallennustilaa.
Aivan samoin tehdään suurimmassa osassa distroja. Se vaan on hallittavuuden kannalta paljon helpompaa. Joskus on tullut nysvätty ja käännettyä kernelit itse ja natiivisti mukaan tasan tarkkaan se mitä rautaa koneessa on. Sekin on ihan fine jos jaksaa säätää mutta jos rauta vaihtuu useasti niin varsin työläs tapa.
Mitä sitten tulee module vs native niin suorituskyvyn suhteen käsittääkseni ei juurikaan ole eroa.

On toki totta että jos jaksaa nysvätä ja kääntää kernelin itse prossu optimointi vipujen kanssa niin saa lypsettyä hiukan suorituskykyä lisää, mutta tämä on työlästä ja kerneli on sitten taas lukittu siihen prossu geniin, saattaa toimia uudemmilla tai sitten ei. Phoronix joskus noita testasi ja ei ainakaan omasta mielestä tuonut niin paljoa suorituskykyä että olisi vaivan arvoista.
6.0 kerneli tulee tuomaan vauhtia lisää aika kivasti verrattuna 5.x kerneliin joten sitä odotellessa.

EDIT: niin ja en tosiaan ainakaan itse yöunia menetä sen takia että on ylimääräistä "roskaa"
Koodi:
du -sh /lib/modules/5.18.11-200.fc36.x86_64/
127M    /lib/modules/5.18.11-200.fc36.x86_64/

127MB ei tänäpäivänä ole mitään.
 
Ja sillähän nyt ei ole yhtään mitään merkitystä että on kaikki mahdollinen "roska" käännetty kernel moduuleina mukaan. Ainut "ongelma" on että ne vie hiukan tallennustilaa.
Aivan samoin tehdään suurimmassa osassa distroja. Se vaan on hallittavuuden kannalta paljon helpompaa. Joskus on tullut nysvätty ja käännettyä kernelit itse ja natiivisti mukaan tasan tarkkaan se mitä rautaa koneessa on. Sekin on ihan fine jos jaksaa säätää mutta jos rauta vaihtuu useasti niin varsin työläs tapa.
Mitä sitten tulee module vs native niin suorituskyvyn suhteen käsittääkseni ei juurikaan ole eroa.

On toki totta että jos jaksaa nysvätä ja kääntää kernelin itse prossu optimointi vipujen kanssa niin saa lypsettyä hiukan suorituskykyä lisää, mutta tämä on työlästä ja kerneli on sitten taas lukittu siihen prossu geniin, saattaa toimia uudemmilla tai sitten ei. Phoronix joskus noita testasi ja ei ainakaan omasta mielestä tuonut niin paljoa suorituskykyä että olisi vaivan arvoista.
6.0 kerneli tulee tuomaan vauhtia lisää aika kivasti verrattuna 5.x kerneliin joten sitä odotellessa.

EDIT: niin ja en tosiaan ainakaan itse yöunia menetä sen takia että on ylimääräistä "roskaa"
Koodi:
du -sh /lib/modules/5.18.11-200.fc36.x86_64/
127M    /lib/modules/5.18.11-200.fc36.x86_64/

127MB ei tänäpäivänä ole mitään.
Juu, joskus Pentiumin alkuaikoina tuli vielä itse käänneltyä kerneleitä kun silloin siitä hommasta vielä sai hyötyäkin jonka oikeasti jopa huomasi. Nykyään kun prossussa on tehoa ja muistia riittää jne niin eipä tuolla kernelin kääntämisellä taida ihmeitä saavuttaa ellei ole joku hyvin spesiaali kokoonpano joka ei oikein muuten toimi.
 
Ja sillähän nyt ei ole yhtään mitään merkitystä että on kaikki mahdollinen "roska" käännetty kernel moduuleina mukaan. Ainut "ongelma" on että ne vie hiukan tallennustilaa.
Aivan samoin tehdään suurimmassa osassa distroja. Se vaan on hallittavuuden kannalta paljon helpompaa. Joskus on tullut nysvätty ja käännettyä kernelit itse ja natiivisti mukaan tasan tarkkaan se mitä rautaa koneessa on. Sekin on ihan fine jos jaksaa säätää mutta jos rauta vaihtuu useasti niin varsin työläs tapa.
Mitä sitten tulee module vs native niin suorituskyvyn suhteen käsittääkseni ei juurikaan ole eroa.

On toki totta että jos jaksaa nysvätä ja kääntää kernelin itse prossu optimointi vipujen kanssa niin saa lypsettyä hiukan suorituskykyä lisää, mutta tämä on työlästä ja kerneli on sitten taas lukittu siihen prossu geniin, saattaa toimia uudemmilla tai sitten ei. Phoronix joskus noita testasi ja ei ainakaan omasta mielestä tuonut niin paljoa suorituskykyä että olisi vaivan arvoista.
6.0 kerneli tulee tuomaan vauhtia lisää aika kivasti verrattuna 5.x kerneliin joten sitä odotellessa.

EDIT: niin ja en tosiaan ainakaan itse yöunia menetä sen takia että on ylimääräistä "roskaa"
Koodi:
du -sh /lib/modules/5.18.11-200.fc36.x86_64/
127M    /lib/modules/5.18.11-200.fc36.x86_64/

127MB ei tänäpäivänä ole mitään.
Siinä olet täysin oikeassa, että moduulien määrällä ei ole merkitystä, jos kerneliä verrataan toiseen samanlaiseen, missä on stokki conffi ja kaikki modulit päällä. Näitä sitten ladataan bootissa tai ajon aikana raudan mukaan. Käyttäjäystävällistä, nopeaa ja vie vain vähän tilaa, helppo ylläpitää.

Itse kyllä kuitenkin väittäisin, että näillä moduleilla ja niiden lataamismahdollisuudella on merkitystä. Sadat äänikorttien, webcamien, näytönohjainten, jne. modulit on täysin turhaa roskaa serverikoneessa. Nämä tuhannet turhat modulit ja niiden lataus mahdollisuus on myös ihan aito tietoturvariski. Rootkitit on monesti juurikin kernel moduleita, jotka mukavasti ladataan roottauksen jälkeen lennossa kerneliin ja luodaan modprobe tiedostot bootteja varten jne. Jos haluaa tältä suojautua, niin ainoa täysin varma vaihtoehto on disabloida LKM tuki kernelistä ja kääntää kaikki tarvittava suoraan kerneliin. Yleensä kernel modulien tärkeyteen havahtuu siinä kohdassa, kun sisäverkon koneella ajettu rkhunter löytää rootkitin, vaikka kyseiselle koneelle ei pitänyt olla pääsyä muualta, kuin lokaalista verkosta.

Itse tulee nykyäänkin jotain kerneleitä käännettyä viikko/kuukausi tasolla, eikä se nyt ihan maailman lopun hommaa ole. Käännän siis suoraan rpm paketteja, jotka asentuu lokaaleista repoista sinne minne pitääkin. Eli käytännössä puhutaan muutaman komennon suorittamisesta, kun on haluttu conffi ja patchit valmiina.

Jos sattuu olemaan uudehkoa Intel rautaa koneessa niin voi asentaa vaikka ClearLinuxin rinnalle ja testata, että huomaako Intel optimoidussa distrossa nopeudessa eroa verrattuna nykyiseen distroon. Itse tuli aikanaan kokeiltua ja yllätyin. Oli pakko ottaa heidän kernel patcheja käyttöön myös omiin kerneleihin. Eli hatunnosto Arjan van de Ven:ille (ja muille), kyllä Intelin tyypit selkeästi tuntee rautansa.

Näyttää olevan muuten ensimmäinen kernel 6.0.0 rc1 buildi jo fedoraan saatavilla. Eli kyllähän sitä pääsee toki jo ilman kääntämistä testaamaan, jos haluaa.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
301 412
Viestejä
5 130 796
Jäsenet
81 984
Uusin jäsen
Sokka

Hinta.fi

Back
Ylös Bottom