Linux-kysymyksiä & yleistä keskustelua Linuxista

Eikös Snap ja Flatpak tee samaa asiaa, Snapit on Canonicalin työstämä ja Flatpak RedHat&co? Jotain hyviä asioita huomannut, että Flatpakissa voi olla tuoreempi versio vs pakettimanageri ja esim. Chromiumin sai asennettua Flatpakin kautta mediakodekkeineen eli ei tarvinnut rupeta virittämään mitään 3rd party media codec repoja (opensuse). Vaikuttaisivat parantavan käyttäjän elämää ainakin vähän isompien softien kanssa kun depency hell on leivottu imagen sisään.
 
Eikös Snap ja Flatpak tee samaa asiaa, Snapit on Canonicalin työstämä ja Flatpak RedHat&co? Jotain hyviä asioita huomannut, että Flatpakissa voi olla tuoreempi versio vs pakettimanageri ja esim. Chromiumin sai asennettua Flatpakin kautta mediakodekkeineen eli ei tarvinnut rupeta virittämään mitään 3rd party media codec repoja (opensuse). Vaikuttaisivat parantavan käyttäjän elämää ainakin vähän isompien softien kanssa kun depency hell on leivottu imagen sisään.

Joo ja tais olla vielä joku kolmaskin kikotin. Tämähän se on juuri linux puolen kirous (toisten mielestä siunaus) kun jokainen haluaa tehä jotain omaa juttua niin sitten kaikki on pirstaloitunutta.
Ainakaan Fedorassa out of the box ei flatpak löydä kovinkaan paljoa softaa. Pitäisi flathub repo lisätä niin sitten alkaisi löytyä.
 
Eikös Snap ja Flatpak tee samaa asiaa, Snapit on Canonicalin työstämä ja Flatpak RedHat&co? Jotain hyviä asioita huomannut, että Flatpakissa voi olla tuoreempi versio vs pakettimanageri ja esim. Chromiumin sai asennettua Flatpakin kautta mediakodekkeineen eli ei tarvinnut rupeta virittämään mitään 3rd party media codec repoja (opensuse). Vaikuttaisivat parantavan käyttäjän elämää ainakin vähän isompien softien kanssa kun depency hell on leivottu imagen sisään.

Periaatteessa sama toiminnallisuus, joitakin löytyy. Yksi huomionarvoinen on se että vaikka ehkä osa Flatpakin kehittäjistä saa palkkansa Red Hatilta, niin se on kokonaan avoin ja kuka tahansa voi flatpak-repon pystyttää. Snapit pyörivät storen ympärillä, joka taas on Canonicalin hallinnoima suljettu (myös koodiltaan) "kauppa". Ei ole tullut vastaan kolmannen osapuolen vastaavaa.

Canonical perinteisesti liittänyt avoimiin projekteihinsa CLA vaatimuksen. Snapin tapauksessa näin ei (ehkä) ole, ei kiinnosta tarpeeksi tutkia, mutta tämä suljettu store lienee uudempi tapa rajata avoimuutta.

Joo ja tais olla vielä joku kolmaskin kikotin. Tämähän se on juuri linux puolen kirous (toisten mielestä siunaus) kun jokainen haluaa tehä jotain omaa juttua niin sitten kaikki on pirstaloitunutta.
Ainakaan Fedorassa out of the box ei flatpak löydä kovinkaan paljoa softaa. Pitäisi flathub repo lisätä niin sitten alkaisi löytyä.

AppImage on ainakin samansuuntainen.
 
Mistäs voisi lähteä purkamaan kun yhteys Raspberryyn (Bullseye) RealVNC:n kautta onnistuu vain 320x200 resoluutiolla? Xrandr mukaan maksimiresoluutio olisi 7620x7680, mutta jos tätä koittaa muuttaa vaikka xrandr -s 1920x1080, tulee herja "size not found in available mode", huolimatta mitä resoluutiota yrittää tarjota. Joku riippuvuus tässä on siihen, jos on kytketty erillinen näyttö HDMIn kautta. Tällöin resoluutio etäyhteydenkin kautta näyttää ihan fiksulta. What do?
 
