@pid_eins@mastodon.social
@pid_eins@mastodon.social avatar

pid_eins

@pid_eins@mastodon.social

⛵ I write software. ⛵

This profile is from a federated server and may be incomplete. Browse more on the original instance.

pid_eins, to random
@pid_eins@mastodon.social avatar

Even though Fedora probably is kinda popular among developers, it sometimes baffles me what is and what isn't packaged in Fedora.

I mean come on, how is it possible that there's no meson mode packaged for emacs on Fedora?

I mean, it's pretty obvious: if Fedora wants to be taken seriously as a developer platform, I think it's pretty obvious that this is a glaring omission, like no other! 🤓

pid_eins,
@pid_eins@mastodon.social avatar

@jamesh it doesn't show up in melpa if I do M-x package-list-packages however… Seems MELPA is hosed on Fedora Emacs?

pid_eins,
@pid_eins@mastodon.social avatar

@jamesh ah, indeed. thanks. that worked.

didn't realize the difference between those repositories...

ELPA seems kinda useless though? requires copyright assignment, uh? what is this, 1995? but meh, sounds like something typically gnu...

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣2️⃣ Here's the 12th installment of posts highlighting key new features of the upcoming v256 release of systemd.

Putting a PC to sleep is complicated business and there are different mechanisms available to achieve this on Linux. Broadly speaking there is suspend-to-ram and suspend-to-disk, as well as combinations of this: one where we suspend to both, and one where we first suspend-to-ram and then later change to suspend-to-disk, if we have slept for a long time, or the battery is running empty.

pid_eins,
@pid_eins@mastodon.social avatar

Which types of sleep are available depends on various parameters. On functionality of the hardware, on security settings, on available swap space and more.

systemd exposes all four modes listed above via high D-Bus calls in systemd-logind, and via systemctl commands. Desktop UIs so far were expected to figure out which of the methods to use, and maybe implement a fallback scheme. This is less than ideal, in particular as inhibitor schemes would trigger multiple times…

pid_eins,
@pid_eins@mastodon.social avatar

…if fallbacks are necessary.

With v256 we did something about this: there's now a new D-Bus call and systemctl command, which we just called "sleep". It's supposed to abstract this mess away, and just get the job done, according to what is available, and based on system-level configuration in /etc/systemd/sleep.conf if needed.

This relieves tools and desktops to bother what precisely to when suspending, and just make the system "sleep" and let the lower layers of the stack then figure…

pid_eins,
@pid_eins@mastodon.social avatar

…out what to precisely do.

Hence, in your mind, please rewire "systemctl suspend" to now become "systemctl sleep".

And that's all for now. Stay tuned for installment Nr. 13.

pid_eins,
@pid_eins@mastodon.social avatar

@dinfuehr we increase the version number when we do a new release.

pid_eins, to random
@pid_eins@mastodon.social avatar

Look at this:

https://blogs.gnome.org/chergert/2024/05/07/system-extensions-from-flatpak/

Love it! 👌

rrwo, to random
@rrwo@floss.social avatar

Yet again trying to understand why a service never stays enabled for .

Every time the system reboots, the service has to be enabled manually and then started manually.

Systemd says the service is enabled after restarting. But it cannot be started until it's enabled manually.

Nothing is logged.

pid_eins,
@pid_eins@mastodon.social avatar

@rrwo a service that is "started" is a different concept from "enabled" in systemd.

"started" means: actually runing.

"enabled" means: hooked into the system that it is automatically started at the right time, for example at boot, or at hw plug-in or similar.

Your post sounds if the two concepts are mixed up?

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣1️⃣ Here's the 11th installment of posts highlighting key new features of the upcoming v256 release of systemd.

There are multiple network management services in popular use on Linux. In systemd we ship systemd-networkd, and of course think it's the best choice. Weirdly, some people disagree though, and that creates problems of ownership: you either have to use one or the other network management service (i.e. either systemd-networkd OR NetworkManager), or you have to carefully make…

pid_eins,
@pid_eins@mastodon.social avatar

…sure that there's exactly one service that manages each interface, so that they don't fight for ownership of the network device, trample on each other's feet and undo each other's settings.

To improve the situation in systemd v255 we introduced a udev property ID_NET_MANAGED_BY= which can be set on a network interface device. The value is expected to be a some string identifying the intended owning network management service, by convention in reverse domain name syntax.

pid_eins,
@pid_eins@mastodon.social avatar

This allows running multiple services side-by-side, and clearly tell each one which interfaces they shall manage. Of course they might still fight for the devices that are not tagged like this, but at least in the networkd case we should be safe, since by default it will not try to manage an devices it has no configuration for.

