That is interesting I have tried to use planka kanban boards, but was missing the all decisions go through a single channel instead of individual chat windows.
I also have a pretty much abandoned tool to take individual items and run them in non interactive sessions in individual containers which I may get back to because the brain fry is indeed real.
I am sorry, a little? I am deeply disappointed that libc decided to do the same just with another sequence.
And why because some dude was complaining sshd or whatever was crashing because it didn't handle nulls? Just handle the null my guy you already know why your bullshit is crashing.
Rust tells you off if you don’t handle Results. Sure, you can still just unwrap() it and have it panic, but at least that’s a specific decision instead of forgetting to check for NULL like in this case.
As the TCP bug that surfaced a couple of weeks ago, that is not true, you depend on the kernel, your application runtime, and many layers of dependencies.
Many bugs live in all those layers that may undermine your ability to lock down inputs and outputs.
Nah we just all have to switch to a handfull of heavily audited memory safe unikernels.
Your http proxy and your web server don't need a shell, drivers for wifi, mail daemons, systemd, python, PHP, perl, docker, multiple users, hell it might not even need a file system.
You can ship a stripped down docket image running on a stripped down Linux distro, but that still ships the entire kernel with a huge amount of functionality you don't need that may be exploited.
Because 50m lines of code with whatever defect density is a lot more defects than a dedicated app+kernel with just the code that you need. So much of the Linux kernel is unused by any given application: why have that code loaded and runnable?
Exactly. Anybody deploying Linux today in scenarios where you might replace it with a unikernel is already not affected by LPE. They have a kernel running in a VM with one user and one application, in essence using Linux as a sort of bloated unikernel.
The kernel probably is too complex to reason about. C is notoriously hard to write correctly and will compile with a very large amount of errors.
Probably not, the kernel is written in an unsafe language, it's rather long handles an incredibly large space of concerns, including the handling of permissions.
Not if they are only using it to route the DNS traffic (though in that case a cheaper VPS might be better), which will work if the ISP is only poisoning DNS replies and not (which is often the case) blocking traffic to the target servers entirely.
The problem with this is you are adding a moving part to your DNS lookups. It might be worth adding two on separate VPS hosts and have your resolver fall back to the second if the first goes down.
Another, usually more minor, problem is that some services (like CDNs) use the source of your DNS query to modify the response so you get sent to a topologically near-by end-point. This means you might notice such services being slower as you are sent to a PoP near your VPN host not one closer to your actual location.
Not for DNS lookups. Hetzner forwards complaints from copyright holders, they don't proactively snoop traffic to make sure you don't access 1337x at all. It's legal to access the site.
Oh well OP was doing shady stuff ... then yeah they should continue with using VPN provider. VPN providers are shady AF, I don't think there is VPN provider I would trust more than my local internet provider.
What about it? Unless they've hijacked your local cert store somehow (which corporate machines do), they can't see inside the TLS. They can detect that you're connecting to somewhere and probably infer that it's some VPN, but only the most repressive countries actually block VPNs altogether.
Qwen 3.8 is useful and honestly impressive but it's far from slightly worse.
For slightly worse you need something like Kimi K3.1 or glm 5.3
reply