Linux-kysymyksiä & yleistä keskustelua Linuxista

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.
 
Onko kellään kokemusta Linux videoitten editointi ohjelmista... Miten kulkee??? Entäs videon pakkaus mahdollisemman pieneksi kooltaan (mt)...
 
Onko kellään kokemusta Linux videoitten editointi ohjelmista... Miten kulkee??? Entäs videon pakkaus mahdollisemman pieneksi kooltaan (mt)...
softia editointiin löytyy useita. Löytyy ihan DaVinci Resolvesta sitten opensource kdenliveen. kdenlive varmaan se tunnetuin ja kattavin opensource editori.
 
Onko kellään kokemusta Linux videoitten editointi ohjelmista... Miten kulkee??? Entäs videon pakkaus mahdollisemman pieneksi kooltaan (mt)...
Voi toki pienentää videon kokoa noilla editointiohjelmilla tai sitten vaan ffmpegillä. Muutin itse ogv-videon mp4:ksi suoraan ja pienentyi 5 kertaa pienemmäksi. Sitten voi koittaa tiputtaa framerate tai bitratea.
 
Onko kellään kokemusta Linux videoitten editointi ohjelmista... Miten kulkee??? Entäs videon pakkaus mahdollisemman pieneksi kooltaan (mt)...
Itse tullut KDEnliveä ja Shotcut:tia käytettyä molemmat toimii oikein hyvin. Näillä myös videoiden renderöinti (pakkaus, tai miksi haluaa tätä kutsua) onnistuu suoraan käyttöliittymästä erilaisilla algoritmeillä käyttäen CPU:ta tai GPU:ta.
 
Varmaan tiedät mutta laitetaan nyt kuitenkin ihan yleisesti; mp4 on vain säiliö/container, kuten mkv, eri asia missä muodossa siellä sisällä on se itse video (esim. H.264 tai H.265).
En kyllä näistä tiedä oikein hyvin, mutta meinasin sitä, ettei tarvinnut antaa mitään parametreja ffmpegille, että pienentyi, vain tiedostopääte muuttaa. Edit. Tai mitä se sitten oikein teki oikeasti.

Luulin, ettei oma ffmpeg tue H.265:sta, kun ei man-sivuilta löydy mitään, mutta on kyllä käännetty mukaan.
 
Viimeksi muokattu:
Kiitoksia kaikille vastanneille! Pitääpä perehtyy tarkemmin noihin editointi ohjelmiin!
 
En kyllä näistä tiedä oikein hyvin, mutta meinasin sitä, ettei tarvinnut antaa mitään parametreja ffmpegille, että pienentyi, vain tiedostopääte muuttaa. Edit. Tai mitä se sitten oikein teki oikeasti.
Default näyttäisi olevan H.264. Ei ehkä kannata re-enkoodata videoita ilman mitään ohjeita, saattaa samalla esim. ääniraidankin re-enkoodata. Laatu kärsii kun re-enkoodaa jotain. Suosittelen Handbrake-softaa, siinä voi helpommin gui:n kautta säätää mitä oikeasti muutetaan ja laatuasetuksia. Äänet voi laittaa vaikka esim. "passthrough":na niin niitä ei re-enkoodata. Vaatii vähän opettelua mutta parempi kuin sokkona vetää ffmpegillä defaultilla (toki voi opetella ffmpegin salat mutta hankalampi se on). FFmpeg näyttää kyllä tietoja (input ja output tiedot) kun lähdet jotain sillä konvertoimaan.
 
Onko kellään kokemusta Linux videoitten editointi ohjelmista... Miten kulkee??? Entäs videon pakkaus mahdollisemman pieneksi kooltaan (mt)...

