No, Firefox would die too. Or at least it would become completely irrelevant.

The open source community doesn’t have enough manpower to maintain a browser engine.

It’s 75% of their income. Definitely obscene CEO salary but it’s still true that Mozilla would die without this deal.

Haha this is also the classic Linux experience. Any complaints about stuff not working properly get met with “It works for me” and “You’re doing it wrong”. Oh and don’t forget “did you submit a bug report?” and “if you don’t like it, fork it!”.

Ha yeah ASCII Nethack.

@

Good.

Don’t be an idiot.

That’s definitely better, but still not as good as Windows. If you click on an area that isn’t a drag source it should be raised on button down. I presume it doesn’t do that?

So, Windows has fully optimal behaviour here:

If you click on an area of the window that cannot be dragged from, it raises it on mouse-down.

If you click on an area of the window that can be dragged on, it doesn’t raise if you start a drag, otherwise it raises it on mouse-up.

That’s the desired behaviour. I agree people didn’t really explain that clearly.

I haven’t looked into it for over 20 years but as I recall it is impossible to do this with X11. I have no idea if Wayland added some kind of support for this, but I would be quite surprised given how long it took them to do screenshots.

Part of the difficulty is that you need to somehow query an app on mouse-down if it might start a drag. I have no idea how Windows does that… but… they solved it decades ago.

I wonder if they’ll ever fix this 24 year old bug…

https://bugs.kde.org/show_bug.cgi?id=36065

(Note they closed it but it doesn’t sound like they actually did fix it.)

Honestly I don’t need to know anything about it at all except that it’s a payment system designed by GNU to know that it stands zero chance of success.

GNU are uber-geeks that do not comprehend usability at all. They think everyone is happy to go to key exchange parties and run their own servers and so on. There’s absolutely no chance this is understandable by normal people.

Impressive. I would imagine it is very difficult to get native performance without ISA extensions like Apple had to do for TSO and other awkward x86isms.

I would guess someone will make a RISC-V extension for that stuff eventually, though I haven’t seen anyone propose one yet.

The linked patch actually explains it really well.

If you want two processes to communicate (IPC) normally, you would set up some shared memory, so that in each process’s virtual memory some pages are shared between them both, so when process A writes to that memory it is visible to process B and vice versa. There are other ways to do IPC but this is the fastest since it doesn’t involve any syscalls (context switch to the kernel which is slow).

However it still requires each process to copy its private data into and out of the shared memory. Also it still requires a context switch from process A to process B.

A common use of IPC is for RPC (Remote Procedure Calls). Basically you want to run a function in the other process. This solution does that but differently and faster.

1. First, both processes share the same virtual memory. This is normally a recipe for disaster since it completely destroys the normal process memory sandboxing (a memory error in one process can now crash the other one!). However they use a new Intel MPK hardware feature that allows splitting the pages into one of 16 groups (“keys”), and you can control read/write access to each group independently.

2. Next when process A wants to call a function in process B, the RPAL code does a lightweight context switch in user space. I guess this just means changing the MPK key, and normal saving of registers for the function call. I’m not sure what else you’d need to change. It’s a little unclear about how you pass heap data from process A to process B. I guess both processes just have read access to the entire address space? That doesn’t really change the security model on Unix since any process can already debug any other process with no extra permissions.

It sounds very similar to running two processes as if they were threads in the same process. Why not just use threads? Probably a better option if you can, but I guess if you are e.g. running processes written in different languages that might be tricky?

Why? They did it right…

But Wine could handle the case insensitivity though? NTFS is case sensitive.

I was looking into this recently and I didn’t know this but NTFS is actually designed by competent people and is fully case sensitive.

For backwards of course Microsoft had to make the file APIs case insensitive, but the actual filesystem is case sensitive.

Also, presumably because this is a real turn-off for developers there is actually an option in Windows to sort of make specific directories case sensitive. Wild right?

https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity

Damn straight. I thought bcachefs was a modern filesystem? Why is it case insensitive? Huge red flag.

I thought OEMs only paid like $10 for Windows?

I don’t think it’s quite a titanic enough endeavour to put slow in quotes. It’s been in development for 16 years and only got a stable support for screenshots a few months ago. Does drag and drop work yet?

IMO at this point it is reasonable to say that the idea of having a shared protocol and then making every desktop environment implement the entire display server was not a good one. The Linux community does not have enough manpower to make that work well.

SiFive P670

From what I can tell this might be almost as fast as a RPi 5 (single core). Which is almost as fast as my 12 year old i5-2500K. I guess we’ll find out when it is available.

I definitely think we’ll get an M1/Zen class RISC-V CPU eventually but I doubt this is it.

They’re a kind of backup…