Linux kysymyksiä

[Dehir]

Kubuntu 22.10:n kun päivitin, niin tuli Pipewire Pulseaudion tilalle ja mukana tuli kaksi vikaa. Kun avasin tekemäni Java-ohjelman, niin kaikkien muiden ohjelmien äänet alkoi kuulostamaan vammaselta. Ja toinen oli, että aina vaikka videon katsomisen jälkeen tuli pieni ääni, kun äänilähde meni kiinni tai jotain. Joskus se taas jäi päälle ja kuului jotain ininää. Ongelma ratkesi ottamalla Pulseaudio taas käyttöön. Tulikohan Pipewire keskeneräisenä käyttöön, vähän sama juttu kuin Waylandilla.

Kyllähän se pipewire taitaa olla vielä aika kokeellinen kehityksen osalta. Tai vaikka core elementit oliskin suht "vakaita" ongelmaksi näissä muodostuu aina legacy/modernien softien tuen päivittäminen. Käytännössähän homman pitäisi mennä eri välikerrosten kautta eli nyt vaikka pulseaudio <-> pipewire. Ellei sitten kirjoiteta suoraa tukea, mutta vähemmän päivityksiä saavien softien kohdalla tätä tuskin kannattaa odottaa eli tosielämässä olet enemmän tai vähemmän riippuvainen rikkoutuvista/latencyä aiheuttavista layereistä.

Parhaimmillaan itse toivoisin että pipewiresta tulisi joskus Applen coreaudion tasoinen "Se vaan toimii" ratkaisu joka mahdollistaisi helppokäyttöisemmän. Varsinkin musiikkipuolen softan ja laitteiden kytkemisen käyttämisen linuxilla. Eli tarjoaisi jackd:n tasoista nollalatencya helppokäyttöisesti. (Periaatteessahan tuon pipewiren sai jotenkin linkitettyä jackd tällä hetkellä.)

Mitä tulee tuohon waylandiin niin kyllähän tuo pipewire on nimenomaan askel myös oikeaan suuntaan siinä rinnalla waylandiinkin siirryttäessä.

 

[Karonkka]

Kyllähän se pipewire taitaa olla vielä aika kokeellinen kehityksen osalta. Tai vaikka core elementit oliskin suht "vakaita" ongelmaksi näissä muodostuu aina legacy/modernien softien tuen päivittäminen. Käytännössähän homman pitäisi mennä eri välikerrosten kautta eli nyt vaikka pulseaudio <-> pipewire. Ellei sitten kirjoiteta suoraa tukea, mutta vähemmän päivityksiä saavien softien kohdalla tätä tuskin kannattaa odottaa eli tosielämässä olet enemmän tai vähemmän riippuvainen rikkoutuvista/latencyä aiheuttavista layereistä.

Parhaimmillaan itse toivoisin että pipewiresta tulisi joskus Applen coreaudion tasoinen "Se vaan toimii" ratkaisu joka mahdollistaisi helppokäyttöisemmän. Varsinkin musiikkipuolen softan ja laitteiden kytkemisen käyttämisen linuxilla. Eli tarjoaisi jackd:n tasoista nollalatencya helppokäyttöisesti. (Periaatteessahan tuon pipewiren sai jotenkin linkitettyä jackd tällä hetkellä.)

Mitä tulee tuohon waylandiin niin kyllähän tuo pipewire on nimenomaan askel myös oikeaan suuntaan siinä rinnalla waylandiinkin siirryttäessä.

En ymmärrä Pipewiren toiminnallisuudesta juuri mitään. Tällä hetkellähän se tarvitsee toimiakseen useita paketteja käytettävän ääniajurin mukaan. Pipewire-pulse, pipewire-jackd tai pipewire-alsa tarvitaan toimiakseen.

Koska pipewire ei ole ainakaan täysin itsenäinen (standalone) ratkaisu, niin millä termillä sitä pitäisi kutsua?

Olen käyttänyt pipewire-pulsea ja wireplumberia xorgissa jo liki 1,5 vuotta enkä ole havainnut mitään ketjussa puhuttuja ongelmia. Päinvastoin, pulseaudiolla varsinkin bluetooth-kuulokkeet vaativat kikkailua lähes päivittäin ja siksi pipewire kokeiluun tulikin.

Oliko Ubuntu vai Fedora joka pari viikkoa ilmoitti siirtyvänsä pipewireen? Tarkoittaako se positiivisia askeleita kehitykseen?

 

[archy]

Oliko Ubuntu vai Fedora joka pari viikkoa ilmoitti siirtyvänsä pipewireen? Tarkoittaako se positiivisia askeleita kehitykseen?

Fedora on käyttäny pipewireä vakiona jo oliko versiosta 34 lähtien, ja oli samalla ensimmäinen joka tuon otti käyttöön, kuten Fedoralla on tapana. Ubuntu taisi siirtyä pipewireen 22.10 julkaisussaan.

 