Blenderillä käsittääkseni onnistuu video editointi myös. Videon encoodaukseen löytyy vaihtoehtoja paljonkin. ffmpeg on varmaan monipuolisin mutta mikäli command line ajaminen tuntuu vieraalta niin sitten esim handbrake joka loppupelissä käyttää ffmpeg.
Command line puolelle löytyy sitten h264, h265 ha av1 encoodaukseen ihan niitä varten tehdyt työkalut. x264, x265 ja av1:lle svt-av1 ja rav1e noin alkuunsa. Muitakin toki on.

EDIT: Ja kun mahdollisimman pieneksi havitellaan videon kokoa, niin av1 siihen tarkoitukseen paras. Ongelmana on että kaikki laitteet ei välttämättä tue av1:stä ja encode ajat voi olla aika pitkiä. HEVC eli h265 on sitten se seuraava vaihtoehto jonka tuki on nykyisin varmaan aika pitkälti kaikissa laitteissa ellei ole ihan kivikautinen kikotin. h264 ainakin itse nykypäivänä välttäisin käyttämästä. Siitä alkaa olla jo aika ajanut ohi.

Vaatii vähän opettelua mutta parempi kuin sokkona vetää ffmpegillä defaultilla (toki voi opetella ffmpegin salat mutta hankalampi se on). FFmpeg näyttää kyllä tietoja (input ja output tiedot) kun lähdet jotain sillä konvertoimaan.

Mikäli ihan enemmän on tarkoitus touhuta encoodauksen kanssa niin ffmpeg kannattaa ehdottomasti opetella. Handbrake ei tarjoa kuin murtoosan siitä mitä mihin kaikkeen ffmpeg kykenee.
 
Mikäli ihan enemmän on tarkoitus touhuta encoodauksen kanssa niin ffmpeg kannattaa ehdottomasti opetella. Handbrake ei tarjoa kuin murtoosan siitä mitä mihin kaikkeen ffmpeg kykenee.
Jep. Mutta olettaisin, että tässä tapauksessa taitaa se Handbrake riittää enemmän kuin hyvin. FFmpegin opettelu on selvästi vaikeampaa, siinä taitaa olla joku pari miljaaardia toimintoa.. enkä itse pidä sen dokumentaatiosta (en ole varmaan kertaakaan saanut mitään hyötyä kun olen sitä tutkiskellut, aina joutunut turvautumaan jonkun muun sivuston oppaisiin/ohjeisiin/esimerkkeihin). Itse käytän molempia silloin harvoin kun tarvii jotain tehdä, ffmpegiä esim. jos pitää jotain blu-ray-rippausta täydentää jollain toisella materiaalilla (esim. kommenttiraita dvd:ltä blu-ray-julkaisuun), Handbrakea taas jos joku leffavideo pitää re-enkoodata H.265->H.264 kun oma rautamediatoistin ei tue tuota HEVC:tä, tai joskus harvoin joku arkistoitava känny/kameravideo pitää saada vähän pienemmäksi kooltaan.
 
Viimeksi muokattu:
Jep. Mutta olettaisin, että tässä tapauksessa taitaa se Handbrake riittää enemmän kuin hyvin. FFmpegin opettelu on selvästi vaikeampaa, siinä taitaa olla joku pari miljaaardia toimintoa.. enkä itse pidä sen dokumentaatiosta (en ole varmaan kertaakaan saanut mitään hyötyä kun olen sitä tutkiskellut, aina joutunut turvautumaan jonkun muun sivuston oppaisiin/ohjeisiin/esimerkkeihin). Itse käytän molempia silloin harvoin kun tarvii jotain tehdä, ffmpegiä esim. jos pitää jotain blu-ray-rippausta täydentää jollain toisella materiaalilla (esim. kommenttiraita dvd:ltä blu-ray-julkaisuun), Handbrakea taas jos joku leffavideo pitää re-enkoodata H.265->H.264 kun oma rautamediatoistin ei tue tuota HEVC:tä, tai joskus harvoin joku arkistoitava känny/kameravideo pitää saada vähän pienemmäksi kooltaan.

