Or wait for rust to support the extra languages. With LLVM adding new architectures or projects like gccrs. But all of these options are a way out and rust will remain device driver only for a long time I suspect - it is still experimental after all. I would hope that as rust in the kernel matures so do the available architectures that rust supports.
People said the same thing about tweet when twitter first came out.
They only need it to pass once, we need it to be rejected every single time.
Secureboot is meant to help protect you against the evil maid attack. IE someone with physical access to your computer can compromise your boot loader with a keylogger that can capture your encryption password so that when they return they can gain access to your computer as they now know your password. Though the vast majority of people just don’t need to worry about that level of attack so I have never really bothered with secureboot.
Switching a whole distro is an extreme way to try out a tiling window manager. It would be far better if desktop environments supported it so it is a simple toggle a user can turn on or off and not having to upend everything to get into.
but you think those same users will be totally interested in spending hours writing Perl or JSON configs and memorizing dozens of keyboard shortcuts for every function they used to use the mouse for??
Of course not. This is the argument for a tiling desktop environment. The only reason people need to do all that ATM is because of the current tiling window managers. Not because tiling window management is inherently complex to understand. You can have a tiling window manager with a GUI configuration and that better supports the mouse while still supporting keyboard shortcuts. Then users can incrementally learn the shortcuts - like they do with floating window managers - to gain productivity in their day to day tasks.
They might not be for everyone, but giving everyone the choice is also not a bad thing. Most people I have seen that try a tiling window manager do end up liking it and quite a few hate to go back to floating ones. But not all of them can be bothered with the amount you need to configure the current ones.
So what is wrong with trying to make a easier to configure, use and generally a batteries included tiling desktop environment? This is essentially what it looks like Cosmic are doing - they support both floating and proper tiling without needing complex configuration or needing to learn loads of shortcuts.
IMO the tiling support in KDE and with gnome extensions does not look great. It cannot replace someones workflow that has been on a true tiling window manager. It is a benefit to those that have been using floating window managers for their whole life but I cannot now go back to them. Cosmic is the first desktop environment that looks like it has true tiling support (that can rival a tiling window manger) and not just drag a window to a side/area of the screen. Though I have yet to really try it out.
I disagree. What is wrong with a fully featured batteries included desktop environment that has proper tiling support (not just partital drag the window to the edge of the screen support). Lower the barrior to entry so that more people can make use of this powerful way of working. The main reason that tiling is considered hardcore is becuase it has mostly only been available on minimal configure them yourself window managers. But tiling does not have to be for the fully DIY only crowed.
IMO the basic tiling support on gnome or KDE are not good enough. So I am forced to use something minimal but TBH I am sick of needing 100s of lines of config to get a basic environment setup. Cosmic seems like it will be a good answer to this post as its tiling support looks far more fully baked than other full desktop environments and hopefully we will see more people wanting to try out tiling once it reaches a more stable point.
Those always feel like a half baked hack when compared to a true tiling window manager. At least all the ones I have tried on my work mac I have not found any that are good enough and all have weird edge cases or break in weird ways.
Use whatever that distro recommends then - which as far as I can tell seems to be svlogd for runit based systems. Though you should consult their documentation and make your own decision on which logger to use.
There is also the BREACH which targets gzip/deflate compression on http as well. But also, don’t see how that affects disk encryption.
Looks to be an exploit only possible because compression changes the length of the response and the data can be injected into the request and is reflected in the response. So an attacker can guess the secret byte by byte by observing a shorter response form the server.
That seems like something not feasible to do to a storage device or anything that is encrypted at rest as it requires a server actively encrypting data the attacker has given it.
We should be careful of seeing a problem in one very specific place and then trying to apply the same logic to everything broadly.
How does that work? Encryption should not care at all about the data that is being encrypted. It is all just bytes at the end of the day, should not matter if they are compressed or not.
You dont need syslog. Journald is good enough for most systems.
It also does not support unix file permissions - so for most installs it does indeed not work.
Ext4 codebase is known to be very complex and some people say even scary. It just works because everybody’s using it and bugs have been fixed years ago.
I heard that ext4s best feature was its fsck utils being extremely robust and able to recover from a lot of problems. Which does not shine a great light on the filesystem itself :/ and probably a result of the complex codebase.
bcachefs is meant to be more reliable than btrfs - which has had issues with since it was released (especially in the early days). Though bcachefs has yet to be proven at scale that it can beat btrfs at that.
Bcachefs also supports more features I believe - like encryption. No need for an extra layer below the filesystem to get the benefits of encryption. Much like compression that also happens on both btrfs and bcachefs.
Btrfs also has issues with certain raid configurations, I don’t think it yet has support for raid 5/6 like setup and it has promised that for - um, well maybe a decade already? and I still have not heard any signs of it making any progress on that front. Though bcachefs also still has this on their wishlist - but I see more hope for them getting it before btrfs which seems to have given up on that feature.
Bcachefs also claims to have a cleaner codebase than btrfs.
Though bcachefs is still very new so we will see how true some of its claims will end up being. But if true it does seem like the more interesting filesystem overall.
Sure, my bad. But it does not change my point. They have released stuff as opensource even if not all of it. Which means they can if they want to.
The wrote and released VS Code - a completely opensource development environment. If they wanted to patch Grub I bet they could have found the permissions internally to do that. Microsoft is a lot more open to OSS contributions then they were in the past.
The goal ATM is simply to allow people to write new drivers in rust, not convert the whole kernel to rust. It will be a very long time, before more core parts would be allowed to be written in rust let alone rewriting any existing core kernel code. Which is all fine as new drivers are a large part where bugs are added - older parts have had a long time for bugs to be found and fixed and so it is far less important to need to rewrite them.