Linux OS - info, how-to, pitanja, novosti, savjeti, problemi...

[tomek@vz]

Landlock is a Linux API that lets applications explicitly declare which resources they are allowed to access. Its philosophy is similar to OpenBSD’s unveil() and (less so) pledge(): programs can make a contract with the kernel stating, “I only need these files or resources — deny me everything else if I’m compromised.”
It provides a simple, developer-friendly way to add defense-in-depth to applications. Compared to traditional Linux security mechanisms, Landlock is vastly easier to understand and integrate.
This post is meant to be an accessible introduction, and hopefully persuade you to give Landlock a try.
↫ prizrak.me blog

Here is a fact-based summary of the story contents:

The numbers on Linux installations are finally starting to show some life, and despite what some people might say, it's not all down to just one or two major moves. But, undeniably, the rise of Linux gaming has something to do with it.
After decades of being inviable as a primary gaming platform, things are changing fast in the world of Linux gaming. This time it doesn't feel like a flash in the pan, but trying to understand why it feels that way to me turns out to be a little complicated.

> Why everyone suddenly cares about Linux gaming—and it's not just the Steam Deck

Miguel Ojeda has already submitted the core Rust programming language infrastructure updates intended for the Linux 6.19 merge window. In the pull request he also notes that moving forward the minimum supported Rust version for compiling the Linux kernel will likely follow whatever the minimum Rust version currently in use by the latest Debian stable release.

The Rust for Linux 6.19 updates include adding support for Syn as a parsing library for parsing strams of Rust tokens into a syntax tree of Rust source code.

Rust in this next version of the Linux kernel also continues enhancing its "kernel" crate with support for more features, support for C string literals in Rust 1.77+, and documentation updates.

As part of the documentation updates it's noted in the pull request:

> Rust Updates For Linux 6.19, Rust Minimum Baseline To Likely Follow Debian Stable

KubeCon + CloudNativeCon North America 2025, Atlanta: After being founded in 1992 in Germany, open source and Linux vendor SUSE built itself into a well-known brand across Europe, Asia, and Latin America. Yet SUSE’s footprint in North America has never been anything close to that of its major enterprise open source Linux competitor, Red Hat, which dominates the Linux and open source market here.
But SUSE’s new chief marketing officer, Margaret Dawson, who began her new job in September, says she is already working to change that scenario and earn SUSE a bigger slice of the pie in the North American marketplace.

> KubeCon 2025 Report: SUSE Is Diving Deeper Into the Channel

[tomek@vz]

Steam's November 2025 survey shows Linux gaming climbed to its highest share in a decade "thanks to the success of the Steam Deck, the underlying Steam Play (Proton) software, and now further excitement thanks to the upcoming Steam Machine and Steam Frame," writes Phoronix's Michael Larabel. From the report:

[xlr]

Pokušavam na Debian VM-u mountati NFS share na NAS-u i, osim što sam to radio gro puta i koristim identične fstab komande koje sam uvijek koristio, nemam uopće ideju zašto mi je ne želi mountati nakon reboota. Ako ručno mountam nakon boota s "mount -a" onda sve radi.

Koji vi pristup koristite za mountanje shareova (multimedija), kroz fstab (i koju komandu) ili kao service (ovo nisam do sada koristio)?

Ne kužim zašto mi recimo Proxmox uredno spaja na NFS share, a Debian VM neće:

10.27.20.2:/media /mnt/media nfs vers=3,nouser,atime,auto,retrans=2,rw,dev,exec 0 0

Probao sam dodati i "_netdev", ali nema promjene. Probao sam i čekati x minuta u nadi da će se mount dignuti naknadno.

[tomek@vz]

Autor xlr

Pokušavam na Debian VM-u mountati NFS share na NAS-u i, osim što sam to radio gro puta i koristim identične fstab komande koje sam uvijek koristio, nemam uopće ideju zašto mi je ne želi mountati nakon reboota. Ako ručno mountam nakon boota s "mount -a" onda sve radi.