Docut ffmpeg kieltämättä on alkuun varsin sekavan oloiset, mutta kun pääsee jyvälle niin kyllä niiden kanssa toimeen tulee. Täytyy muistaa että ffmpeg on paljon muutakin kuin video enkooderi jonka takia siinä on tolkuttomasti vipuja. Sillä voi esim kaapata videota taikka ihan vaan muuntaa valokuvien formaattia taikka audio tiedostoja formaatista toiseen.
 
Mitäs Linuxin työpöytäympäristöjä ja ikkunointisysteemejä porukat tällä foorumilla käyttää ?

Itse olen päätynyt tässä vuosien varrella XFCE-ympäristöön, ja ikkunointiin on käytössä dwm (suckless.org). Komentorivillä saman pajan st.

Itselleni ykkösjuttu näissä on, että kaikki mahdolliset koneen resurssit aina niille sovelluksille. Ihan nyt yhtenä esimerkkinä kuvaruudulta ikkunoista pois kaikki turhat otsikkopalkit jms. kehykset -> Kun ruudulla usein helposti jopa kymmeniä ikkunoita auki, niin perinteisissä "windows"-ikkunoissa menee kauhia määrä pikseleitä ihan hukkaan. Aikoinaan laskin, että usein pahimmillaan 25-30% ruudusta (vertikaali) oli aivan hukkakäytössä juuri näihin em. turhakkeisiin :lol: Minulla on 3 fyysistä näyttöä jotka jakautuu vielä kaikki 10 "työpöytään", niin täytyy olla systeemi miten näiden välillä liikutaan ja siirrellään juttuja tehokkaasti ja toimintavarmasti. Ja yleensä vielä ilman hiirtä, koska se on turhan hidasta ja epätarkkaa. Siihen nämä tiling ikkunointisysteemit on todella hyviä ja toimivia vaihtoehtoja.
 
Työpöytäympäristöjä? :shifty:
i3 riittää.

Juu i3 on tuttu. Oikein hyvä sekin on. Omaan käteeni ja tarpeisiini dwm toimii vielä paremmin. Taitaa olla muutaman megan laihempikin, tosin näissä ollaan jo niin keveissä systeemeissä (tyyliin 3-5 MT), että ei oikein enää merkitystä. Makuasioita.

xfce on siis käytössä "taustalla" (X ei lataa itse työpöytää vaan menee suoraan dwm:ään) ihan vain siksi, että sen mukana tulee valmista grafiikkapohjaista kikkaretta yhteen jos sun toiseen juttuun mihin on tottunut.
 
Viimeksi muokattu:
Juu i3 on tuttu. Oikein hyvä sekin on. Omaan käteeni ja tarpeisiini dwm toimii vielä paremmin. Taitaa olla muutaman megan laihempikin, tosin näissä ollaan jo niin keveissä systeemeissä (tyyliin 3-5 MT), että ei oikein enää merkitystä. Makuasioita.

i3:ssa on se bonus että Sway on (niin paljon kuin on käytännössä mahdollista olla Wayland vs X) kutakuinkin 1:1 i3:n kanssa. Siinä vaiheessa kun viimeinenkin syy jumittaa Xorgissa poistuu niin ei tarvitse vaivautua opettelemaan uutta ikkunointihässäkkää.
 
Mitäs Linuxin työpöytäympäristöjä ja ikkunointisysteemejä porukat tällä foorumilla käyttää ?

Niissä joissa se tarvitaan (= jyrsinten ja sorvin ohjain) on fvwm.
Mutta niissä tarvitaankin vain linuxcnc (ja harvoin kevyt tekstieditori), ei ehkä ihan vertailukelpoinen tässä kontekstissa... ;)
 
Mitäs Linuxin työpöytäympäristöjä ja ikkunointisysteemejä porukat tällä foorumilla käyttää ?
Gnomea tullut käyteltyä viimeiset ~4 vuotta. Ei ole oikein tarvetta vaihtaa kun toimii omaan käyttöön täydellisesti. Joku Sway voisi olla kiva, mutta ei riitä aika alkaa pläräämään ja konffaamaan että saisi mieluisen.
 