Mitä käyttistä / versiota suosittelisitte mini-pc:hen jota on tarkoitus käyttää pääasiassa verkon ksutta päivittyvänä iPhonen valokuvien backupina ja hdmi:n kautta 4K telkkariin videoiden katseluun?
 
Mitä käyttistä / versiota suosittelisitte mini-pc:hen jota on tarkoitus käyttää pääasiassa verkon ksutta päivittyvänä iPhonen valokuvien backupina ja hdmi:n kautta 4K telkkariin videoiden katseluun?
Oliko kyseessä siis ihan PC rautaa vai joku arm pohjainen systeemi?

Toi synkkaus wifin yli on aiemmin onnistunut vain maksullisilla softilla tai joskus muistaakseni ainoa ilmainen softa on ollut VLC, juu luit oikein VLC. Normaalisti siis video/audio siirto, mutta ainakin aiemmin VLC:llä pystyi myös siirtämään suoraan mitä tahansa tiedostoja.
 
Oliko kyseessä siis ihan PC rautaa vai joku arm pohjainen systeemi?

Toi synkkaus wifin yli on aiemmin onnistunut vain maksullisilla softilla tai joskus muistaakseni ainoa ilmainen softa on ollut VLC, juu luit oikein VLC. Normaalisti siis video/audio siirto, mutta ainakin aiemmin VLC:llä pystyi myös siirtämään suoraan mitä tahansa tiedostoja.

joo ihan pc, tuollainen minisforum amd:n prossulla.

kiitos, täytyy tutkia ja myös vlc. Luulisi että tällaista olisi moni tarvinnut.
 
joo ihan pc, tuollainen minisforum amd:n prossulla.

kiitos, täytyy tutkia ja myös vlc. Luulisi että tällaista olisi moni tarvinnut.
Tuohon käy siis oikeastaan sitten mikä vaan distro. Jos siis haluat valmiiksi vähän enemmän esimerkiksi multimedia ominaisuuksia, niin joku Ubuntu pohjainen voisi olla myös ihan ok. Itselle LibreELEC täysin vieras, mutta toki siitäkin näyttää Intel/AMD buildi löytyvän, joten sen puolesta varmasti toimii. Seuraava kysymys varmaan onkin kerneli, että millä configilla se on käännetty.

Edit: perutaanpas sittenkin omat puheet, tämä olikin Kodiin pohjautuva eli tehty juuri multimedia käyttöön.

Yleensä Apple käyttäjät käyttää vain mäkkiä ja Applen cloudia, joten todellisuudessa ei välttämättä löydy loputonta määrää käyttäjiä, jotka haluaisi kuvia synkata Linuxiin. Nopea Googlaus näytti, että monelle on kelvannut/riittänyt USB kaapelin yli tallennus. iOS on tehty tarkoituksella mahdollisimman suljetuksi systeemiksi. Ei ole tietenkään Applen etu, jos joku synkkaa kuvansa omalle Linux PC:lle, eikä heidän cloudiin. ;)
 
Viimeksi muokattu:
Löytyi Nextcloud, joka näyttäisi siltä että voisi ajaa asian.

eli LibreELEC + Kodi + Nextcloud voisi olla hyvä kombo.

Voisi siis ottaa kopion pc:lle ja tälle sitten joku halpa cloud kopio. Ei huvittaisi maksella 10€/kk Applelle 2Tb iCloudista.
 
Löytyi Nextcloud, joka näyttäisi siltä että voisi ja asian.

eli LibreELEC + Kodi + Nextcloud voisi olla hyvä kombo.

Voisi siis ottaa kopion pc:lle ja tälle sitten joku halpa cloud kopio. Ei huvittaisi maksella 10€/kk Applelle 2Tb iCloudista.
Kuulostaa ihan hyvältä viritykseltä. Itsellä on iCloud firman kortilla maksettuna, niin ei ole tullut säädettyä mitään synkkausta aikoihin, vaikka Linuxia siis käytän pöytäkoneissa ja servereissä, Applen rautaa sitten kannettavassa muodossa (läppäri, puhelin ja kello).
 
Miten PopOS:ssa, tai yleensäkään Linuxissa, avataan GUI softa, tässä tapauksessa esim. virt-manager, kun on kirjautunut sisään rajoitetulla tilillä, jolla ei ole siis oikeuksia tuon Virt-managerin käyttöön?

