I believe that either gender has a genetic disposition towards the feminine form.

I am not sure you can conclude that. Environmental factors likely play a large role here as well as genetic factors. I feel we tend to idolize and sexualize the female form far more then the male form these days. But if you look back and different cultures that did the same with the male form I suspect you would see an opposite trend to both genders preferring the male form more often.

There is probably a forced arbitration clause and class action waver in the TOS…

I believe that VKD3D can give you directx support. Proton should be able to run most games these days, which is essentially a bundle of wine + vkd3d and other things. This is what valve created to run games on steam on linux/steamdeck. https://www.protondb.com/ shows what is able to run on it and it is most things that do not have some form of incompatible anticheat.

You might have more luck not using wine directly (if that is what you are doing) and using things like steam (you can add external games to it to run them in a proton context) or lutris or heroic games launcher.

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.

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.

I would say it is more so they can advertise a lower price. But then expect you to get the more expensive ones as the bare minimum is just not enough.

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.

They can write good short bits of code. But they also often produce bad and even incorrect code. I find it more effort to read and debug its code then just writing it myself to begin with the vast majority of the time and find overall it just wastes more of my time overall.

Maybe in a couple of years they might be good enough. But it looks like their growth is starting to flatten off so it is up for debate as to if they will get there in that time.

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.