Mitäs Linuxin työpöytäympäristöjä ja ikkunointisysteemejä porukat tällä foorumilla käyttää ?

Itse olen päätynyt tässä vuosien varrella XFCE-ympäristöön, ja ikkunointiin on käytössä dwm (suckless.org). Komentorivillä saman pajan st.

Itselleni ykkösjuttu näissä on, että kaikki mahdolliset koneen resurssit aina niille sovelluksille. Ihan nyt yhtenä esimerkkinä kuvaruudulta ikkunoista pois kaikki turhat otsikkopalkit jms. kehykset -> Kun ruudulla usein helposti jopa kymmeniä ikkunoita auki, niin perinteisissä "windows"-ikkunoissa menee kauhia määrä pikseleitä ihan hukkaan. Aikoinaan laskin, että usein pahimmillaan 25-30% ruudusta (vertikaali) oli aivan hukkakäytössä juuri näihin em. turhakkeisiin :lol: Minulla on 3 fyysistä näyttöä jotka jakautuu vielä kaikki 10 "työpöytään", niin täytyy olla systeemi miten näiden välillä liikutaan ja siirrellään juttuja tehokkaasti ja toimintavarmasti. Ja yleensä vielä ilman hiirtä, koska se on turhan hidasta ja epätarkkaa. Siihen nämä tiling ikkunointisysteemit on todella hyviä ja toimivia vaihtoehtoja.
Aiemmin Cinnamon, nyt KDE (5.24.4/Kubuntu). Ensin mainittu ei skaalautunut järkevästi uuden läppärin 2880x1800 näyttöön (kaikki oli joko liian suurta, pientä tai blurria ja kärsi pahasta lagista). KDE näyttää hoitavan homman siinä kuin Windowsikin. Selvästi sulavampi kuin Cinnamon ja pienellä virittelyllä tutun ja turvallisen oloinen. Vähän turhan paljon nippeliä tässä, mutta onneksi kaikkeen ei tarvi kajota.
 
Viimeksi muokattu:
Mitäs Linuxin työpöytäympäristöjä ja ikkunointisysteemejä porukat tällä foorumilla käyttää ?

Dwm:ää käytin pitkään mutta pikkuhiljaa loppui mielenkiinto siihen patchailyyn ja turhaan virittelyn ylipäätään. Dolphinistä ja muutamasta muusta KDE:n softasta olen aina pitänyt hitosti joten Plasma oli itselle luonnollinen valinta "distro/WM-hoppailuvuosien" jälkeen. Nykyään ei jaksa enää säätää :) Sama Arch asennus ollut nyt 6 vuotta ja ei taida olla tarvetta eikä mielenkiintoa distroakaan enää vaihtaa.
 
Viimeksi muokattu:
Kubuntu eli Plasma. Melkein aina yksi ohjelma koko näytöllä, niin ei mistään tiling wm:stä olisi hyötyä kaiketi. Ei mitenkään erityisesti ole kiinnostustakaan käyttikseen tehdä paljon omia muutoksia. Hyvä on, kun pysyy poissa tieltä ja hiukan kuitenkin on säätömahdollisuuksia.
 
Kubuntu eli Plasma. Melkein aina yksi ohjelma koko näytöllä, niin ei mistään tiling wm:stä olisi hyötyä kaiketi. Ei mitenkään erityisesti ole kiinnostustakaan käyttikseen tehdä paljon omia muutoksia. Hyvä on, kun pysyy poissa tieltä ja hiukan kuitenkin on säätömahdollisuuksia.

Silleempä se just pitää tehhäkki. Omien tarpeiden ja mieltymysten mukaan ne systeemit.

Itselle "tiling" taas on aivan ehdoton vaatimus. Ja hiirtä mahdollisimman vähän. Meikäläisen setup on rakennettu pelkästään toimivuutta ja tehokkuutta ajatellen näiden omien käyttämieni sovellusten näkökulmasta katsottuna. Siksi ajautunut tähän Setupiin.
 
