globalc

That, and if not possible one can try to get the used kABI symbols graylisted at Red Hat, to get informed when they change.

Let's take a task like "uncompressing a file".

It's clear that a Raspi is uncompressing slower than a new and shiny Thinkpad.. but the Thinkpad also uses much more power. Who is more energy efficient?

The article compares the energy efficiency of ARM/x86/RISC-V/AppleSilicon. The created framework can be used to easily compare energy efficiency of other tasks, i.e. kernel compilation.

AppleSilicon with #asahi #fedora remix shines for the uncompress task I looked at.

You should pay attention to make the ethernet the preferred interface.

If aggregation of bandwidth over the various underlying media is important for you: depending on the exact mode, aggregation might not work. Even if working, via bonding you might only get aggregation if the traffic goes over multiple TCP channels, while MPTCP also aggregates for a single TCP channel.

Nice, was not sure how stable such a setup would be. The applications will not need further modification and just need to be sent over the bond.

For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.

Ah, valid point, mea culpa. I have not used nbd, but I'm aware of it. Was very impressed to see even a NetBSD implementation. There is just so much around in that area.

In my defense, the storage related PM and colleagues who reviewed the article did not bring up nbd either.

+1

I use the older one which uses the kernel from the stock firmware. To my understanding done by the guys who worked also on the original firmware. I have seen just a single issue, it's minor: fast forward/rewind does not work properly. It does forward/rewind, but slower than expected.

The new native port lists quite some downsides/TODO's, so I did not yet switch over.

Of course, besides simply supporting recovery from bit rot, one would also want to have confidence in the implementation. I think the vendors which provide production support for btrfs do so just for a few features.

I know someone who did setup ceph just for it's healing capabilities.. but of course one has to familiarize with all of it's administration aspects for that.

Setups with RAID1 could help fixing bit rot, but I think these setups are not full stack tested, so one would have to play and test by oneself (and after soft ware updates verify the whole stack again..).

Maybe easiest remedy is to keep all files in a second directory, and hope that when bit rot invalidates one version of the file the second one is ok. rsync could in cycles sync the 2 directory trees.

- XFS: can use checksummed metadata, changed data (bit rot) will not be noticed, unless extra layers like dm-integrity are used

- ext4: same as XFS

- btrfs: can with checksums detect bit rot, not heal it by itself it seems

- ceph: can detect bit rot, not repair. Ceph is for networked systems, no local file system like xfs/ext4/btrfs.