Koji vi pristup koristite za mountanje shareova (multimedija), kroz fstab (i koju komandu) ili kao service (ovo nisam do sada koristio)?

Ne kužim zašto mi recimo Proxmox uredno spaja na NFS share, a Debian VM neće:

10.27.20.2:/media /mnt/media nfs vers=3,nouser,atime,auto,retrans=2,rw,dev,exec 0 0

Probao sam dodati i "_netdev", ali nema promjene. Probao sam i čekati x minuta u nadi da će se mount dignuti naknadno.

Probaj mu implementirati delay...moja je pretpostavka da u trenutku kad zeli mountat da mreza nije spremna pa posto nemoze do ciljnog servera - mount ne uspijeva a kasnije ni ne pokusava. Cekiraj i autofs. Imas cak opciju mountanja mount pointa tek kad neka aplikacija zatrazi pristup lokaciji.

[strikoo]

Proxmox je debian
mi na valjd 200 debiana imamo nfs u fstabu

[domy_os]

Jesi li pregledao logove? Čini se kao da presporo digne mrežu ili DHCP kasni.

EDIT: Kasnim, briši.

[Bono]

Autor tomek@vz

Probaj mu implementirati delay...moja je pretpostavka da u trenutku kad zeli mountat da mreza nije spremna pa posto nemoze do ciljnog servera - mount ne uspijeva a kasnije ni ne pokusava. Cekiraj i autofs. Imas cak opciju mountanja mount pointa tek kad neka aplikacija zatrazi pristup lokaciji.

Da treba staviti delay bar 10-15s, onda ce mountati pri bootu.

Sent from my SM-S931B using Tapatalk

[Neo-ST]

Autor tomek@vz

Probaj mu implementirati delay...moja je pretpostavka da u trenutku kad zeli mountat da mreza nije spremna pa posto nemoze do ciljnog servera - mount ne uspijeva a kasnije ni ne pokusava. Cekiraj i autofs. Imas cak opciju mountanja mount pointa tek kad neka aplikacija zatrazi pristup lokaciji.

Zar ne postoji neki "queue" sistem kod bootanja servisa nego ih moraš ovako napamet delayati ?
Tipa:
Service 1 up? If yes -> Load Service 2. If not -> wait for Service 1.
Service 2 up? If yes -> Load Service 3, itd.

[Dule]

Autor Neo-ST

Zar ne postoji neki "queue" sistem kod bootanja servisa nego ih moraš ovako napamet delayati ?
Tipa:
Service 1 up? If yes -> Load Service 2. If not -> wait for Service 1.
Service 2 up? If yes -> Load Service 3, itd.

Postoji, zove se systemd

Vjerojatno bi trebalo dodati ovo u fstab mount opcije:

x-systemd.automount
x-systemd.after=network-online.target

npr.

 10.27.20.2:/media /mnt/media nfs vers=3,nouser,atime,auto,retrans=2,rw,dev,exec,x-systemd.automount,x-systemd.after=network-online.target 0 0

[xlr]

Hvala, ovo je napravilo razliku "x-systemd.after=network-online.target" i to sad radi kako sam zamišljao. Dodao sam tvoje parametre, a taj naglašeni mi je izgleda falio. Naletio sam na sličan savjet, vrtilo se oko "_netdev" koji kod mene nema funkciju, ako je taj parametar uopće još aktualan:

https://www.reddit.com/r/linuxmint/c...mment/l8yw3g1/

Hvala svima još jednom. Ljepše je ovdje nego u W11 temi

[Neo-ST]

Autor xlr

Hvala svima još jednom. Ljepše je ovdje nego u W11 temi

Uživaj dok traje. Mladen je probao Linux i svidio mu se.

[xlr]

Autor Neo-ST

Uživaj dok traje. Mladen je probao Linux i svidio mu se.

Hahahaha, once you go black...

[xlr]