Dwm:ää käytin pitkään mutta pikkuhiljaa loppui mielenkiinto siihen patchailyyn ja turhaan virittelyn ylipäätään. Dolphinistä ja muutamasta muusta KDE:n softasta olen aina pitänyt hitosti joten Plasma oli itselle luonnollinen valinta "distro/WM-hoppailuvuosien" jälkeen. Nykyään ei jaksa enää säätää :) Sama Arch asennus ollut nyt 6 vuotta ja ei taida olla tarvetta eikä mielenkiintoa distroakaan enää vaihtaa.

Heh joo eiköhän tuota hyppimistä ole vähän jokainen harrastanut. Ja niitä eri jakeluitahan sitten muuten riittää, jos sille tielle lähtee... Minulla on Debian ollut jo ties miten pitkään (20 vuotta ?!) ja siinä pysytään jatkossakin.

Pätsien kauttahan sitä noita suckless-sovelluksia ylläpidetään. Paatuneena vanhana C-koodarina tuo on se ainoa oikea tapa hoitaa homma :rofl: Eli tykkään oikein kovasti tästä menetelmästä. Muutenkin kun on erittäin kevyt systeemi kyseessä, niin sitä ylläpidettävääkin on sitten vastaavasti aina vähemmän. Päivitinköhän viime vuonna kertaakaan yhtään mitään... tämän vuoden alussa tuli 6.3. Muutenkin muistaakseni 2000 SLOC koko hoidossa, niin sen sielunelämän pystyy 1 koodaustaitoinen ymmärtämään ja opettelemaan helposti. Tietää tasan tarkkaan, että mistä se on tehty ja miten. Siksipähän se sitten onkin niin vakaa. Ollu ainakin omissa jutuissa. Toki helppo saada asiat sotkuunkin, jos ei tiedä mitä tekee. No solmut saa aina auki sitten yhdellä cp käskyllä + make että tuota...

Noissa graafisissa filemanagereissa en oo oikeen rakastunu koskaan mihinkään. Aina käyttänyt milloin mitäkin. Nyt taitaa olla joku SpaceFM:stä derivoitu versio käytössä. Pääasiassa siirtelen ja käsittelen tiedostoja kuitenkin komentoriviltä. Paljon kaikenlaisia itse värkättyjä automaatteja siellä apuna.
 
Pätsien kauttahan sitä noita suckless-sovelluksia ylläpidetään. Paatuneena vanhana C-koodarina tuo on se ainoa oikea tapa hoitaa homma :rofl:
Sucklessin ideologia kiehtoo kyllä edelleen ja st löytyy vieläkin koneelta. Töissä saa nykyään koodata sen verran paljon että kotikoneella saa riittää kun kerran kuukaudessa päivittää paketit. Tosin tulee nykyäänkin satunnaisesti käytyä ihailemassa r/unixporn:ssa upeita työpöytiä :)
 
Onko näillä mitään eroa:
Koodi:
sudo --login --user="juuseri" "skripti.bash"

su --login --command "skripti.bash" "juuseri"

Ja onko tuo oikea tapa ajaa jotain toisen käyttäjän tunnuksella? Ettei vaan ole mitään sudenkuoppia? Jostain sellaisista muistelen lukeneeni. Vertailin ENV ja SET komentojen ulosantia rootin ja toisen käyttäjän välillä ja se mitä ymmärrän näistä niin ei pitäisi mitään yllätyksiä tulla.