In systemd v256 we now made it possible to configure this udev property (or any other in fact) via the Property= field in .link files.

pid_eins,
@pid_eins@mastodon.social avatar

Recap: .link files configure various settings on network devices that are more property of the device itself – as opposed to .network files which configure settings that belong to the network you then attach to it. .link files are a udev concept (they are also interpreted if you use NM hence!), while .network files are a networkd concept. At any time there are zero or one .link files and zero or one .network file applied to a network interface.

pid_eins,
@pid_eins@mastodon.social avatar

Hence, with this new Property= field you can nicely define via .link files which network service shall manage the matching devices.

This is particularly useful as systemd out-of-the-box ships with a bunch of .link files that match devices created by systemd-nspawn, systemd-vmspawn and systemd-nsresourced. These .link files have been updated to clearly indicate that these interfaces are supposed to be managed by networkd, and nothing else.

pid_eins,
@pid_eins@mastodon.social avatar

Or in other words: it's now entirely safe out of the box to run NM and systemd-networkd side-by-side and be sure that networkd will manage the interfaces of systemd's other components, and NM can do its own thing, without any ownership issues.

At this point at least NetworkManager also respects the NET_MANAGED_BY= property. And we recommend that packages that allocate their own network interfaces (bridges, veth tunnels, dummys, tap, tun, …) start shipping .link files that match them, …

pid_eins,
@pid_eins@mastodon.social avatar

… and declare ownership the same way.

And that's all for now. I hope to post installment 12 soon, there's still so much great stuff to cover!

pid_eins,
@pid_eins@mastodon.social avatar

@mariusor yeah, the "systemctl enable --now" line is independent of the ownership declaration for the device.

pid_eins,
@pid_eins@mastodon.social avatar

@greatquux most of our releases if similar numbers of big features, it's just that previously I didn't post mastodon stories about them, and you had to read the NEWS file instead.

pid_eins,
@pid_eins@mastodon.social avatar

@jntesteves yes, typo.

pid_eins,
@pid_eins@mastodon.social avatar

@breiti well, the scheme leaves unanswered what happens to network devices that are not tagged for any network management service. My assumption is that based on user config one of them takes possession of all untagged devices. networkd by default doesn't, NM by default does. Thus in this combination at least we should be good, you can just leave networkd running together with NM and in the default config everything should be fine.

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣0️⃣ Here's the 10th installment of posts highlighting key new features of the upcoming v256 release of systemd.

You might be aware of systemd-sysext: a component of systemd that can overlay immutable disk images (DDIs) on top of /usr/, to extend it in a secure, and again, immutable fashion. It has a companion tool systemd-confext that does the same over /etc/.

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger might sound weird, but i am kinda afraid of a bigger audience tbh. The run0 story with all the problematic folks suddenly showing up from hn, reddit, heise forums, and so on and feeling the urge to be assholes on the internet which I then have to block makes me prefer posting things in a way that doesnt find the really big audience. Thankfully those folks aren't capable of reading more than one sentence anyway, hence by hiding the good stuff a bit further down keeps things civil?

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger its a difficult balance to find, but let's just say that of the 9 stories I posted until today only the one that reached the big audience was a mess to keep control of.

Yeah, it's in a way elitist as fuck, and I am usually against that, but the Internet is what the Internet is.

pid_eins,
@pid_eins@mastodon.social avatar

@javierm yeah, not convinced though. Doesn't protect the bits that need protection the most: the fs data structures. It's simply on the wrong layer. It's like you try to build a skyscraper on quicksand.

pid_eins,
@pid_eins@mastodon.social avatar

@gnomealex @javierm nope. DDIs come with dm-verity. Hence regardless what they are stored on integrity is ensured on block layer before the fs data structures are processed.

And if they themselves are stored on a backing fs then sure you need to ensure some basic validity of that, but its relatively limited, i.e. even vfat suffices (which is probably where data structures are simple enough for security, because kinda mandated by uefi model around esp)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • anitta
  • khanakhh
  • magazineikmin
  • vwfavf
  • osvaldo12
  • hgfsjryuu7
  • InstantRegret
  • Youngstown
  • slotface
  • ngwrru68w68
  • rosin
  • tacticalgear
  • kavyap
  • PowerRangers
  • Leos
  • DreamBathrooms
  • thenastyranch
  • tester
  • everett
  • mdbf
  • Durango
  • cubers
  • GTA5RPClips
  • modclub
  • normalnudes
  • ethstaker
  • cisconetworking
  • provamag3
  • All magazines
    •