Linux 5.6 Is Looking Like It Will Be Spectacular With A Long List Of Features

[Neraxa]

That's why partitions are a thing, you know. If someone only wants to encrypt /home it is totally possible even on the block layer.

Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.

[amdtesterman]

No AMD Zen2 CPPC support yet?

there won't be any cppc support because Linux developpers want schedutil to be the only governor in Linux. They want to add the features of cppc to this governos. intel pstate was different because there was no plans to do this before. Correct me if it is not.
Other thing, it is not only for zen 2, it is too for zen cpu's , Michael had an error there and there is no correction yet in that thread I think.

[CochainComplex]

Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.

how about https://btrfs.wiki.kernel.org/index....ide#Subvolumes

[skeevy420]

Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.

That's literally why I stated using ZFS. I know I'm not the only one who partiton-fucked themselves once or twice over the years. I was reading about it and went, hold up, so you're telling me that something with the benefits of LVM without the downside of known partition sizes actually exists? Sign me up.

But if I could only shrink and move my XFS /home over ....is a phrase I will never say again

[anarki2]

Filesystem related things on Linux have long been a mess, full of half assed solutions and disclaimers like "we know its broken, and we don't care", or, "you can't do it the way you want, you can only do it this way, even though it does not work well for you". For many users, having encryption done above the filesystem is far preferable, since encrypting everything at the block layer is overkill. Most people don't need /usr/bin encrypted. Talking about needless performance degradation. So the idea that this is the only well supported way to have encryption is retarded. A lot of people just want per directory encryption, and they want it to be secure, reliable and robust. Reading the documentation for the kernels ecryptfs solution gives you the impression that no one cares about it, and the kernel people don't like it that you are using it. and the idea that people should encrypt /usr/bin and everything is absurd. Encrypting at block layer is what many people do not want. But for no good reason, kernel people think you should have to encrypt everything at the block layer. There is no technical reason, encryption above filesystem can be perfectly robust, no excuses.

The problem with cherry-picking directories for encryption is that there's never a guarantee that your sensitive information will happen to be in those encrypted dirs. Especially when your developers DEMAND sudo rights, which they usually do. In which case the value of encryption on your cherry picked directories is exactly zero. When it comes to encryption, FDE is the only sane way to do it, otherwise it's a 50-50 in which case, why even bother.

Have you actually measured the performance loss with LUKS? It's the same kind of sentiment as with SSL exceptions, because encrypting everything is sooo expensive. Like <1% these days. So why the hell would you risk it.

ZFS is unfit for single disk scenarios (read: 95% of desktops), Btrfs is EOL'd on RHEL, eCryptfs is EOL'd, fscrypt is half-@ssed at best (already ranted about it to great extent), so you really have no other option but LUKS. With Clevis TPM2 automatic unlock it's pretty decent, that's the setup we've been deploying for the past 2 months or so.

[-MacNuke-]

Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.

And there is LVM which fixes most of these problems. Shrinking may be an issue depending on your filesystem but extending is pretty easy. Sure, one can always construct a scenario where there is a random problem but that works everywhere.
Most people I know just encrypt everything. It's not like that you execute multiple gigabytes of binaries per second from /usr/bin on a daily basis.

edit: And btw. only encrypting i.e. /home gives one a nice opportunity to single-user boot your PC and place a keylogger/trojan into /usr/bin. Since it is not encrypted it easily accessible.

[brent]

there won't be any cppc support because Linux developpers want schedutil to be the only governor in Linux. They want to add the features of cppc to this governos. intel pstate was different because there was no plans to do this before. Correct me if it is not.

That's pretty sad if it is true. It's not the first time that kernel development politics hinder progress. What's wrong with getting an AMD-specific CPPC2 implementation in now and later converging to a schedutil-based implementation that makes both intel_pstate and the AMD CPPC2 implementation obsolete?

Perfect is the enemy of good.

[skeevy420]

Most people I know just encrypt everything. It's not like that you execute multiple gigabytes of binaries per second from /usr/bin on a daily basis.

Is that a challenge?

[cynical]

Full disk encryption overhead is not high. I think it’s a waste of time to complain about it. Either you don’t want any overhead, or you care enough about security to be fine trading some performance for it.

[Flaburgan]

5.6 will also come with A64 motherboard support so the pinephone will be able to run on a vanilla kernel!