Teen tässä omaa scheduleria joka osaa ajaa missatut ajastukset. Teen ihan yksinkertaista missä on valittavana vain intervalli sekunneissa, aloituspvm & ajetaan-userina. Tarkoitus ajaa scheduleri puolen tunnin välein rootin crontabista ja omia ajastus-skriptejä voi vain sijoittaa tiettyyn kansioon ja ne ajetaan määrätyin välein (jokaisella oma intervallisäätö ja useri jolla ajetaan). Cronihan ei osaa missattuja ollenkaan ja anacronissakin on puutteita, esim. minimiajastus on yksi päivä ja se ei (ainakaan mintissä/ubuntu(?)) aja yhtään mitään jos läppäri on akun varassa. Tein jo aiemmin yhteen backup-skriptiin tällaisen toiminnon mutta nyt tuli tarvetta muillekin niin teen yleiskäyttöisen skriptin.
 
Onko näillä mitään eroa:
Koodi:
sudo --login --user="juuseri" "skripti.bash"

su --login --command "skripti.bash" "juuseri"

Ja onko tuo oikea tapa ajaa jotain toisen käyttäjän tunnuksella? Ettei vaan ole mitään sudenkuoppia? Jostain sellaisista muistelen lukeneeni. Vertailin ENV ja SET komentojen ulosantia rootin ja toisen käyttäjän välillä ja se mitä ymmärrän näistä niin ei pitäisi mitään yllätyksiä tulla.

Ei taida noin käytettynä muuta eroa olla kuin autentikoinnissa. Siihen en ota kantaa onko se oikea tapa, riippuu miten ja missä käyttää.

Teen tässä omaa scheduleria joka osaa ajaa missatut ajastukset. Teen ihan yksinkertaista missä on valittavana vain intervalli sekunneissa, aloituspvm & ajetaan-userina. Tarkoitus ajaa scheduleri puolen tunnin välein rootin crontabista ja omia ajastus-skriptejä voi vain sijoittaa tiettyyn kansioon ja ne ajetaan määrätyin välein (jokaisella oma intervallisäätö ja useri jolla ajetaan). Cronihan ei osaa missattuja ollenkaan ja anacronissakin on puutteita, esim. minimiajastus on yksi päivä ja se ei (ainakaan mintissä/ubuntu(?)) aja yhtään mitään jos läppäri on akun varassa. Tein jo aiemmin yhteen backup-skriptiin tällaisen toiminnon mutta nyt tuli tarvetta muillekin niin teen yleiskäyttöisen skriptin.

Itse olen käyttänyt systemd timereitä ajastushommiin jo vuosia. Omiin tarpeisiin enemmän kuin riittävät ajastusmahdollisuudet. En itseasiassa edes muista milloin viimeksi tarvinnut crontabiin koskea tai uhrata ajatustakaan cron daemoneille :whistling:
 
Ei taida noin käytettynä muuta eroa olla kuin autentikoinnissa. Siihen en ota kantaa onko se oikea tapa, riippuu miten ja missä käyttää.
Hmm, eikä tuo minun selostukseni sitten kertonut tarpeeksi miten sitä käyttäisin? Ja onko autentikoinnin erolla vaikutusta tarpeeseeni? En ymmärrä mitä tuo "eroa autentikoinnissa" oikein tarkoittaa.

Itse olen käyttänyt systemd timereitä ajastushommiin jo vuosia.
Eikö Poetteringin tekeleet olleetkaan itse perkeleestä? ;) Tuli nopeasti tuotakin mahdollisuutta katsottua mutta en saanut siitä oikein selvää niin se tipahti pois laskuista äkkiä kun mulla oli jo aiemmin tekemäni skripti-ratkaisu valmiina yhtä backup-tarvetta varten (jota siis vain lähdin nyt siirtämään omaksi skriptiksi). Ei sulla sattuisi olemaan hihassa jotain ihan ässä-linkkiä mistä systemd-noobi saisi jotain irti tuohon ajastukseen? EDIT: Ja onko siis systemd-ratkaisussa missatut-ajastukset toimintoa, vai miten se pelaa?

EDIT2: Katselin nopeasti tuossa tätä saittia ja näyttäisi olevan tapa missatuille ajastuksille. EDIT3: ja tietenkin archin wikistä saa tietoa.
 
