georgyo

This isn't Linode getting attacked, it is telling customers that this zero click RCE CVE is pretty serious. You should patch ASAP.

Did you know that GO defaults to listening on TCP connections with MPTCP, so anyone running GO programs listening on the internet (Caddy, traffic, etc) and are on an unpatched kernel now have a way to from attackers to get root on that box?

Even if you're not using MPTCP, this functions as a DOS attack.

It's a very bad CVE, so yes. Follow the advisor and patch.

This is all the bad parts of ipv6 with none of the good parts...

You still need to have routers, clients, and absolutely everything to understand the new scheme to use those new addresses.

Flakes are neither stable or unstable...

They are defacto stable in that everyone is using them and the interface is not really going to change at this point.

But they are still marked as an experimental feature.

To get them out of experimental, the requirements are

normalizing the CLI. Currently some options are global and some are local to a command. The plan as I understand it is to make them all local. This would make it clear which options any particular command actually take instead of guess work. They are not going to break usage, but make the usage more clear.

And fetchTree needs to be stabilized. A big criticism of flakes is that they had a nonstandard method of fetching data and repos. fetchTree is a new nix built-in that behaves the same way. This makes flakes a lot less special.

So, nix flakes are a stable experimental feature, slowly getting to the state that it won't be experimental any more.

There is drama, yes. But it is getting a lot better recently.

It's a thriving open source ecosystem. There are forks, there are differing opinions, and in-depth discussions.

But, universally, everyone agrees that nixpkgs, independent from any implementation, is the real value of nix.

That said, things change. OpenSSL 4, glibc 2.44, gcc 16, etc which then requires a bit of tweaking every now and then.

The article also talks about NetNut, which was embed in many apps released into the app stores.

The article at the end talks about how is very easy for arbitrary apps from app stores can install a residential proxy on your phone.

10 years ago, apps had to explicitly state if they needed network access. And then the powers that be decided that really all apps need network access no matter what. And both ios and android make it hard to deny apps network access.

But really, this finally explains the hordes of really basic boring games that just advertise other boring games. Idle games and the like that really just want you to keep your phone unlocked and open. Millions of downloads on the app stores for entirely offline content (and ads) and no way to block the network access.

These are not the worst graphs in the world... Sure the bottom left axis is not labeled, but it still conveys the point correctly. The growth between 2023->2024->2025->2026 is growing quickly. And that in the end/beginning of 2026 they say more growth than the three years before, combined!

You don't need to know the bottom left axis number. We do have to assume the graph is linear, and not some kind of negative exponent log graph. But given the rest of the content, I think that is safe to assume.

Any company that experiences significantly more growth than they were planning for will have capacity issues.

The priorities are most inline with that. The are way beyond the point that they can just add more hardware. They need to make the backend more efficient, and all the stated goals are about helping there.

The thread here doesn't explain why GPL might be better. So I'll try.

You're correct, with MIT there are a lot less restrictions. I can make GPL or pretty much any other license. Including one that I sell and never have to release the source of.

The latter option means if you make a product off of it, you have no obligation to share or even fund upstream development. This kind of situation has strangled other products.

Consider if Linux was released under MIT. Then companies like Oracle and RedHat (now owned by IBM) who have strong incentives to keep improvements to themselves and fund a lot of development would never share those improvements. Linux is the most used operating system in the world because of _everyone_ contributing back. But a MBA would want to privitize the profits.

If you care about the long term openness of a product, then GPL is hard to beat.

Reading your comment made me segfault a little.

You don't understand the argument of why people might want to install their own OS on a device they own. And then say you won't buy another iPhone because you don't like their software... It sounds like you _do_ understand the argument.

I greatly dislike Apple software, but I think their hardware is quite nice. I would buy apple hardware if it wasn't handy-caped by their OS.

It used to be said that Apple was a hardware company that happens to make an OS. This argument never made sense to me, because while they make good hardware they very clearly don't want people to use it.

If I'm reading any of this correctly, this doesn't apply to hardware attestation.

It seems apple has a service, with an easily rotated key and an agreement with providers. If the key _Apple_ uses is compromised, they can rotate it.

BUT, apple knows _EXACTLY_ who I am. I attest to them using my hardware, they know _EXACTLY_ which hardware I'm using. They can ban me or my hardware. They then their centralized service gives me a blind token. But apple, may, still know exactly who owns which blind tokens.

However, I cannot generate blind tokens on my own. I _MUST_ talk to some centralized service that can I identify me. If that is not the case, then any single compromised device can generate infinite blind tokens rending all the tokens useless.

Maybe not so doable. The whole point of io_uring is to reduce syscalls. So you end up just three. io_uring_setup, io_uring_register, io_uring_enter

There is now a memory buffer that the user space and the kernel is reading, and with that buffer you can _always_ do any syscall that io_uring supports. And things like strace, eBPF, and seccomp cannot see the actual syscalls that are being called in that memory buffer.

And, having something like seccomp or eBPF inspect the stream might slow it down enough to eat the performance gain.

In 2007 several people and I started NYC Resistor, a hacker space in Brooklyn, completely unaware of this resistors in New Jersey.

It was over 10 years later that any of us heard of this much older resistor. It's kinda it funny how similar we are to them, nearly shared a name, and completely unaware of each other.

The world needs more places where people can explore their curiosity of how things work.

For now. 20XX is the year of the Linux desktop.

Nix in production is more common than you think, even at scale.

It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.

This again is a limitation of mapping labels to IMAP, which does not understand labels.

Both the Gmail web interface and the Gmail API allow the ability to set all the labels for a message. This can effectively enable your desired functionality. But IMAP can only deal with "folders", and cannot correctly decide when to remove a single label or remove all other labels when it sees a move action.

IMAP also only deals in messages and not threads. Gmail labels also technically only apply to messages, but the web interface shows the union of all labels of a thread. This is another decision I agree with. It means that when someone explicitly adds me to a thread, the whole thread gets highlighted in my feed.

I personally really enjoy the Gmail/fastmail/proton behavior so please don't make another political campaign to make things worse again. We have enough of those.