Kokeilin terminaalin kautta käynnistää sitä, sen jälkeen kun olin kirjautunut terminaalissa superuser-oikeudet omaavana käyttäjänä sisään komennolla su -l <superuser>, mutta saan vastaan virheilmoituksen:
Koodi:
(virt-manager:8037): Gtk-WARNING **: 14:32:10.873: cannot open display:

Virt-manager toimii vain esimerkkinä, olen tietoinen virsh-komennosta...

[edit] En siis halua lisätä käyttäjän oikeuksia, vaan käynnistää sovellus toisenna käyttäjänä, jolla on sopivat oikeudet. Onko toi edes mahdollista?
 
Viimeksi muokattu:
Miten PopOS:ssa, tai yleensäkään Linuxissa, avataan GUI softa, tässä tapauksessa esim. virt-manager, kun on kirjautunut sisään rajoitetulla tilillä, jolla ei ole siis oikeuksia tuon Virt-managerin käyttöön?

Kokeilin terminaalin kautta käynnistää sitä, sen jälkeen kun olin kirjautunut terminaalissa superuser-oikeudet omaavana käyttäjänä sisään komennolla su -l <superuser>, mutta saan vastaan virheilmoituksen:
Koodi:
(virt-manager:8037): Gtk-WARNING **: 14:32:10.873: cannot open display:

Virt-manager toimii vain esimerkkinä, olen tietoinen virsh-komennosta...
Ihan yksinkertaisuudessaan lisää käyttäjä libvirt groupiin, jonka jälkeen pitäisi toimia ihan normaalikäytäjänä:
Bash:
sudo usermod -aG libvirt $(whoami)
 
Miten PopOS:ssa, tai yleensäkään Linuxissa, avataan GUI softa, tässä tapauksessa esim. virt-manager, kun on kirjautunut sisään rajoitetulla tilillä, jolla ei ole siis oikeuksia tuon Virt-managerin käyttöön?

Kokeilin terminaalin kautta käynnistää sitä, sen jälkeen kun olin kirjautunut terminaalissa superuser-oikeudet omaavana käyttäjänä sisään komennolla su -l <superuser>, mutta saan vastaan virheilmoituksen:
Koodi:
(virt-manager:8037): Gtk-WARNING **: 14:32:10.873: cannot open display:

Virt-manager toimii vain esimerkkinä, olen tietoinen virsh-komennosta...

su nollaa oletuksena environmentin, joten DISPLAY ei välity. Kannattanee käyttää sudoa tai muuten järjestää DISPLAY-asetus perille.
 
@JRan En siis halua lisätä käyttäjän oikeuksia, vaan pelkästään hetkellisesti startata sovellus toisena käyttäjänä, jos se on vain mahdollista.

@oongee En halua antaa kys. käyttäjälle sudotus oikeuksia, edes rajoitettuja sellaisia.

Välillä tulee tarve käynnistää joku graaffinen sovellus kun on kirjautunut sisään rajoitetulla tilillä, niin etsin tapaa (jos sellaista edes on), jolla sen voisi käynnistää toisena käyttäjänä ilman, että vaihdan koko DE:n toisen käyttäjän DE:ksi.

Miten tuon DISPLAY-asetuksen voisi järjestää hetkellisesti sille yhdelle sovelle?
 
@JRan En siis halua lisätä käyttäjän oikeuksia, vaan pelkästään hetkellisesti startata sovellus toisena käyttäjänä, jos se on vain mahdollista.

@oongee En halua antaa kys. käyttäjälle sudotus oikeuksia, edes rajoitettuja sellaisia.

Välillä tulee tarve käynnistää joku graaffinen sovellus kun on kirjautunut sisään rajoitetulla tilillä, niin etsin tapaa (jos sellaista edes on), jolla sen voisi käynnistää toisena käyttäjänä ilman, että vaihdan koko DE:n toisen käyttäjän DE:ksi.

Miten tuon DISPLAY-asetuksen voisi järjestää hetkellisesti sille yhdelle sovelle?
Emmanuele Bassi GNOMEn kehittäjä on muotoillut asian näin:
there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you are literally running millions of lines of code that have not been audited properly to run under elevated privileges; you are also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc.You are opening up a massive, gaping security hole
 