Viimeksi muokattu:
Archin wikissä oli tällainen huomio:
If a timer gets out of sync, it may help to delete its stamp-* file in /var/lib/systemd/timers (or ~/.local/share/systemd/ in case of user timers). These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.
Mitäs tuo "out of sync" oikein tarkoittaa? Voiko tulla tilanne, että joku ajastus lopettaa toimintansa kokonaan kun timeri/timestamppi on "epäsynkassa"?
 
Onko näillä mitään eroa:
Koodi:
sudo --login --user="juuseri" "skripti.bash"

su --login --command "skripti.bash" "juuseri"

Ja onko tuo oikea tapa ajaa jotain toisen käyttäjän tunnuksella? Ettei vaan ole mitään sudenkuoppia? Jostain sellaisista muistelen lukeneeni. Vertailin ENV ja SET komentojen ulosantia rootin ja toisen käyttäjän välillä ja se mitä ymmärrän näistä niin ei pitäisi mitään yllätyksiä tulla.

Nuohan käyttäytyisi hyvin eri tavalla, jos ajaisit muulla käyttäjällä kuin roottina. Jälkimmäinen pyytäisi kohdekäyttäjän salasanaa, kun ensimmäinen kysyy sen hetkisen käyttäjän salasanaa ellei sudoa ole erikseen sallittuna ilman salasanaa.

Eri komentoja nuo on, vaikka saman lopputuloksen erityisesti roottina ajettuna saakin. Teoriassa voivat käyttäytyä eri tavalla riippuen asetuksista. Esim sudoers konffissa voisi olla määritettynä säilytettäväksi joitain muuttujia. su ilman tuota --login vipua säilyttäisi env muuttujat mikä ei välttämättä ole toivottua, mutta ongelmaa ei ole kun se on paikallaan.
 
Archin wikissä oli tällainen huomio:

Mitäs tuo "out of sync" oikein tarkoittaa? Voiko tulla tilanne, että joku ajastus lopettaa toimintansa kokonaan kun timeri/timestamppi on "epäsynkassa"?

Teoriassa kyllä, jos onnistut saamaan käyttöjärjestelmän kellon täysin väärään aikaan. Voidaan ajatella vaikka että kello hyppää 1kk eteenpäin, timer pyörähtää, stamp tiedoston muokkausaika on 1kk edellä todellisuutta. Korjaat kellonajan, mutta timer odottelee 1kk että stamp tiedoston aiemmin kirjoitettu muokkausaika saadaan kiinni kunnes se ajautuu taas normaalisti.
 
@dome Kiitos, oli ihan timangia settiä :), tuosta su vs. sudo asiasta tuli sellainen "doh, tietenkin" efekti. Ollut pitkään ulkoinen häiriötekijä riesana ja esim. 5 viime viikkoa on tullut nukuttua vain joku 4-5 tuntia yössä.. rupeaa olemaan aivot ihan muussina.
 
Teoriassa kyllä, jos onnistut saamaan käyttöjärjestelmän kellon täysin väärään aikaan. Voidaan ajatella vaikka että kello hyppää 1kk eteenpäin, timer pyörähtää, stamp tiedoston muokkausaika on 1kk edellä todellisuutta. Korjaat kellonajan, mutta timer odottelee 1kk että stamp tiedoston aiemmin kirjoitettu muokkausaika saadaan kiinni kunnes se ajautuu taas normaalisti.
Oolrait, kiitos tästäkin. Omassa skripti-schedulerissa käytän unix/epoch-timestamppia niin se on samalle tilanteelle altis myös. Ajattelin lähinnä, että voiko tulla tilannetta jossa joku systemd ajastus lopettaa kokonaan toimintansa.
 
Kun teet oman systemd timerin, ja laitat sinne loppuun:
Koodi:
[Install]
WantedBy=timers.target
niin bootin jälkeen se timeri aktivoituu automaattisesti? Ja se pysyy aktiivisena vaikka konetta laittaisi välillä sleep tai hibernate tilaan?

