Here's the 31st post highlighting key new features of the current v257 release of systemd. #systemd257
In an earlier installment of this series we already talked about "systemd-repart", systemd's "elastic", automatic repartitioning tool, that can also be used as installer and image building tool.
One thing systemd-repart can do for you is to initialize the partitions it creates with initial data. This can be a freshly generated fs that it copies files into, but there's also CopyBlocks=…
… which operates on the block layer, and can initialize the partition from either a regular file (which then would typically contain a pre-made fs image), or another block device (in order to maybe replicate an existing partition onto a new disk, in a byte exact fashion).
With v257 CopyBlocks= gained one new feature: in addition to regular files and block devices you can now specify character devices as source to copy from too.
You wonder what that might be good for?
Well, one device in particular: /dev/urandom. Or in other words: you can now do CopyBlocks=/dev/urandom to initialize a partition with entirely random data, which is sometimes useful to systematically overwrite any previous contents it might have had.
Note that whenever systemd-repart initializes a partition it will anyway use the DISCARD hardware operation first to empty it, and it also ensures that any remaining super blocks from an older fs are erased no matter what.
However, both of these operations won't comprehensively overwrite the partitions, simply because that'd be just too slow potentially given today's disk sizes. But now you have a way to explicitly request this anyway.
You might wonder why supporting character devices as copy source even needs explicit support, given that supposedly on UNIX "everything is a file". Well, that's because that mantra is of course nonsense. There are major differences between block devices, regular files and…
…character devices. For example the size of a regular file you query with fstat(). The size of of a block device you query with the BLKGETSIZE64 ioctl() and a character device generally has infinite size. What's more important though is that block devices operate in multiples of some block size, and you better respect that when doing IO on them. Regular files and character devices however operate byte-exact. And there's more.
Anyway, that's it for today.
@pid_eins "Everything is sort of a file" doesn't have as nice of a ring to it, I guess 
@jawnsy I think "everything has an fd" would be a much better mantra, and one i could get behind, though unfortunately not really true, i.e. their are other handles around, such as inotify wds, keyring keys, sysv ipc keys and so on....
@pid_eins Maybe an operating system does too many things for generalizations like, "everything is a file," to be universally true?
If you say, "everything is a thing," then I guess it would be accurate and useless. And if you say, "everything is a file," or, "'i' before 'e', except after 'c'," then there are also various exceptions, lol
In any event, thanks for everything you do with systemd and also for these threads!
@pid_eins afaik securely overwriting an entire SSD manually, to prevent recovery of old disk contents, is not really possible though because SSDs have more storage space than they advertise and transparently remap logical blocks to physical blocks. you'd have to use the SSD's special "securely wipe the entire disk" command for that
@jann yeah i guess this feature is not so much about total destruction of the data, it's really just about making the stuff invisible.
I guess we could teach repart also to fire the right nvme commands to do a secure erase of the disk on request. Afaiu this couldnt be done for parts of the disk though, would always cover the full thing, hence probably would have to be exposed quite differently.
@pid_eins I think all these new features are amazing, but I don't think many people are actually going to use them anytime soon.
Most distros seem to only use a tiny subset of modern systemd features, and IMHO more effort needs to be put on helping with downstream integration and working *with* existing projects.
@hughsie oh, my day only has 24h. And so has everyone else's on the systemd maintainer team. We do what we can working with people, but of course there are limits to everything we can do.
@pid_eins Ohh I'm not asking anyone to work harder, I'm merely suggesting that the upstream team take their foot off the new-features accelerator, and make sure that the great stuff is actually being picked up by distros and actually in the hands of end-users.
The hard (and slow) part of distro engineering is the change proposals, the test days, the marketing, the new QA tests -- not new upstream features.
@hughsie @pid_eins it is nice though to have solutions already available on the shelf when having to fix technical debt in distributions. Also systemd-repart is a tool that developers can just use for other purposes. For instance embedded development. Distributions do not have to use it right now. In addition, Snapd had to have a similar tool to make Ubuntu Core. If systemd-repart was available at that time, it would have been used instead.
@hughsie @Valentin Oh, we have plenty of good cooperation going on with some projects, in particular GNOME OS people, or at least two of the hyperscalers.
I think it's not surprising though that this works better with some projects than with others. In particular Snap being this half-commercial thing from a vendor who isn't necessarily known as the best player in Open Source is not the really the ideal candidate for more cooperation I guess. That said, I had fruitful discussions…
@hughsie …with some people from the Snap team (mostly ex- I think though). But talking and doing then again are still two different things.