Toi nyt menee taas ohi... Tuossa puhutaan rootista, ei toisesta käyttäjästä, jolla on eri oikeudet (eri oikeudet, mutta ei root-/su-/sudo-oikeudet)...
Aa, ymmärsin vähän väärin alkuperäisestä komennostasi sen mitä olet tekemässä. Mutta jos ajat seuraavan komennon käyttäjänä millä olet ajamassa virt-manageria.
Bash:
export DISPLAY=:0

Toki DISPLAY sen mukaan, joka on oikeasti kirjautuneella käyttäjällä käytössä.
 
Aa, ymmärsin vähän väärin alkuperäisestä komennostasi sen mitä olet tekemässä. Mutta jos ajat seuraavan komennon käyttäjänä millä olet ajamassa virt-manageria.
Bash:
export DISPLAY=:0

Toki DISPLAY sen mukaan, joka on oikeasti kirjautuneella käyttäjällä käytössä.

No nyt alko toimimaan! Kiitos!

[edit] Tai ei suoraan vaan vaati vielä tämän rimpsun antamisen xhost +si:localuser:<toinenkäyttäjä> että alkoi toimimaan.

Kokonaisuus menee siis näin:
Koodi:
> xhost +si:localuser:<toinenkäyttäjä>
> echo $DISPLAY                               
:1
> su -l <toinenkäyttäjä>
> export DISPLAY=:1
> <käynnistettäväGUIsofta>

Kun ei enään tarvitse <käynnistettäväGUIsoftaa>, niin:
Koodi:
> exit
> xhost -si:localuser:<toinenkäyttäjä>
 
Viimeksi muokattu:
Noissa molemmissa pitää lisätä <käyttäjälle> oikeudet X-serveriin komennolla xhost +si:localuser:<käyttäjä>, muuten ei suostu käynnistämään sovellusta. Ja kun lopettaa, niin exitin jälkeen xhost -si:localuser:<käyttäjä>, jolla poistetaan ne oikeudet.
 
Emmanuele Bassi GNOMEn kehittäjä on muotoillut asian näin:
Mitä tuossa tarkoitetaan tällä "you are also running code that will touch files inside your $HOME ..."? Miten oman kotikansion tiedostojen käsittelyyn vaikuttaa se, ajetaanko ohjelmaa roottina vai ei?
 
Mitä tuossa tarkoitetaan tällä "you are also running code that will touch files inside your $HOME ..."? Miten oman kotikansion tiedostojen käsittelyyn vaikuttaa se, ajetaanko ohjelmaa roottina vai ei?
Niin siis tämän jälkeen jos ohjelma luo/kirjoittaa tiedostoja, kotihakemistosi tiedostot ovat root käyttäjän tiedostoja, joten normaali käyttäjä ei voi lukea/kirjoittaa/poistaa niitä.

Pointti oli siis se, että root käyttäjänä ei Linuxissa kuulu ajaa mitään graafista. Ja juu kyllä jotkut softat on toki tehty ja testattu tätä varten, mutta silti kannattaa pysytellä komentorivillä sen root käyttäjän kanssa.

Tässä pari malliesimerkkiä jotka tulivat mieleen. Lähinnä siis millaisia bugeja softissa saattaa olla ja softat oli kuitenkin ihan suht laajasti käytössä:

 
Niin siis tämän jälkeen jos ohjelma luo/kirjoittaa tiedostoja, kotihakemistosi tiedostot ovat root käyttäjän tiedostoja, joten normaali käyttäjä ei voi lukea/kirjoittaa/poistaa niitä.

Pointti oli siis se, että root käyttäjänä ei Linuxissa kuulu ajaa mitään graafista. Ja juu kyllä jotkut softat on toki tehty ja testattu tätä varten, mutta silti kannattaa pysytellä komentorivillä sen root käyttäjän kanssa.

Tässä pari malliesimerkkiä jotka tulivat mieleen. Lähinnä siis millaisia bugeja softissa saattaa olla ja softat oli kuitenkin ihan suht laajasti käytössä:

Ok, nyt tajusin. Eli tässä kohtaa kyseessä oli lähinnä mukavuushaitta (tai esittämiesi bugisten ohjelmien kohdalla vähän isompikin haitta).

Tulkitsin lainauksen ensin niin, että kotihakemiston tiedostot olisi jotenkin paremmin turvassa (esim. haittaohjelmilta), jos ohjelmia ajaa tavallisena käyttäjänä eikä roottina. Mutta tämähän olisi aika huono vinkki. Kaikki muut tiedostot kyllä olisivat paremmin turvassa, mutta kotikansion tiedostojen varastamiseen/tuhoamiseen ei yleisesti ottaen tarvitse root-oikeuksia.
 
Ok, nyt tajusin. Eli tässä kohtaa kyseessä oli lähinnä mukavuushaitta (tai esittämiesi bugisten ohjelmien kohdalla vähän isompikin haitta).

Tulkitsin lainauksen ensin niin, että kotihakemiston tiedostot olisi jotenkin paremmin turvassa (esim. haittaohjelmilta), jos ohjelmia ajaa tavallisena käyttäjänä eikä roottina. Mutta tämähän olisi aika huono vinkki. Kaikki muut tiedostot kyllä olisivat paremmin turvassa, mutta kotikansion tiedostojen varastamiseen/tuhoamiseen ei yleisesti ottaen tarvitse root-oikeuksia.
Juuri oikein ymmärretty, eli tosiaan seuraavalla kerralla softa ei välttämättä käynnisty ollenkaan jos se on aiemmin suoritettu roottina. Tai se ei pysty lukea kirjoittaa omia tiedostojaan.

Mutta tosiaan root käyttäjällä saa ihan oikeaa tuhoa aikaan, jos suorittaa sokkona koodia ja sinne on lipsahtanut vähän typoja ja kukaan ei ole vaivautunut kunnolla testaamaan sitä.

Yleensä vaarallisimmat ovat rm -rf komennot ympäristömuutujista, shelliparametreista tms. Komento muuttuu pahimmillaan muotoon:
Bash:
rm -rf /oikea_hakemisto /

Toki dd komennolla saa myös ikävää jälkeä aikaiseksi.
 
Kokeilin tuota POP OS jakelua. Ongelmaksi muodostui ettei ohjelmien tiedostonhallinta suostu näyttämään kuin ainoastaan ne kansiot, jotka ovat samalla kiintolevyllä kuin Linux jakelu. Näin ollen ulkoisella kovalevyllä olevia tiedostoja ei saa näkyville. Käyttöjärjestelmän kautta ulkoiset kovalevyt ja usb-tikut näkyvät ja tiedostoja voi käsitellä mutta ei softien kautta. Mikä neuvoksi?
 
Kokeilin tuota POP OS jakelua. Ongelmaksi muodostui ettei ohjelmien tiedostonhallinta suostu näyttämään kuin ainoastaan ne kansiot, jotka ovat samalla kiintolevyllä kuin Linux jakelu. Näin ollen ulkoisella kovalevyllä olevia tiedostoja ei saa näkyville. Käyttöjärjestelmän kautta ulkoiset kovalevyt ja usb-tikut näkyvät ja tiedostoja voi käsitellä mutta ei softien kautta. Mikä neuvoksi?

Onkohan kyseessä Flatpak-softa jolla jostain syystä puuttuu oikeudet käpistellä ulkoisia laitteita?
 
Ei ole ollut käyttänyt PopOSia nyt hetkeen, mutta muistelisin että jotain Flatpakien oikeuksia sai säädettyä Pop Shopin kautta menemällä sovelluksen tietoihin ja jostain kulmasta pääsi säätämään oikeuksia.
 
Jostain syystä useimmat Steam pelit eivät suostu käynnistymään. Joko pelin Laucherin käynnistys kestää useita minuutteja, jonka jälkeen Steam jumittuu ennen pelin päävalikon latautumista tai sitten tulee herja "ERROR: DX12 is not supported on your system". Samat pelit kuitenkin pyörivät ongelmitta samalla hardwarella Windows 10 kautta, joten miten ne saisi toimimaan myös Linuxin kautta?

Näytönohjain GeForce GTX 780 jossa uusimmat päivitykset, kokeiltu myös eri Proton jakeluilla tuloksetta.
 