Ja Persistent=true käyttämällä onnistuu missatut ajastukset (vaatii OnCalendar tyyppistä ajastusta)? Oliko tää nyt näin yksinkertainen sittenkin?
 
Hmm, eikä tuo minun selostukseni sitten kertonut tarpeeksi miten sitä käyttäisin? Ja onko autentikoinnin erolla vaikutusta tarpeeseeni? En ymmärrä mitä tuo "eroa autentikoinnissa" oikein tarkoittaa.

Tähän vastattiinkin tuossa ylempänä kattavammin kuin itse hoksasin asiaa avata. Tuo autentikointi on siis su:n tapauksessa täysin PAMin kautta kohdekäyttäjälle, sudo nykyiselle käyttäjälle ja lisäksi sudoers konfiguroinnilla voidaan estää tai sallia asioita eri tavalla kuin mitä PAM mahdollistaa. Mutta siitä ei sen enempää, ylempänä jo käsitelty.

Eikö Poetteringin tekeleet olleetkaan itse perkeleestä? ;)

En ole kuullut kenenkään oikeasti systemd:tä käyttävän polttelevan Lennart-olkinukkeja. Ehkä jos kysyy joltakin vaahtosuiselta Debian-käyttäjältä jonka mielestä SysV on kehityksen huipentuma ja joka ei oikeasti ole vaivautunut edes kokeilemaan tai ottamaan selvää?

Tuli nopeasti tuotakin mahdollisuutta katsottua mutta en saanut siitä oikein selvää niin se tipahti pois laskuista äkkiä kun mulla oli jo aiemmin tekemäni skripti-ratkaisu valmiina yhtä backup-tarvetta varten (jota siis vain lähdin nyt siirtämään omaksi skriptiksi). Ei sulla sattuisi olemaan hihassa jotain ihan ässä-linkkiä mistä systemd-noobi saisi jotain irti tuohon ajastukseen? EDIT: Ja onko siis systemd-ratkaisussa missatut-ajastukset toimintoa, vai miten se pelaa?

EDIT2: Katselin nopeasti tuossa tätä saittia ja näyttäisi olevan tapa missatuille ajastuksille. EDIT3: ja tietenkin archin wikistä saa tietoa.

Kerkesitkin jo ilmeisesti löytää itse vastaukset näihin :thumbsup: Systemd eri man-sivut ovat aika kattavat, ja kuten monessa muussakin aiheessa Arch wiki on hyvä.

Kun teet oman systemd timerin, ja laitat sinne loppuun:
Koodi:
[Install]
WantedBy=timers.target
niin bootin jälkeen se timeri aktivoituu automaattisesti? Ja se pysyy aktiivisena vaikka konetta laittaisi välillä sleep tai hibernate tilaan?

Pitää enabloida kuten systemd servicet normaalistikin. Ts. tyyliin systemctl enable --now munakello.timer. Tuolla systemctl list-timers komennolla saa timerit listattua, jos se puuttuu listalta niin ei ole enabloitu.

Ja Persistent=true käyttämällä onnistuu missatut ajastukset (vaatii OnCalendar tyyppistä ajastusta)? Oliko tää nyt näin yksinkertainen sittenkin?

Joskus näinkin päin :tup:

Archin wikissä oli tällainen huomio:

Mitäs tuo "out of sync" oikein tarkoittaa? Voiko tulla tilanne, että joku ajastus lopettaa toimintansa kokonaan kun timeri/timestamppi on "epäsynkassa"?

Sivukommenttina, ei tarvitse etsiskellä timestamppeja kun ajelee systemctl clean --what=state ajastimen-synkka-hukassa.timer
 
Viimeksi muokattu:

Statistiikka

Viestiketjuista
259 266
Viestejä
4 507 170
Jäsenet
74 347
Uusin jäsen
Si-Pe

Hinta.fi

Back
Ylös Bottom