So no vetting at all presumably since you didn't mention it? So how do you know that Dashlane is safer than a password scheme that might be guessed by someone after they've already compromised a couple of your passwords?

For someone to work it out, they would have to be targeting you specifically. I would imagine that is not as common as, eg, using a database of leaked passwords to automatically try as many username-password combinations as possible. I don't think it's a great pattern either, but it's probably better than what most people would do to get easy-to-remember passwords. If you string it with other patterns that are easy for you to memorize you could get a password that is decently safe in total.

Don’t complicate it. Use a password manager. I know none of my passwords and that’s how it should be.

A password manager isn't really any less complicated. You've just out-sourced the complexity to someone else. How have you actually vetted your password manager and what's your backup plan for when they fuck up?

Both su and sudo originally meant "superuser" because that was their only use. They have retroactively been changed to "switch user" because this functionality was added later.

It's not just Batman. This is a common trope in the superhero genre. Pop Culture Detective has a great video on the subject: https://youtu.be/LpitmEnaYeU

I think you misunderstood what I was saying. I'm not saying wayland magically makes everything secure. I'm saying that wayland allows secure solutions. Let's put it simply

• Wayland "ignores" all the issues if that's what you want to call it
• Xorg breaks attempts to solve these issues, which is much worse than "ignoring" them

You mentioned apps having full access to my home directory. Apps don't have access to my home directory if I run them in a sandbox. But using a sandbox to protect my SSH keys or firefox session cookies is pointless if the sandboxed app can just grab my login details as I type them and do the same or more harm as they would if they had the contents of my home directory. Using a sandbox is only beneficial on Wayland. You could potentially use nested Xorg sessions for everything but that's more overhead, will introduce all the same problems as Wayland (screen capture/global shortcuts/etc), while also having none of the Wayland benefits.

And given how garbage the modern state of sandboxing still is

I'm not talking about "the current state" or any particular tool. One protocol supports sandboxing cleanly and the other doesn't. You might have noticed that display server protocols are hard to replace so they should support what we want, not only what we have right now. If you don't see a difference between not having a good way to do something right now versus not allowing for the possibility to do something in a good way ever, let's just end the discussion here. If those are the same to you no argument or explanation matters.

If you actual want to solve this issue you have to provide secure means to do all those task.

Yes that exactly the point. Proposed protocols for these features allow a secure implementation to be configured. You would have a DE that asks you for every single permission an app requests. You don't automatically get a secure implementation, but it is possible. There might be issues with the wayland protocol development processes or lack of interest/manpower by DE/WM developers, or many other things that lead to subpar or missing solutions to current issues, but they are not inherent and unsolvable issues of the protocol.

In theory, yeah, a bit more control over what apps can and can’t access would be nice. In reality, it doesn’t really matter, since any malicious app can do more than enough damage even without having access to the Xserver.

Complete nonsense. Moving away from a protocol that doesn't allow every single application to log all inputs isn't "a bit more control over what apps can and can't access". We're switching from a protocol where isolation is impossible to one where it is.

The notion that if you can't stop every possible attack with a sandbox then you should not bother to stop any of them is also ridiculous. A lot of malware is unsophisticated and low effort. Not bothering to patch gaping security holes just because there might be malware out there that gets around a sandbox is like leaving all your valuable stuff on the sidewalk outside your house because a good thief would have been able to break in anyway. You're free to do so but you'll never convince me to do it.

The solution is to not run malicious code

Another mischaracterization of the situation. People don't go around deliberately running "malicious code". But almost everyone runs a huge amount of dubious code. Just playing games, a very common use case, means running millions of lines of proprietary code written by companies who couldn't care less for your security or privacy, or in some cases are actively trying to get your private data. Most games have some online component and many even expose you to unmoderated inputs from online strangers. Sandboxing just steam and your browser is a huge step in reducing the amount of exploitable vulnerabilities you are exposed to. But that's all pointless if every app can spy on your every input.

Xnest, Xephyr and X11 protocol proxy have also been around for a while, X11 doesn’t prevent you from doing isolation.

What's the point then of a server-client architecture if I end up starting a dedicated server for every application? It might be possible to have isolation this way but it is obviously patched on top of the flawed design that didn't account for isolation to begin with. Doing it this way will break all the same stuff that Wayland breaks anyway so it's not a better approach in any way.

Disabling screen tearing for two or more monitors with different refresh rates is as far as I know impossible within the X11 protocol. This is especially annoying for high-refresh rate VRR monitors which could be tearfree with negligible cost in responsiveness.

You also can't prevent processes from manipulating each others inputs/outputs. An X11 system can never have meaningful sandboxing because of this. Maybe you could run a new tweaked and sandboxed X server for every process but at that point you're working against the protocol's fundamental design.

This would be an incredible QoL improvement for gaming, at least until all compositors reach feature parity. Imagine using your preferred compositor for everyday tasks, quick-switching to another one that supports VRR and/or HDR while gaming, and then back again, all without logging out and logging in again.

It's not about "accomplishing" something that couldn't be done with a database. It's about making these items tradeable on a platform that doesn't belong to a single entity, which is often the original creator of the item you want to sell. As good as the Steam marketplace might be for some people, every single sale pays a tax to Valve, and the terms could change at any moment with no warning. The changes could be devastating for the value of your collectibles that you might have paid thousands of dollars for. This could not happen on any decentralized system. It could be something else that isn't NFTs but it would absolutely have to be decentralized. Anything centralized that "accomplishes the same thing" doesn't really accomplish the same thing.

It's worth noting that this sort of market control would never be considered ok on any other market. Can you imagine a car manufacturer requiring every sale to go through them? Would you accept paying them a cut when you resell your car? Would you accept having to go through them even to transfer ownership of the car to a family member? If a car manufacturer tried to enforce such terms on a sale they would be called out for it and it would most likely be ruled to be unlawful. But nobody questions the implications of the same exact situation in a digital marketplace.

I know that zsh has the option to use vim-like keybindings if you're familiar with those.

I don't think Linux literally waits for you to unmount the drive before it decides to write to it. It looks like that because the buffering is completely hidden from the user.

For example say you want to transfer a few GB from your SSD to a slow USB drive. Let's say:

• it takes about half a minute to read the data from the SSD
• it takes ten minutes to write it to the USB
• the data fits in the spare room you have in RAM at the moment

In this scenario, the kernel will take half a minute to read the data into the RAM and then report that the file transfer is complete. Whatever program is being used will also report to the user that the transfer is complete. The kernel should have already started writing to the drive as soon as the data started being read into the RAM, so it should take another nine and a half minutes to complete the transfer in the background.

So if you unmount at that point, you will have to wait nine and a half minutes. But if you leave it running and try to unmount ten minutes later it should be close to instant. That's because the kernel kept on writing in the background and was not waiting for you to unmount the drive in order to commit the writes.

I'm not sure but I think on Windows the file manager is aware of the buffering so this doesn't happen, at least not for so long. But I think you can still end up with corrupted files if you don't safely remove it.

Out of curiosity, what distro was this on?