Jostain syystä useimmat Steam pelit eivät suostu käynnistymään. Joko pelin Laucherin käynnistys kestää useita minuutteja, jonka jälkeen Steam jumittuu ennen pelin päävalikon latautumista tai sitten tulee herja "ERROR: DX12 is not supported on your system". Samat pelit kuitenkin pyörivät ongelmitta samalla hardwarella Windows 10 kautta, joten miten ne saisi toimimaan myös Linuxin kautta?

Näytönohjain GeForce GTX 780 jossa uusimmat päivitykset, kokeiltu myös eri Proton jakeluilla tuloksetta.

Onhan nvidian ajurit eikä open source ajureita?
 
Jostain syystä useimmat Steam pelit eivät suostu käynnistymään. Joko pelin Laucherin käynnistys kestää useita minuutteja, jonka jälkeen Steam jumittuu ennen pelin päävalikon latautumista tai sitten tulee herja "ERROR: DX12 is not supported on your system". Samat pelit kuitenkin pyörivät ongelmitta samalla hardwarella Windows 10 kautta, joten miten ne saisi toimimaan myös Linuxin kautta?

Näytönohjain GeForce GTX 780 jossa uusimmat päivitykset, kokeiltu myös eri Proton jakeluilla tuloksetta.
jos on pelkästään win versio pelistä ni eihän se päälle lähdekkään. Steamissä näkyy jos on win only. Jos haluaa Win pelejä linukalla pelata pitää wine yms. emulaattori asentaa
 
jos on pelkästään win versio pelistä ni eihän se päälle lähdekkään. Steamissä näkyy jos on win only. Jos haluaa Win pelejä linukalla pelata pitää wine yms. emulaattori asentaa
Johan tuossa mainittiin että Protonia käytetty. Protonilla siis saa ainakin suurimman osan Steamin windows-peleistä toimimaan ihan heittämällä linuxissa. Ei siis tarvitse mitään wineä tms erikseen. Yhtäkkiä ei tule mieleen kuin ehkä pari peliä jotka ei tuolla Protonilla ole toimineet.

Itsellänikin on nyt lähiaikoina tuo Steam vähän kiukutellut, joskus käynnistyy ihn järkyttävän pitkään ja joskus tulee vain joku "Launching Steam" taskbariin mutta mitään ei tule näkyviin mutta tuon näkymättömän ikkunan tappamalla Steam lähtee kuitenkin hetken kuluttua käyntiin. Tuota kiukkuamista on nyt ollut ehkä kuukauden verran säännöllisen epäsäännöllisesti, varmaan joku paskempi päivitys Steamista julkaistu joka tökkii joillakin.
 
Johan tuossa mainittiin että Protonia käytetty. Protonilla siis saa ainakin suurimman osan Steamin windows-peleistä toimimaan ihan heittämällä linuxissa. Ei siis tarvitse mitään wineä tms erikseen. Yhtäkkiä ei tule mieleen kuin ehkä pari peliä jotka ei tuolla Protonilla ole toimineet.

Itsellänikin on nyt lähiaikoina tuo Steam vähän kiukutellut, joskus käynnistyy ihn järkyttävän pitkään ja joskus tulee vain joku "Launching Steam" taskbariin mutta mitään ei tule näkyviin mutta tuon näkymättömän ikkunan tappamalla Steam lähtee kuitenkin hetken kuluttua käyntiin. Tuota kiukkuamista on nyt ollut ehkä kuukauden verran säännöllisen epäsäännöllisesti, varmaan joku paskempi päivitys Steamista julkaistu joka tökkii joillakin.
Aa, pitäs lukee vähä tarkemmin ennenku vastaa
 
Jostain syystä useimmat Steam pelit eivät suostu käynnistymään. Joko pelin Laucherin käynnistys kestää useita minuutteja, jonka jälkeen Steam jumittuu ennen pelin päävalikon latautumista tai sitten tulee herja "ERROR: DX12 is not supported on your system". Samat pelit kuitenkin pyörivät ongelmitta samalla hardwarella Windows 10 kautta, joten miten ne saisi toimimaan myös Linuxin kautta?

