Do you imagine someone got a stolen credit card, made a linkedin with that name, used the card to attend a live class under the fake ID, or are you just doing the classic hacker news aaaaactually?
Comments like this have ruined this site. We all know that’s never happened once in history.
If you care about the quality of the site, consider the guidelines about not responding to a bad comment with a worse one and not griping about how HN has gotten terrible or turned into reddit or what there you. Downvote, flag, and move on to better discussion, and you'll spend a lot more time engaging and contributing to good discussions.
Contributing to good discussions is the highest leverage way to promote the quality of the site. Spending time in poor discussions is what makes it feel like HN has gone to crap.
The odds that someone meaningfully reflects on their behavior when you tell them they're what's wrong with HN are pretty slim. You can substantially increase those odds by being more neutral about it.
It's entirely possible HN is dying, HN won't last forever and dang has said he is very concerned about the direction he sees the commentary going. But it's also entirely possible that the quality waxes and wanes primarily due to internal factors and that political tensions, AI bots and slop submissions, etc are external factors straining HN that will eventually be resolved.
Either way, the "real HN" I find is still here if you look for it, and I have always seen people on here who complain about the quality of the site but when you go to their comment history (I have not looked at your comment history to be clear) you see they're constantly getting into arguments and architecting a miserable experience for themselves. One's experience on HN is largely what they make it.
I write "reported by gcc16 -pedantic" when I'm fixing a bug, because it's useful to flag "this is how they issue became visible" in case readers want to use the same tool on their code.
The fact that it's just a tool is irrelevant. You don't need to mention search and replace because everyone already knows that exists... mind you I have had commit messages which included sed commandlines, for ease of future reuse.
Note that "FreeBSD Foundation" != "FreeBSD Project".
Obviously they're connected, but the FreeBSD Foundation supports the FreeBSD Project; they don't direct it. Governance of the FreeBSD Project vests in the FreeBSD core team, which is elected by FreeBSD developers; and as a FreeBSD developer I'm far more concerned with what OS members of the core team run than I am with what OS members of the Foundation run.
F/OSS is like GNU/Linux; the second part is the part which matters, but the first part keeps getting pushed by noisy people so we put up with it to keep them happy.
The exploit is injecting environment variables, but yes, close enough. You need someone to call execve as root in order to become root, but you don't need a setuid binary.
"When the timing aligns, the trigger's buggy memmove causes K+1 to self-overwrite, replacing sshd-session's real environment with the preseed payload. sshd-session's exec_copyout_strings copies LD_PRELOAD=/tmp/evil.so to the new process's stack, the runtime linker loads evil.so, and its constructor copies /bin/sh to /tmp/rootsh and sets it suid root. My human's unprivileged user runs /tmp/rootsh -p and gets a root shell."
... so at the very end of the exploit chain, is /tmp/rootsh required to be suid root before it is finally run to get the root shell ?
... or is the exploit already achieved and /tmp/rootsh is just an arbitrary indicator ?
Reducing clock speeds, even if they could do that -- and I'm not sure they can, given how Nitro is designed -- would be problematic since a lot of customer workloads assume homogeneous nodes.
But they did load-shed. Perhaps not soon enough, but the reason this is publicly known is because they reduced the amount of heat being produced.
Right, exactly, I highly doubt the facility went into any kind of actual uncontrolled thermal rise. This is news because they had to take such drastic actions. I'm sure its common that they force spot prices up (probably way up) to compensate for reduced capacity due to events, I'm sure they even sometimes fake no capacity for similar reasons. No capacity means "I don't want to turn on your node" not merely "I don't have any more physical servers I could turn up for you".
This is news because they powered off some non-preemptible customer loads, which actually makes me wonder if you saw that chain of events occur here.
spot prices rise -> new instance availability goes to 0 -> preemptible instances go dark -> normal instances go dark.
Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for the "I've pushed the patches" message to go out on slack, 10-30 seconds for patches to be uploaded, and up to a minute for mirrors to sync).
I'm somewhat skeptical here, because I notified the FreeBSD security team of a vulnerability a few years ago, and I never got a response, even after a follow-up email a few weeks later. To be fair, my report was about a non-core component, and the vulnerability wouldn't be very easy to exploit, but Debian, OpenBSD, SUSE, and Gentoo all patched it within a week [0].
That being said, I'm not suggesting that anyone should judge an entire OS based off of how they handle a single minor report, since everything else that I've seen suggests that FreeBSD takes security reports quite seriously. But then you could also use this same argument for the Linux kernel bug, since it's pretty rare for a patch to be mismanaged like this there too :)
While not receiving a response isn't ideal, I note that we actually have two secteams: secteam@ and ports-secteam@; something like luatex should go to the latter, but their level of activity has been kind of hit or miss in my experience. Curating security issues in ports is kind of hard due to the size of it and we probably more often than not end up getting hit with patching things a little after disclosure because of it.
Linux Kernel doesn’t differentiate between security bugs and other bugs, which is the main complaint here I think. They have the same process.
So the issue is bigger than the mishandling of a single issue, it’s a fundamental process issue around security for one of the most impactful projects in the entire space.
FreeBSD didn’t have user land ASLR until 2019 and, amongst other mitigations, still doesn’t have kASLR. It’s not a serious operating system for people who care about security. If you want FreeBSD and security take Shawn Webb’s HardenedBSD.
>Last I read, ASLR is a good thing to have, but overall is usually not difficult to defeat.
For local attackers there may be easier avenues to leak the ASLR slide, but for remote attackers it's almost universally agreed it significantly raises the bar.
>I don't think it's reasonable to say that an OS that lacks it isn't "serious" about security.
When they implemented it in 2019 it had been an 18-year-old mitigation. If you are serious about security, you implement everything that raises the bar. The term "defense-in-depth" exists for a reason, and ASLR is probably one of the easiest and most effective defense-in-depth measures you can implement that doesn't necessarily require changes from existing code other than compiling with -pie.
They exploited a linear stack buffer overflow. Not a write-what-where or arb write. A linear stack buffer overflow in 2026! There are at least two distinct failures there:
If you are switching to a BSD for security reasons, why FreeBSD? Isn't OpenBSD the super secure one? Sorry, it's been a while since I've looked at those projects
The person suggesting FreeBSD is a FreeBSD developer (Colin Percival - actually according to Wikipedia FreeBSD engineering lead), would be weird for him to suggest openbsd.
Also hilarious to see Drew Houston responding a bit later on the same thread:
> we're in a similar space -- http://www.getdropbox.com (and part of the yc summer 07 program) basically, sync and backup done right (but for windows and os x). i had the same frustrations as you with existing solutions.
> let me know if it's something you're interested in, or if you want to chat about it sometime.
It was, yes. I was trying to figure a way to bring it up but I didn't want to imply that the comment here was ignorant for not knowing the account. It's the opposite, HN accounts have so little fanfare and we all talk in the same threads, it's fun!
Okay. But the question isn't about him, the question is about the actual merits. And he's a good person to ask for a compelling argument about the merits.
If you ask Bill Gates why you should use MS-DOS in particular, not DR DOS, the answer is not "it would be weird for Bill Gates to suggest DR DOS".
There’s always a guy. It’s great that your favorite distro is definitely safer. An order of magnitude fewer exploits will mean only a few thousand or so, I suppose. Ozymandis used Gentoo.
Less laconically, distros generally refer to the userland parts of the operating systems rather than the actual kernel. FreeBSD does not use the Linux kernel so calling it a distro, which typically refer specifically to Linux distros, wouldn't be accurate.
Where are you messing with userland-only options? In my experience a Linux distro not only comes with a kernel, it's almost always a kernel specific to the distro. So I don't understand that reason.
As far as Linux versus not Linux, "distro" feels fine to me for Unix systems.
FreeBSD is not a distro. It's not even Linux; it's a completely different kernel and operating system that traces back to even before Linux. It's honestly closer to Darwin than it is to Linux; macOS is technically a BSD. (Not FreeBSD though.)
That's more of a historical artifact. The BSDs started as just "BSD": a set of patches for AT&T Unix that were _distributed_ by Berkeley. Eventually the patches became complete enough to be an entire operating system. _Then_ the various BSDs that we know today (FreeBSD, OpenBSD, NetBSD, DragonflyBSD) all forked and became completely independent operating systems. For decades, FreeBSD's kernel and userland has been developed independently from the OpenBSD kernel and userland which is developed independently from NetBSD's kernel and userland, etc. You could not take an OpenBSD program and run it on FreeBSD. Even recompilation from source isn't necessarily enough since the BSDs support different syscalls.
They are completely independent operating systems with a distant shared history.
Whereas on Linux, the distros are taking a common Linux kernel source, and combining it with their choice of common userlands like GNU. Debian has the same kernel and GNU userland that Arch and Fedora use. You could take a program compiled for Debian and run it on Arch, which is common these days due to Docker where you're pulling another distro's userland and running it on your distro's kernel. That is how Linux distros are "distros" whereas the BSDs are independent operating systems.
Do you honestly think stackghost doesn't know what the "D" stood for? They were making a point, not seeking information. My answer directly responded to the point they were making.
While you’re correct that FreeBSD is not a Linux distribution, the word “distro” is literally short for distribution. It doesn’t have a different meaning like smart and smartass, it’s more like repo and repository.
Debian is probably the best of all the Linuxes, but still suffers from split-brain: If patches are sent upstream first, Debian can't start digesting them until they're already public.
With FreeBSD there's never any question of "who should this get reported to".
> Debian can't start digesting them until they're already public
Not sure what you mean by this. Debian is able to handle coordinated disclosures (when they're actually coordinated), and get embargoed security updates out rapidly without breaking the embargo.
Is there some other aspect of this that you're referencing?
The key words there are "when they're actually coordinated". Debian doesn't own the Linux kernel, and the kernel developers don't bother with coordinated disclosure, so the happy path of coordinated disclosure only happens when reporters make the non-obvious choice of reporting vulnerabilities to people other than the maintainers.
Been constructing a lot of infrastructure servers recently, almost all of them FreeBSD VMs running under bhyve on FreeBSD physical hosts. It's a very simple, clean, pleasant environment to work in. And they all run tarsnap. ;-)
I've kept hearing about BSD recently, how hard is it to actually switch to? I'm guessing Linux executables don't work on it since it's not Linux, do all your packages have to be made specifically for BSD?
My experiences from dabbling with it a few months ago:
In general everything needs to be compiled for FreeBSD, but the ports collection is quite extensive. For example you will find Firefox, wayland, GNOME, KDE, xfce, … even dotnet was on there.
Problems arise with properietary stuff like Spotify, Widevine DRM etc. However, FreeBSD has a Linux emulation layer (providing syscalls), dubbed ‘Linuxulator’. I managed to run the Spotify Linux desktop client but the Spotify website wouldn’t let me log in, didn’t research further. AFAIK the emulator is limited though, not implementing all syscalls.
There is also podman for FreeBSD and in addition to running FreeBSD containers (using Jails under the hood I guess?) it can run Linux containers as well (using the Linuxulator in addition then?).
It also comes with a hypervisor called bhyve if you want to run VMs
There is a handbook on their website describing how to set up a system (including desktop environment) if you want to give it a go.
curl | sh is more prevalent in Linux where you can expect a stable ABI from the kernel and sometimes GNU libc. No such things in BSD land. Packages are built against a release always. They don't maintain binary compatibility.
reply