Svašta se tu očito promjenilo između Trixiea i Bookworka. Kao, odlučih dignuti čisti Debian 13 VM umjesto da upgrejdam stari i samo prebacim mountove i Docker podatke na nj, pokrenem i zaboravim na to sljedećih godinu dana. Nejde baš bajno, dugo nisam ovoliko udarao u zid

Kontejneri mi se ne žele pokrenuti poslije reboota, bace exit code 128 "error while mounting volume..." i vezano je za NFS mount o kojem sam prije pisao. Taj mount se na kraju uspješno digne, ali očito prekasno za Docker.

Srećom vikend je pred nama, imat ću šta raditi.

[tomek@vz]

Autor xlr

Svašta se tu očito promjenilo između Trixiea i Bookworka. Kao, odlučih dignuti čisti Debian 13 VM umjesto da upgrejdam stari i samo prebacim mountove i Docker podatke na nj, pokrenem i zaboravim na to sljedećih godinu dana. Nejde baš bajno, dugo nisam ovoliko udarao u zid

Kontejneri mi se ne žele pokrenuti poslije reboota, bace exit code 128 "error while mounting volume..." i vezano je za NFS mount o kojem sam prije pisao. Taj mount se na kraju uspješno digne, ali očito prekasno za Docker.

Srećom vikend je pred nama, imat ću šta raditi.

Hint: systemd izmedu ostalog...poceli su kao i svi sa prebacivanjem configova iz /etc u /usr/etc/ i /usr/local/etc. Jedna od mozda najvecih izmjena zadnjih 5 godina na "standarda" datotecne strukture. Stavi da se docker starta nakon nfs-a i sve 5.

[xlr]

Mislim da je to sad to.

systemctl edit docker.service

Dodao:

[Unit]
After=remote-fs.target
RequiresMountsFor=/mnt/media

Morao sam specificirati mount, nije radilo ako umjesto RequiresMountFor stavim "Requires=remote-fs.target".

[tomek@vz]

Odlicno

[Dule]

Autor tomek@vz

poceli su kao i svi sa prebacivanjem configova iz /etc u /usr/etc/ i /usr/local/etc. Jedna od mozda najvecih izmjena zadnjih 5 godina na "standarda" datotecne strukture

Ovo mi je novost, prvi put čujem. Arch i Gentoo su i dalje na /etc, a Arch prati upstream kad god je to moguće...

Imaš neki link? Google mi izbacuje jedino nekakve openSUSE članke gdje mi se na prvu čini da je to dosta opinionated promjena openSUSE developera?

[tomek@vz]

Autor Dule

Ovo mi je novost, prvi put čujem. Arch i Gentoo su i dalje na /etc, a Arch prati upstream kad god je to moguće...

Imaš neki link? Google mi izbacuje jedino nekakve openSUSE članke gdje mi se na prvu čini da je to dosta opinionated promjena openSUSE developera?

E sad da ga hebes nemogu nac to, u sjecanju mi je da sam negdje pred cca godinu dana procitao da je to systemd uvjetovana izmjena, ne samo hir OpenSuse devova ali trenutno mi bas trazenje nejde (14 satna sihta...ne pitaj):

In the longterm, /etc will only contain configuration files that are host-specific or have been modified by the admin. All distribution specific configuration files are located below /usr/ and are not modifiable by the admin (with a read-only root filesystem, this would not even be possible). Instead, the applications need to be enhanced, as far as possible and necessary, to read the configuration files from several locations. If there is a common location for that configuration file already below /usr, e.g. because the application supports already hermetic-usr, this location should stay and not be moved. This would only confuse users.

> openSUSE:Packaging UsrEtc


Kolko vidim vise bi trebalo utjecati na MicroOS (immutable OS) ali znam da drljaju s tim vec od Leap-a 15 jer sam im spominjao mater kod upgrejda sa 15.6 na 16 na par masina.


Red Hat dokumentacija takoder spominje:

The /etc/ directory is reserved for configuration files that are local to the machine. It should contain no binaries; any binaries should be moved to /bin/ or /sbin/.



/usr/etc This directory is used for system-wide configuration files.