Näytönohjain GeForce GTX 780 jossa uusimmat päivitykset, kokeiltu myös eri Proton jakeluilla tuloksetta.

Nämä nimeltä mainitsemattomat Steam pelit ovat varmaan uudehkoja DX12 pelejä. 780 GTX:llä ei ole täyttä DX12 tukea, ja on mahdollista että Windowsissa nämä pelit menevät käynnistettäessä DX11 tilaan. Linux-Steamissa täytyy todennäköisesti lisätä pelikohtaisia käynnistysparametrejä jotta sama tapahtuisi.
 
Oisko jollakin antaa vinkkiä, miten saan Fedorassa standardi näppäinyhdistelmät toimimaan, kun keyboard layout on Finnish (Windows)? Tällä hetkellä Shift + 7 ei anna kauttaviivaa, niin kuin pitäisi, vaikka kaikista muista numeronäppäimistä tulee just se merkki, mikä pitääkin, kun Shift on pohjassa. 7-näppäin toimii muuten normaalisti. Shift + 7 on ainoa, joka ei toimi. Nyt saan /-merkin ainoastaan numpadin näppäimestä.

Edit: Näköjään Cinnamonissa Shift+7 on Check spelling ja siksi ei toimi. :/
 
Viimeksi muokattu:
Edit: Näköjään Cinnamonissa Shift+7 on Check spelling ja siksi ei toimi. :/

Joku tässä vielä on solmussa koska minun ymmärtääkseni ainakin Mint-Cinnamonissa spell check on shift-F7 eli shift ja functionäppäin nro7 eikä numeronäppäin 7 josta kyllä pitäisi tulla se kauttaviiva jos asetukset on oikein. joku muu siis ehkä on asetuksissa pielessä. En tiedä fedora-cinnamonista mutta olisin hyvin hämmästynyt jos he olisivat saaneet päähänsä sitoa spell checkin shift-numeronäppäin7 yhdistelmään enkä nopeasti googlatessa löytänyt fedora-cinnamonin keyboard layoutista oikein mitään tietoja.
 
Joku tässä vielä on solmussa koska minun ymmärtääkseni ainakin Mint-Cinnamonissa spell check on shift-F7 eli shift ja functionäppäin nro7 eikä numeronäppäin 7 josta kyllä pitäisi tulla se kauttaviiva jos asetukset on oikein. joku muu siis ehkä on asetuksissa pielessä. En tiedä fedora-cinnamonista mutta olisin hyvin hämmästynyt jos he olisivat saaneet päähänsä sitoa spell checkin shift-numeronäppäin7 yhdistelmään enkä nopeasti googlatessa löytänyt fedora-cinnamonin keyboard layoutista oikein mitään tietoja.

Kyseessä joku ns. kompakti näppis jossa F<numero>-näppäimet tyyliin Fn+<numero> combon takana ja se sekoilee jotenkin?
 
Onhan nvidian ajurit eikä open source ajureita?

Löytyy Nvideon viralliset driverit Nvidia driver 470. Kokeilin asentaa myös uudestaan mutta ei vaikutusta yhteensopivuuteen.

Steamin kautta toimivat ainoastaan suoraan Linus Torvelolle yhteensopivat pelit ja Proton yhteensopivista pyörii ainoastaan alkuperäinen Deus EX. Kaikilla muilla peleillä, myös hyvin vanhoilla tulee joko DX12 viittaava virheilmoitus, Steam jää jumiin Launcheriin tai peli jumittuu ensimmäiseen tai toiseen latausruutuun, jonka jälkeen Steam jää jumiin.
 
Joku tässä vielä on solmussa koska minun ymmärtääkseni ainakin Mint-Cinnamonissa spell check on shift-F7 eli shift ja functionäppäin nro7 eikä numeronäppäin 7 josta kyllä pitäisi tulla se kauttaviiva jos asetukset on oikein. joku muu siis ehkä on asetuksissa pielessä. En tiedä fedora-cinnamonista mutta olisin hyvin hämmästynyt jos he olisivat saaneet päähänsä sitoa spell checkin shift-numeronäppäin7 yhdistelmään enkä nopeasti googlatessa löytänyt fedora-cinnamonin keyboard layoutista oikein mitään tietoja.