[kaakau<"'\\/>]

Et ole testannut tmuxia tmux-resurrect (+ tmux-continuum) plugareilla?
Resurrectilla voi tallentaa ja palauttaa tmux-session, pitäisi osata jopa Vim-sessio palauttaa (tästä ei kokemusta kun en vimiä käytä). Continuumilla saa automatisoitua tallennuksen ja palautuksen.

Muutenkin henk. koht. tmux tuntuu mukavammalta kuin kivikautinen GNU Screen.

En ole testannut. Ei tule konetta usein sammutettua, niin ei ole hirveästi ollut väliä, mutta voisin kokeilla jos ei paljoa tarvitse säätää. Screeniä olen käyttänyt, kun se on ajanut asiansa. En muuta tee, kun avaan vain jokusen ikkunan istuntoon.

 

[Dehir]

Joo mitä ilmeisemmin pipewire on edennyt siis hyvin kehityksessä.
Itse pohjaan nuo viimeiset "kokemukset" pipewireen tyyliin aika kaudelle miekka ja kirves eli 2017 jolloin lähinnä tuli seurailtua conferenssi esitelmiä siitä millainen pipewire tulee olemaan/miten kehitys edennyt eikä mikään distro juurikaan tainnut tarjota vielä edes valmiita binary paketteja. Tämä on tietenkin hyvä asia jos tai kun pipewire toimii jo monen distron pohjalla. Itsellä tällä hetkellä pelkästään pulseaudio <-> alsa ja jack satunnaisesti. Periaatteessa voisin alkaa jo vaihtaa järjestelmässä pulseaudion tilalle pipewiren pohjalle mutta if aint broken don't fixit mentaliteetilla etenen näissä monesti. Pohjaan tämänkin lähinnä siihen mitä muistan viimeeksi lukeneeni archin bugtrackkerista ja pipewiresta että viime silmäyksellä oli vielä liian aikaista.

Pipewire-pulse, pipewire-jackd tai pipewire-alsa on juurikin niitä yhteensopivuus kirjastoja/paketteja joita tarvitaan että kaikki softat jotka käyttää vielä "vanhoja" äänipuolen ajureita/kirjastoja pyörii pipewiren päällä.

 

[Barbarossa]

Tässä huvikseni väkersin ältsin hienon, joskin karkean ja mutkia suoriksi oikovan, kuvatuksen Linuxin audiopinosta jonka toivon selkeyttävän pipewire-pulseaudio-jack-alsa kuviota.

Spoileri

 

[JiiPee]

Ja vielä tuosta audiopinosta niin jos joku ihmettelee että miksi tommosia tarttetaan niin siksi koska alsa vaikka onkin ihan mainio, on kuitenkin aika yksinkertainen. Esim. kodin saa toimimaan ihan suoraan alsan läpitte, joka taitaa tällä hetkellä olla ainut tapa jolla DD5.1 ja DTS parempia ääniä saa passthroughtina menemään vahvistimelle. Ongelma vaan on että se kodi ryövää sitten yksinoikeudella koko äänipuolen ja mistään muualta ei sitten äänet enää pihise. Tää ei tietty ole ongelma jos pyörittää vaan sitä kodia.
Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.

Pulseaudio puolella tuon passthrough homman kanssa jotain kehitystä tapahtui, mutta se sitten hyytyi kuten koko pulsen kehitys kun toi pipewire alkoi ottaa tuulta alleen. Ilmeisesti pipewire puolella ollaan vielä pahasti vaiheessa tuon passthrough kanssa.
Itte meinannu jo monta vuotta laittaa töllön perään jonkinlaisen HTPC homman, mutta en haluaisi sitä windowsilla toteuttaa, mutta nyt kun tätä kehitystä on seurannut monta vuotta niin ei hyvältä kyllä näytä.
Ääänipuoli ihan rempallaan linuxissa ja HDR myös. Voi olla että täytyy nöyrtyä ja laittaa windows hoitamaan tuota. Windowsilla passthrough toimii ongelmitta, tai ainakin viimeeksi kun sitä testasin.

 

[Vaateri]

Esim. kodin saa toimimaan ihan suoraan alsan läpitte, joka taitaa tällä hetkellä olla ainut tapa jolla DD5.1 ja DTS parempia ääniä saa passthroughtina menemään vahvistimelle.

Aikoinaan, taitaa olla lähemmäs 20 kuin 10 vuotta sitten, kun tuli viriteltyä Linux-pohjaisia mediakoneita mm. digi-tv-käyttöön, niin alsa oli tosiaan pomminvarma virittää esim emolevyn spdif-outputille. Sitten kun distrot alkoivat tuoda mukaan sound servereitä (lähinnä pulseaudio), tuli hommasta huomattavasti hankalampaa. Kiva nähdä että kehitys kehittyy, mutta taitaa tosiaan osittain ainakin samat pulmat olla vielä läsnä. Ei tietenkään samanlaisina, mutta...

 

[Algron28]

Ja vielä tuosta audiopinosta niin jos joku ihmettelee että miksi tommosia tarttetaan niin siksi koska alsa vaikka onkin ihan mainio, on kuitenkin aika yksinkertainen. Esim. kodin saa toimimaan ihan suoraan alsan läpitte, joka taitaa tällä hetkellä olla ainut tapa jolla DD5.1 ja DTS parempia ääniä saa passthroughtina menemään vahvistimelle. Ongelma vaan on että se kodi ryövää sitten yksinoikeudella koko äänipuolen ja mistään muualta ei sitten äänet enää pihise. Tää ei tietty ole ongelma jos pyörittää vaan sitä kodia.
Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.

Pulseaudio puolella tuon passthrough homman kanssa jotain kehitystä tapahtui, mutta se sitten hyytyi kuten koko pulsen kehitys kun toi pipewire alkoi ottaa tuulta alleen. Ilmeisesti pipewire puolella ollaan vielä pahasti vaiheessa tuon passthrough kanssa.
Itte meinannu jo monta vuotta laittaa töllön perään jonkinlaisen HTPC homman, mutta en haluaisi sitä windowsilla toteuttaa, mutta nyt kun tätä kehitystä on seurannut monta vuotta niin ei hyvältä kyllä näytä.
Ääänipuoli ihan rempallaan linuxissa ja HDR myös. Voi olla että täytyy nöyrtyä ja laittaa windows hoitamaan tuota. Windowsilla passthrough toimii ongelmitta, tai ainakin viimeeksi kun sitä testasin.

Tätä äänikeskustelua seuratessa ei kyllä ihmetytä yhtään miksi monelle tavan käyttäjälle Linux edelleen esittäytyy mörkönä. Analogiana voisi ottaa vaikka sen että suurinta osaa ei oikeasti kiinnosta kovin paljon miten ja millä auto toimii vaan se onko sitä kuinka helppo, halpa ja mukava käyttää.

 

[Karonkka]

Tätä äänikeskustelua seuratessa ei kyllä ihmetytä yhtään miksi monelle tavan käyttäjälle Linux edelleen esittäytyy mörkönä. Analogiana voisi ottaa vaikka sen että suurinta osaa ei oikeasti kiinnosta kovin paljon miten ja millä auto toimii vaan se onko sitä kuinka helppo, halpa ja mukava käyttää.

Mitä mukavampi, sen kalliimpi rahassa. Pätee jokaiseen tekniseen laitteeseen ja niiden huoltamiseen kuluvan rahan määrään. Autojen elinikä moninkertaistuisi, mikäli ihmiset huoltaisivat ne itse unohtaen kaikki mukavuustekijät. Sama pätee läppäreihin, jos useampi käyttäisi Linuxia.

Linuxissa toki esteensä valtavirtaistumiseen on, mutta audioajuri tuskin näyttelee mitään roolia siinä. Kaverini on vuodesta 2018 saakka käyttänyt samaa Ubuntun asennusta avaamatta terminalia kertaakaan. Käyttää sitä puoliammattilaisesti kuvien muokkaukseen Gimpillä. Ja ei, en itsekään uskoisi tätä väitettä ellen vierestä katsoisi.

 

[Obi-Lan]

Osassa kuulokeliittimiä on käsittääkseni jonkinlainen triggeri mikä reagoi kun piuhan tökkää sisään? Testasin omalla Lenovon läppäriillä, kuulokelähtö tulee valittavaksi vasta kun tökkää piuhan sisään ja näyttäisi muistavan tuon jos käyttää koneen nukkumassa (Ubuntu 22.04). Tuon kaiuttimet on fyysisesti kohtuu kehnot ja Lenovo on niitä Windows puolella korjannut Dolby Audio appilla ja softapohjaisella equalizerilla, Linuxille sama löytyy EasyEffects sovelluksella mikä toimii ok myös pipewire kanssa.

Pipewiren käsittääkseni piti ainakin korjata lagit äänen prosessoinnissa, jotta joskus tulevaisuudessa myös Audio ammattilaiset pystyisivät käyttämään Linuxia.

 

[Dehir]

Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.

JACK tarjosi vastaavanlaista ratkaisualustaa softatason miksaukselle. Mutta ei kuitenkaan ratkaissut ongelmaa jossa kun käytössä on useampi äänipalvelin. Periaatteessa jos JACKia halusi käyttää piti muut palvelimet sillata JACKin päälle joka toimi vaihtelevalla menestyksellä, lähinnä ongelmia tulee sillon jos käyttää eri mittaustaajuutta yms unohtamatta perus latency ongelmia. Periaatteessa tuon pipewirenhan voi edelleen laittaa operoimaan JACKin päälle jos haluaa jolloin JACK olla se viimeinen rajapinta joka operoi suoraan raudan kanssa.

Run PipeWire on top of native JACK
PipeWire can also run as a JACK client on top of the native JACK daemon if desired. See JACK and PipeWire for more information.

Toinen syy minkä takia pipewire on edelleen toivotumpi ratkaisu on että monikaan softa ei natiivisti tukenut JACKia

 

[Lammas]

Pitkään meni itselläni siirtyessä Screenistä Tmuxiin, mutta nyt kun käyttää niin ei ole enää paluuta vanhaan. Ihan jo vaikka siitä syystä että saa jaettua ruudun kahtia, ja olla kaksi editoria auki vierekkäin. Ja irssissä saa IRC-kanavan jäsenlistan sivupalkiksi, kun käyttää Tmux plugaria

No kyllähän screenillä voi jakaa ruudun vaikka kuinka moneen osaan. Ctrl+a+S (iso S) splittaa vertikaalisesti ja Ctrl+a+| horisontaalisesti.

 

[Algron28]

Mitä mukavampi, sen kalliimpi rahassa. Pätee jokaiseen tekniseen laitteeseen ja niiden huoltamiseen kuluvan rahan määrään. Autojen elinikä moninkertaistuisi, mikäli ihmiset huoltaisivat ne itse unohtaen kaikki mukavuustekijät. Sama pätee läppäreihin, jos useampi käyttäisi Linuxia.

Linuxissa toki esteensä valtavirtaistumiseen on, mutta audioajuri tuskin näyttelee mitään roolia siinä. Kaverini on vuodesta 2018 saakka käyttänyt samaa Ubuntun asennusta avaamatta terminalia kertaakaan. Käyttää sitä puoliammattilaisesti kuvien muokkaukseen Gimpillä. Ja ei, en itsekään uskoisi tätä väitettä ellen vierestä katsoisi.

Minusta tässä audioajuri hommassa esiintyy juuri ne avoimen softtan huonot puolet. Kasa keskeneräisiä toisistaan poikkeavia toteutuksia joita kehitentään, jos kehitetään. Ja sitten ihmitellään miksi kaupalliset yritykset suhtautuu linux tukee nuivasti. Kallista tehdä tuki 10 eri viritykselle joiden elinkelpoisuudesta ei tiedetä. Tavan käyttäjälläkään vaan ei ole mielenkiintoa käyttää useita tunteja aikaa säätämiseen niin autoissa kuin tietokoneissakaan jos erityistä kiinnostusta hommaa kohtaan ei ole.

 

[Dehir]

Minusta tässä audioajuri hommassa esiintyy juuri ne avoimen softtan huonot puolet. Kasa keskeneräisiä toisistaan poikkeavia toteutuksia joita kehitentään, jos kehitetään. Ja sitten ihmitellään miksi kaupalliset yritykset suhtautuu linux tukee nuivasti. Kallista tehdä tuki 10 eri viritykselle joiden elinkelpoisuudesta ei tiedetä. Tavan käyttäjälläkään vaan ei ole mielenkiintoa käyttää useita tunteja aikaa säätämiseen niin autoissa kuin tietokoneissakaan jos erityistä kiinnostusta hommaa kohtaan ei ole.

Näin ehkä työpöydällä. Linux soveltuu kyllä erittäin hyvin embedded raudan kehityksen. Olen esim ollut todistamassa muutamankin kerran live keikoilla kuinka digitaalinen mikseripöytä buutannut nimenomaan linuxilla. Tämä tosin aikaa ennen kuin applesta oli tullut dominoiva tekijä markkinoilla ja pipewiresta ei oltu kuultukaan (Joskus 2010 luvun taitteessa) Eli kyllä se ammattimaiseen käyttöön skaalautuu.

 

[Algron28]

Näin ehkä työpöydällä. Linux soveltuu kyllä erittäin hyvin embedded raudan kehityksen. Olen esim ollut todistamassa muutamankin kerran live keikoilla kuinka digitaalinen mikseripöytä buutannut nimenomaan linuxilla. Tämä tosin aikaa ennen kuin applesta oli tullut dominoiva tekijä markkinoilla ja pipewiresta ei oltu kuultukaan (Joskus 2010 luvun taitteessa) Eli kyllä se ammattimaiseen käyttöön skaalautuu.

Nuo embedded systeemi taas on monesti hyvin rajatun, muuttumattoman käyttötarkoituksen systeemejä joten kun valmistaja on ne kerran vääntänyt valmiiksi niin niitä ei monesti sen jälkeen muutella, tai päivitellä, josta päästään sitten siihen seuraavaan että on valtavasti embedded systeemejä joissa pyörii joku jeesuksen aikainen käyttisversio ilman mitään vähääkään tuoreita tietoturvapäivityksiä ja välillä taas julkaistaan tuotteita jo valmiiksi antiikkisella softalla koska se softa tekee tarvittavan. Tämähän ei sinäänsä ole ongelma, ennenkuin noilla on pääsy internettiin.

 

[Dehir]

Nuo embedded systeemi taas on monesti hyvin rajatun, muuttumattoman käyttötarkoituksen systeemejä joten kun valmistaja on ne kerran vääntänyt valmiiksi niin niitä ei monesti sen jälkeen muutella, tai päivitellä, josta päästään sitten siihen seuraavaan että on valtavasti embedded systeemejä joissa pyörii joku jeesuksen aikainen käyttisversio ilman mitään vähääkään tuoreita tietoturvapäivityksiä ja välillä taas julkaistaan tuotteita jo valmiiksi antiikkisella softalla koska se softa tekee tarvittavan. Tämähän ei sinäänsä ole ongelma, ennenkuin noilla on pääsy internettiin.

Eikä tuo pelkästään embedded systeemeihin rajoitu. Käytännössä kaikki tuotantotason studiojärjestelmät on pääosin aika vakioituja ja softapäivitysten tarve näin ollen vähäinen.
Kyllä ne applellakin studiotyötä tekevät pyrkii minimoimaan päivitystarpeensa. Eli If it aint broken dont fixit pätee ihan yhtä lailla myös kys alustalla. rt-kerneli ja JACK kyllä soveltuu ihan perus studiokäyttikseksi DAWin kanssa joita tarjolla nykyisin ihan natiivisti linuxille. Eli edelleenkään ei se apple ainoa ole. Windowsin käytettävyydestä en jaksa edes alkaa puhumaan kaiken ASIO sekoilun kanssa vaikka "kuluttajille" softian kehitelläänkin.

 

[JiiPee]

Windowsin käytettävyydestä en jaksa edes alkaa puhumaan kaiken ASIO sekoilun kanssa vaikka "kuluttajille" softian kehitelläänkin.

Näin kuluttajan näkökulmasta tuo ASIO vaan toimii kaikessa siinä mitä itte tartten, kun taas linux puolella ei juuri mikään toimi mitä itte tartten kun ei ole tukea vielä vuosienkaan jälkeen saatu koodattua. Silloin kun linux puolelle se tuki saadaan niin se yleensä sitten toimii, mutta fyytsörit vaan tulee linuxille varsin hitaasti.

 

[Dehir]

Näin kuluttajan näkökulmasta tuo ASIO vaan toimii kaikessa siinä mitä itte tartten, kun taas linux puolella ei juuri mikään toimi mitä itte tartten kun ei ole tukea vielä vuosienkaan jälkeen saatu koodattua. Silloin kun linux puolelle se tuki saadaan niin se yleensä sitten toimii, mutta fyytsörit vaan tulee linuxille varsin hitaasti.

Kyllä tuo pipewire tulee tarjoamaan/tarjoaa jo nyt coreaudio tasoista käytettävyyttä matalalla latencylla. Väittäisin että toiminnaltaan tulee olemaan jopa parempi vs yrität windowsissa pakottaa 32-bittistä ASIO softaa rullaamaan 64-bittisessä ASIO ympäristössä. Tai unohtamatta sitä miten eri laitteiden valmistajilla on tapana paketoida omat ajurinsa customoiduilla ASIO ajureilla ja kyseiset laitteet ei toimi juurikaan muilla ajureilla luotettavasti kuin kyseisen valmistajan omilla ja kys ajureita käytettäessä softien ristiin toimivuus onkin sitten aivan oma lukunsa.

 

[JiiPee]

Kyllä tuo pipewire tulee tarjoamaan/tarjoaa jo nyt coreaudio tasoista käytettävyyttä matalalla latencylla. Väittäisin että toiminnaltaan tulee olemaan jopa parempi vs yrität windowsissa pakottaa 32-bittistä ASIO softaa rullaamaan 64-bittisessä ASIO ympäristössä.

No itte kaipaisin sitä passtrough ominaisuutta. Ei ole näkyny eikä kuulunu. Pulseaudio sitä yritti 13.0 versiossa, mutta kusivat sen eikä kukaan ole viitsinyt korjata. Eli DD5.1 ja DTS passthrough onnistuu, mutta ei TrueHD, Atmos taikka DTS-X.

 

[Dehir]

No itte kaipaisin sitä passtrough ominaisuutta. Ei ole näkyny eikä kuulunu. Pulseaudio sitä yritti 13.0 versiossa, mutta kusivat sen eikä kukaan ole viitsinyt korjata. Eli DD5.1 ja DTS passthrough onnistuu, mutta ei TrueHD, Atmos taikka DTS-X.

En ole ite perehtynyt tuohon passthrough käyttöön koska ei ole ollut tarvetta/monikanavaääntä kotona käytössä. Ilmeisesti kyseinen olis/on alsan kautta toteutettavissa jollain configuraatio voodoolla. Ainakin näin muistan lueksineeni. Toki jos kyseinen tulee joskus/lisättävissä pipewireen niin varmasti plussaa. Kuten sanottua tällä hetkellä käytän itse siis pulseaudiota ja satunnaisesti JACKD pohjalla kun kitaralla tulee soiteltua. Enkä oo jaksanu syventyä tuohon pipewireen vielä tarkemmin muuten kuin pintapuolisesti/demonstraatio videoiden/juttujen kautta vuosien aikana.

Mutta mitä ymmärtäsin ite niin tuota alsaa pitäis pystyä käyttämään pipewiren päällä ihan "normaalisti" eli alsan syötteet pitäis kyllä mennä pipewiren kautta ilman ongelmia

 

[JiiPee]

En ole ite perehtynyt tuohon passthrough käyttöön koska ei ole ollut tarvetta/monikanavaääntä kotona käytössä. Ilmeisesti kyseinen olis/on alsan kautta toteutettavissa jollain configuraatio voodoolla

Joo saahan sen kun sammuttaa ensin pipen taikka pulsen ennen kodin käynnistystä ja kertoo kodille käynnistyksessä että käytä alsaa. Mutta aika huono vaihtoehto jos meinaa ajella muutakin kuin pelkkää kodia.

 

[TenderBeef]

Huomasin pienen ongelman omassa "hibernate+restart" systeemissä (käynnistyy kuvakkeesta työpöydällä), jos hibernate ei toimikaan kunnolla ja joutuu laittamaan virrat poikki ja boottaamaan normaalisti takaisin, niin järjestelmään jää ohje restartata seuraavalla kerralla kun konetta taas laitetaan hibernateen (ja tässä voi olla tilanne, että ei haluta restarttia vaan virrat pois normaalisti).

Eli tiedosto /etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf luodaan tuossa omassa systeemissäni sisällöllä:

[Sleep]
HibernateMode=reboot

Ja tiedostolla /lib/systemd/system-sleep/disable_hibernate_reboot tuo äskeinen poistetaan kun tullaan takaisin hibernate-tilasta:

#!/bin/bash

if [[ -f "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf" && "$1" == "post" && "$2" == "hibernate" ]]
then
    rm "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf"
fi

Mikäs olisi paras tapa hoitaa tää? Onko jotain yhtä "/etc/systemd/" konffitiedostoa (tai pitääkö joku service tehdä?) jonka kautta saisi poistettua tuon "HibernateMode" säätötiedoston puhtaan rebootin JA hibernaten jälkeen?

 

[telcoM]

Ja vielä tuosta audiopinosta niin jos joku ihmettelee että miksi tommosia tarttetaan niin siksi koska alsa vaikka onkin ihan mainio, on kuitenkin aika yksinkertainen. Esim. kodin saa toimimaan ihan suoraan alsan läpitte, joka taitaa tällä hetkellä olla ainut tapa jolla DD5.1 ja DTS parempia ääniä saa passthroughtina menemään vahvistimelle. Ongelma vaan on että se kodi ryövää sitten yksinoikeudella koko äänipuolen ja mistään muualta ei sitten äänet enää pihise. Tää ei tietty ole ongelma jos pyörittää vaan sitä kodia.
Eli pulseaudio ja pipewire on taso siinä välissä joka mahdollistaa useamman äänilähteen käyttävän sitä samaa audio liitäntää ja tavallaan kykenee "miksaamaan" useamman äänilähteen äänet yhteen.

ALSAn perusteet suunniteltiin silloin kun asennettujen äänikorttien enemmistö oli vielä ISA-väylässä, ja paremmissa äänikorteissa oli rautatason miksaus useamman äänilähteen yhteiskäytölle. Silloin prosessoritehot olivat niin paljon pienempiä että se kannatti, ja ALSAn kehittäjät veikkasivat että rautatason miksauksesta tulisi äänikorttien perusominaisuus. No eipä tullut, vaan tuli PCI- ja USB-väyläiset äänikortit ja useamman ääntä tuottavan ohjelman yhteenmiksaus jätettiin prosessorin vastuulle. Kehitys kääntyikin siihen suuntaan että äänikorteista karsittiin "ylimääräiset" kuten raudalla toteutetut EAX-tilaäänitoiminnot pois, koska niiden toteuttaminen ohjelmallisesti yhä nopeammilla prosessoreilla ei ollut enää mikään ongelma. Äänikorttien ominaisuudet lakkasivat kiinnostamasta valtaosaa käyttäjiä (koska perusäänipiirit olivat kaikki vähintään "tarpeeksi hyviä" peruskäyttöön), ja muotoutui standardeja rautarajapintoja: ensin AC97 ja sitten HD Audio. USB-puolella äänilaitteille saatiinkin standardimäärittely melkein alusta lähtien, joskin suht äskettäin on saatu aikaan USB Audio 2.0-laiteluokan määritys (saa nähdä mitä siitä seuraa).

Puuttuiko sitten ALSAn kehittäjiltä siviilirohkeutta lähteä ajoissa kehittämään hypoteettista ALSA 2.0:aa jossa rajapintaa olisi pistetty uusiksi siihen suuntaan että softamiksauksesta tulisi rajapinnan universaali osa, vai kävikö sitten niin että ne joille riitti äänet yhdestä ohjelmasta kerrallaan jäivät jurnuttamaan "tää on ihan hyvä, muuta ei tarvita"-moodiin, kas siinä kysymys.

Lopputulos kuitenkin oli se, että softamiksausrajapintaa piti lähteä toteuttamaan erillisenä palikkana, jonka ne jotka eivät sitä halunneet saattoivat jättää pois. Ja sitten vielä kun jotkut isot jakelut (Fedora ja Ubuntu taisivat olla ensimmäisiä) pistivät laajaan levitykseen sellaiset PulseAudion versiot jotka eivät olleet ihan täysin valmiita sellaiseen, soppa oli valmis. Asiaa ei suinkaan auttanut se että silloin PulseAudion pääkehittäjänä oli Lennart Pöttering, joka saattaa olla hyvinkin kova koodari, mutta toisten ihmisten kanssa kommunikoinnissa hänellä on ollut... hiukan haasteita.

 

[JiiPee]

vai kävikö sitten niin että ne joille riitti äänet yhdestä ohjelmasta kerrallaan jäivät jurnuttamaan "tää on ihan hyvä, muuta ei tarvita"-moodiin, kas siinä kysymys.

Veikkaan että tämä nimenomaan tapahtui.

Ja vaikka opensource homma pääsääntöisesti onkin varsin hieno homma, niin välillä hommat on vaan aivan vitun kankeita.

Tuli taas ihan hiljattain todistettua tää kun fedoran x265 (tai siis rpmfusion sitä jakelee kun ei fedoran lisenssiehtojen sisään vissiin jostain syystä oikein tuo satu) paketti on buildattu niin että 8-bit color space libraryyn lyödään hdr10plus flägi päälle (jossa mielestäni ei ole yhtään mitään järkeä koska kaikki hdr matsku vaatii vähintään 10-bit color space) mutta ei 10/12-bit color space libraryyn, joten sillä ei tehny mitään koska hdr10plus metadatan injektointi ei toiminut.

Tein bugi rapsan asiasta ja kuukauteen ei kuulunu yhtään mitään jonka jälkeen otin suoraan sähköpostilla yhteyttä henkilöön joka oli allekirjoittanu rpm .spec tiedoston muutokset viimeisimpänä. Sen jälkeen alkoi hiljalleen tapahtumaan, mutta kukaan ei tuntunu tietävän taikka käsittävän että mistä oikein on kysymys.
Lopulta kun laitoin oikein rautalanka esimerkin niin asia alettiin ymmärtää.
Alkuperäisen .spec filun tekijä ei tiennyt miksi homma oli noin tehty alkujaan, hän oli copy/pastennu sen jostain. Päätin sitten kysellä siltä sälliltä vielä asiaa joka sen oli alkujaan tehnyt ja hän taas ei enää muistanut että miksi, mutta korjasi sitten samalla omaansa tuon kanssa.
Voisin itse lonkalta veikata että x265 on tehty library puolella jossain vaiheessa isompi remontti ja ehkä jossain vaiheessa se on riittänyt että -bit libiin enabloi sen option, mutta ei riitä enää. Mutta täysin arvailua. Ei kiinnosta niin paljoa että alkaisin koodi muutoksia penkomaan kun en nyt varsinaisesti koodaamisesta ole niin kauheasti erdes perillä. Hiukan osaan päätellä jotain.

Muttä tämä saaga siis kesti kaikkiaan 2 kuukautta että saatiin lopulta yksi optio muutettua.

 

[JiiPee]

Eikö oikeasti voi vieläkään alivoltittaa NVIDIAa?

Linux + nvidia = issues.

 

[Hyrava]

Veikkaan että tämä nimenomaan tapahtui.

Ja vaikka opensource homma pääsääntöisesti onkin varsin hieno homma, niin välillä hommat on vaan aivan vitun kankeita.

Tuli taas ihan hiljattain todistettua tää kun fedoran x265 (tai siis rpmfusion sitä jakelee kun ei fedoran lisenssiehtojen sisään vissiin jostain syystä oikein tuo satu) paketti on buildattu niin että 8-bit color space libraryyn lyödään hdr10plus flägi päälle (jossa mielestäni ei ole yhtään mitään järkeä koska kaikki hdr matsku vaatii vähintään 10-bit color space) mutta ei 10/12-bit color space libraryyn, joten sillä ei tehny mitään koska hdr10plus metadatan injektointi ei toiminut.

Tein bugi rapsan asiasta ja kuukauteen ei kuulunu yhtään mitään jonka jälkeen otin suoraan sähköpostilla yhteyttä henkilöön joka oli allekirjoittanu rpm .spec tiedoston muutokset viimeisimpänä. Sen jälkeen alkoi hiljalleen tapahtumaan, mutta kukaan ei tuntunu tietävän taikka käsittävän että mistä oikein on kysymys.
Lopulta kun laitoin oikein rautalanka esimerkin niin asia alettiin ymmärtää.
Alkuperäisen .spec filun tekijä ei tiennyt miksi homma oli noin tehty alkujaan, hän oli copy/pastennu sen jostain. Päätin sitten kysellä siltä sälliltä vielä asiaa joka sen oli alkujaan tehnyt ja hän taas ei enää muistanut että miksi, mutta korjasi sitten samalla omaansa tuon kanssa.
Voisin itse lonkalta veikata että x265 on tehty library puolella jossain vaiheessa isompi remontti ja ehkä jossain vaiheessa se on riittänyt että -bit libiin enabloi sen option, mutta ei riitä enää. Mutta täysin arvailua. Ei kiinnosta niin paljoa että alkaisin koodi muutoksia penkomaan kun en nyt varsinaisesti koodaamisesta ole niin kauheasti erdes perillä. Hiukan osaan päätellä jotain.

Muttä tämä saaga siis kesti kaikkiaan 2 kuukautta että saatiin lopulta yksi optio muutettua.

Juu, joskus on aika nihkeää saada jotain bugia korjattua tai jotain featurea aikaiseksi. Tuo 2kk on varsin lyhyt aika omien kokemuksieni mukaan.

Erääseen softaan olin lukuisten muiden kanssa pyytämässä yhtä featurea ja kuukauden päästä tuli vaan vastaus "ei toteuteta, vastaava toiminto on tulossa ihan kohta vähän eri tavalla toteutettuna". No ok, jos saman toiminnallisuuden saisi vaikka hieman eri tavalla toteutettuna niin mikäpä siinä, odotellaan... Tuo featurepyyntö oli vuonna 2017 eikä vieläkään ole tuota featurea toteutettu, eikä sen paremmin kyllä sitä "ihan kohta tulevaa" korvaavaa toiminnallisuutta ole näkynyt. Kaikkia muita, mielestäni paljon turhempia juttuja kyllä softaan lisäiltiin mutta ei tuota kyseistä. Taisi joku jonkun suunnilleen toimivan pull requestinkin laittaa mutta eipä kehittäjät sitä huolineet. Pari vuotta ihmiset jaksoivat kysellä tuon perään mutta itsekin odotellessani vaihdoin softan toiseen tuon takia.

Vastaavasti joissakin tapauksissa joidenkin softien kehittäjät ovat korjailleet ilmoittamiani bugeja tunneissa tai päivissä tai uusia featureja on tullut seuraavaan tai sitä seuraavaan releaseen joten aika vaihtelevaa meininkiä tuntuu olevan.

 

[Barbarossa]

Niitä saattaa olla nihkeää saada, mutta avoin softa antaa sentään mahdollisuuden ohittaa ehkä ikuisen odottelun: opettelee koodamaan tai vaikka ottamaan sen pull requestin käyttöön itselle. Suljetun puolella ollaankin täysin kehittäjien armoilla, omien kokemusten mukaan edes niitä bugeja ei juuri jakseta korjailla jos se ei vaikuta tuottoihin, ominaisuuksia onkin jo melko turhaa toivoa..

Tämähän se. Aina on (edes teoreettinen) mahdollisuus ottaa kynä kauniiseen käteen ja tehdä itse korjaus, ja tarjota sitä PR:n tai patchin muodossa upstreamiin niin ei tarvitse kaupallisesti kehitetyn distron ilmaisversion vapaaehtoisvoimin ylläpidettyä lisärepoa odotella. Tietenkään aina niitä ei kelpuuteta, joskus vastauksena on sirkkojen sirittämistä mutta ompahan ainakin yrittänyt kantaa kortensa kekoon.


Sivumennen, Gentoon hienoimpia asioita ei ole -funroll-loops vaikka binaaridistroilijat jaksavatkin siitä viisastella. Voi itse muokata ebuildia jolla paketti kääntyy jos haluaa jotakin mihin se distron oma ei taivu. Tai voi ottaa vaikka paketin PR:n patchina matkaan lennosta paketin asennuksen yhteyteen.. tai vaikka tehdä sen korjauksen omin käsin ja tyrkyttää sitä upstreamiin.

 

[Hyrava]

Niitä saattaa olla nihkeää saada, mutta avoin softa antaa sentään mahdollisuuden ohittaa ehkä ikuisen odottelun: opettelee koodamaan tai vaikka ottamaan sen pull requestin käyttöön itselle. Suljetun puolella ollaankin täysin kehittäjien armoilla, omien kokemusten mukaan edes niitä bugeja ei juuri jakseta korjailla jos se ei vaikuta tuottoihin, ominaisuuksia onkin jo melko turhaa toivoa.. Millaista ominaisuutta pyysit?

Tuo feature olisi ollut ihan konfiguraatiofileen parsintaan tuki rangelle, ettei olisi joutunut kirjoittamaan 100 ja 1 kertaa samaa asiaa konfiguraatioon, tyyliin:

[entry]
id=1
param=true
[entry]
id=2
param=true
[entry]
id=3
param=true

eli että tuon olisi saanut vaikka muotoon

[entry]
id=[1-3]
param=true

Noita entry-blokkeja olisi omassa käytössä ollut kymmeniä joten jonkinlainen range-määritys olisi ollut varsin kätevä. Jos käytetty kieli olisi ollut joku mitä olisin osannut, olisin varmaan harkinnut oman forkin tekoa. Tosin, sitten tulevaisuuden tietoturvapäivitysten kanssa olisi kyllä tullut oma hommansa kun olisi itse pitänyt hoidella päivitykset.

Jonkin verran olenkin C/C++/Python -softista tehnyt omia privaattiversioita jos ovat olleet sellaisia joissa en ole nähnyt kovin suurta riskiä että päivityksiä ei omien muutosten jälkeen saisikaan helposti mukaan ympättyä. Ihan mielellään en noita kuitenkaan rupea tekemään kun en mikään oikea koodari ole eikä oikein aika riitä kaiken mahdollisen ylläpitämiseen.

 

[Algron28]

Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.

 

[bindi]

Onko pakko olla ftp? Esim pythonilla voi ajaa python -m http.server niin se jakelee nykyistä hakemistoa portissa 8080 (muistaakseni).

 

[Algron28]

Onko pakko olla ftp? Esim pythonilla voi ajaa python -m http.server niin se jakelee nykyistä hakemistoa portissa 8080 (muistaakseni).

On pakko olla FTP, sillä nuo siis on erilaisia verkkolaitteita yms ja toiminta logiikka on että niitä laitteen hallinnasta komennetaan muodostamaan ftp yhteys johonkin osoitteeseen ja sitten lataamaan suuntaan tai toiseen tiedostoja.

 

[emagdnim]

Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.

modeemireitittimissä on yleensä ftp-palvelinkin, jos sellainen riittää?

 

[Algron28]

modeemireitittimissä on yleensä ftp-palvelinkin, jos sellainen riittää?

Tämä tulee käytettäväksi muualla kuin kotiverkossa ja tarkoitus olisi saada konffi läppärille sellainen toteutus että sen käyttö olisi vaivatonta muissakin FTP:tä vaativissa tilanteissa.

Mitä noita googletteli, niin FTP servereitä linuxille on pilvin pimein, mutta monet noista on tarkoitettu jatkuvaan "oikeaan" FTP käyttöön ja täten kovin kankeita. Esim koneen IP osoitteen vaihto ei saisi aiheuttaa ongelmaa.

 

[bindi]

Tämä tulee käytettäväksi muualla kuin kotiverkossa ja tarkoitus olisi saada konffi läppärille sellainen toteutus että sen käyttö olisi vaivatonta muissakin FTP:tä vaativissa tilanteissa.

pip3 install pyftpdlib
python3 -m pyftpdlib - jakelee nykyisen hakemiston ilman kirjoitusoikeuksia (anonymous login) portissa 2121
python3 -m pyftpdlib --write --port 21 - jakelee nykyisen hakemiston kirjoitusoikeuksilla(anonymous login) portissa 21

Testailin tätä nopeasti ja vaikuttaisi ihan näppärältä väliaikaistarkoituksiin.

 

[Algron28]

pip3 install pyftpdlib
python3 -m pyftpdlib - jakelee nykyisen hakemiston ilman kirjoitusoikeuksia (anonymous login) portissa 2121
python3 -m pyftpdlib --write --port 21 - jakelee nykyisen hakemiston kirjoitusoikeuksilla(anonymous login) portissa 21

Testailin tätä nopeasti ja vaikuttaisi ihan näppärältä väliaikaistarkoituksiin.

Tämä.... oli parempi kuin 100 jänistä. Todella helppo ja vaivaton. Kiitos vain paljon!

 

[JKAVS]

Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?

 

[emagdnim]

Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?

Oisko kameralla mahis lähettää kuvia muutenkuin sähköpostina? Kuvat suoraan sinne minne halutaan ilman liitetiedostojen kans säätämistä.

 

[SShadow]

Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?

Sama tunne itsellä, pitää hieman osata koodata, jos haluaa käyttää Linuxia tuohon. On Linuxiinkin maksullisia softia, mutta yleensä halutaan helposti ja ilmaisena. Windowsissa Power Bi on ilmainen ja tekee tuon tosi helposti.

 

[keskiverto]

Tämähän on varmaan täysin linuxin periaatteiden vastainen jo ajatuksena, mutta onkohan olemassa jotain ubuntulla toimivaa yksinkertaista, helppokäyttöistä FTP serveriä joka olisi näppärä väliaikaiseen käyttöön. Eli siis, käyttö tulisi olemaan sitä kun erilaisiin laitteisiin tarvitsisi FTP:llä ladata softaa tai konffista tai päinvastoin eli laitteessa on siis client joka ottaa yhteyttä läppärillä olevaan serveriin tiedostojen siirtämiseksi. Tarve on ajoittaista joten pitäisi olla sellainen mikä on vaivaton laittaa päälle ja pois.

vsftpd on ainakin ollut Ubuntulle: Service - FTP | Ubuntu
Tosin nuo aiemmin mainitut python-palikat lienevät hetkittäiseen käyttöön vielä selvempiä.

 

[JKAVS]

Oisko kameralla mahis lähettää kuvia muutenkuin sähköpostina? Kuvat suoraan sinne minne halutaan ilman liitetiedostojen kans säätämistä.

Tuo ei ole mahdollista.

Sama tunne itsellä, pitää hieman osata koodata, jos haluaa käyttää Linuxia tuohon. On Linuxiinkin maksullisia softia, mutta yleensä halutaan helposti ja ilmaisena. Windowsissa Power Bi on ilmainen ja tekee tuon tosi helposti.

Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.

 

[emagdnim]

Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.

No onhan se koko ajatuskin tuosta pöljä. Sinun syyhän se ei ole vaan valmistajan, joka sallii vain sähköpostien lähettämisen pelkän datan sijaan. Tuossa sit pitää lukea sähköpostiviestejä ja hakea sieltä liitetiedostoja. Asiaa helpottaa, jos kameralle on oma sähköposti-tili, nii säästyy sentäs filtteröinniltä. Joka tapauksessa ihan turhaa purkkaa, mut ei kyl auta sun ongelmassa yhtää tämä vuodatus

 

[kaakau<"'\\/>]

Haluaisin ottaa automaattisesti riistakameran sähköpostit vastaan ja laittaa kuvat tiettyyn paikkaan verkkolevyllä. Minulla on Ubuntua pyörittävä palvelin, ja ajattelin että homma olisi helppo tehdä sillä.

Mutta vielä mitä. Googletuksen jälkeen näyttää siltä että tarvitsen ensin yhden ohjelman joka hoitaa sähköpostiliikenteen, toisen ohjelman joka hakee uudet viestit ja vielä kolmannen joka erottaa liitteenä olevan kuvan viestistä.

Onko noinkin yksinkertainen asia todella noin vaikea, vai yritänkö vaikeimman kautta?

Vähän googlettelin ja tällainen projekti voisi toimia GitHub - auino/mail-attachments-archiver: Store mail attachments to file-system.

 

[JKAVS]

Vähän googlettelin ja tällainen projekti voisi toimia GitHub - auino/mail-attachments-archiver: Store mail attachments to file-system.

Siinähän tosiaan näyttäisi olevan valmis ratkaisu.

 

[Hyrava]

Siinähän tosiaan näyttäisi olevan valmis ratkaisu.

Heh, tuohan näyttäisi olevan melkein samanlainen tekele mitä itse puolisen vuotta sitten tein itselleni väliaikaiseksi työkaluksi vastaavaan ongelmaan. Eli simppeli mailiserveri joka huoli vain tietyiltä lähettäjiltä sähköpostia tietyillä otsikkotiedoilla ja tallensi liitetiedostot viestin sisällön mukaan tietyllä logiikalla eri kansioihin. Olisi siis kannattanut googlettaa ensin niin ei olisi tarvinnut itse yhtä iltaa käyttää koodaamiseen

 

[emagdnim]

Heh, tuohan näyttäisi olevan melkein samanlainen tekele mitä itse puolisen vuotta sitten tein itselleni väliaikaiseksi työkaluksi vastaavaan ongelmaan. Eli simppeli mailiserveri joka huoli vain tietyiltä lähettäjiltä sähköpostia tietyillä otsikkotiedoilla ja tallensi liitetiedostot viestin sisällön mukaan tietyllä logiikalla eri kansioihin. Olisi siis kannattanut googlettaa ensin niin ei olisi tarvinnut itse yhtä iltaa käyttää koodaamiseen

Olisit jääny paitsi "koodaamisen" ilosta.

 

[JiiPee]

Koodaaminen itsessään ei ole ongelma, mutta tuli epäusko että onko tuo tosiaan noin monimutkainen toteuttaa.

Monimutkainen on varmaan maku asia. Linux maailmassa kannattaa ajatusmallina pitää se että löytyy työkaluja vaikka mihin jotka tekee jonkun yhden asian ja yleensä sen ne tekee sitten hyvin.
Monesti kun jotain tarttee niin näitä työkaluja yhdistelemällä ja scriptaamalla saa asiat hoidettua melko vaivattomasti. Itse kun en sinäänsä koodata osaa niin tuota asiaa olisin varmaan lähtenyt ratkomaan ensin fetchmailin kanssa jonka siis saa hakemaan mailit serveriltä ja sitten ettiny seuraavan kikkareen jolla ne mailit voi komuta läpi talletella liitteet.

 

[kaakau<"'\\/>]

Joo, munpackilla tai ripmimella, jos jotain kiinnostaa, olisi saanut mailista liitteet eroteltua, sen olisi saanut vaikka ihan tavan mailiclientin johonkin hookkiin lisättyä ja sitten vain siirto levylle. Nämä varmaan tuli JKAVS:lla etsiessä vastaankin.

 

[Karonkka]

Monesti kun jotain tarttee niin näitä työkaluja yhdistelemällä ja scriptaamalla saa asiat hoidettua melko vaivattomasti.

Tämän vuoksi jokainen DE ja WM pitäisi rakentaa Rofin tai Dmenun ympärille.

 

[Sikatiiker]

Yleensä kai asennusjärjestys ensin winukka, sitten Linux, mutta nyt kun vanhalla työläppärillä on jo Linux mietin millainen operaatio olis asentaa Windows samalle läppärille?

Windows olis parin softaseikan taki tuleva sivutuloyrittäjän puoli ja Linuxilla kaikki muu käyttö.