Ok, googlasin noita pikaisesti ja katsoin, että Shift + 7, mutta voi olla, että oli Shift + F7. En vielä ole päässyt kotiin tutkimaan lisää. Jos jollain on ideaa, saa ehdottaa.
 
Kyseessä joku ns. kompakti näppis jossa F<numero>-näppäimet tyyliin Fn+<numero> combon takana ja se sekoilee jotenkin?

Kyseessä Logitechin Craft -näppis, joten tuosta ei kai ole kyse. Testailen vielä Gnomella ja KDE:llä kun pääsen koneen ääreen, josko niillä toimisi normaalisti.
 
Löytyy Nvideon viralliset driverit Nvidia driver 470. Kokeilin asentaa myös uudestaan mutta ei vaikutusta yhteensopivuuteen.

Steamin kautta toimivat ainoastaan suoraan Linus Torvelolle yhteensopivat pelit ja Proton yhteensopivista pyörii ainoastaan alkuperäinen Deus EX. Kaikilla muilla peleillä, myös hyvin vanhoilla tulee joko DX12 viittaava virheilmoitus, Steam jää jumiin Launcheriin tai peli jumittuu ensimmäiseen tai toiseen latausruutuun, jonka jälkeen Steam jää jumiin.

Nyt menee arvailuksi mutta voisi kokeilla Steamissä pelin kohdalta oikealla klikkauksella ottaa "Properties" ja sieltä launch options kohtaan laittaa
PROTON_USE_WINED3D11=1 %command%

Kaipa tuon ympäristömuuttujan voisi asettaa globaaliksikin jos tuolla korjautuu?
 
Nyt menee arvailuksi mutta voisi kokeilla Steamissä pelin kohdalta oikealla klikkauksella ottaa "Properties" ja sieltä launch options kohtaan laittaa
PROTON_USE_WINED3D11=1 %command%

Kaipa tuon ympäristömuuttujan voisi asettaa globaaliksikin jos tuolla korjautuu?
Laitanpa tuon niksin jatkoksi yhden rimpsun millä joku vähän uudempi peli lähti toimimaan, eli ei käynnistetä steamia perinteisesti suoraan kuvakkeesta / valikosta vaan komentoriviltä seuraavanlaisella loitsulla:
Koodi:
VK_ICD_FILENAMES=NONE steam
Ihan tarkkaan en edes tiedä mitä tuo tekee mutta tuo korjasi yhden pelin herjat näytönohjaimesta. Jotenkin tuo johonkin Protonin näytönohjainjuttuun liittyi.
 
Kyseessä Logitechin Craft -näppis, joten tuosta ei kai ole kyse. Testailen vielä Gnomella ja KDE:llä kun pääsen koneen ääreen, josko niillä toimisi normaalisti.

Nyt pääsin testaamaan ja Gnomessa näppis toimii niin kuin pitää ja saan shift + 7:lla kirjoitettua //////.

Ongelma on siis Cinnamonissa. :confused2:
 
Oisko jollakin antaa vinkkiä, miten saan Fedorassa standardi näppäinyhdistelmät toimimaan, kun keyboard layout on Finnish (Windows)? Tällä hetkellä Shift + 7 ei anna kauttaviivaa, niin kuin pitäisi, vaikka kaikista muista numeronäppäimistä tulee just se merkki, mikä pitääkin, kun Shift on pohjassa. 7-näppäin toimii muuten normaalisti. Shift + 7 on ainoa, joka ei toimi. Nyt saan /-merkin ainoastaan numpadin näppäimestä.

Edit: Näköjään Cinnamonissa Shift+7 on Check spelling ja siksi ei toimi. :/
Kokeile ruotsinkielisen näppäimistön us-alavarianttia. Erikoismerkit menevät us-paikoille, mutta ääkköset tarvitsevat alt gr:n kaveriksi toimiakseen.
 

Liitteet

  • KB_United_States-NoAltGr.svg.png
    KB_United_States-NoAltGr.svg.png
    99,9 KB · Luettu: 32

Statistiikka

Viestiketjuista
262 374
Viestejä
4 548 833
Jäsenet
74 978
Uusin jäsen
Omi77

Hinta.fi

Back
Ylös Bottom