Recent submissions

Comment · 3 days ago
Comment · 27 days ago
Google never wanted to share details about their datacenters because they thought (think?) their power efficiency was a competitive advantage. So it'd be lower than you expect.

Also, they didn't want you to be able to guesstimate how many machines / computing power they had, for similar reasons.

Comment · 1 month ago
It is, but you can start with a COPR repo instead.
Comment · 1 month ago
I think I've cleaned up my box of cables twice in the past and, inevitably, _the very next day_ I did so, I needed one of the cables I had gotten rid of. Never again.
Comment · 2 months ago
Comment · 2 months ago
Start with Doom Emacs. I haven't felt the need to customize almost anything since I switched (from VSCode) 4 years ago.

TBH, I had used Emacs before VSCode and had accumulated a bunch of cruft in my .emacs configuration, and I never felt it was "mine" anyway...

Comment · 2 months ago
Comment · 2 months ago
That's not surprising. The page says the kernel is multiboot compliant, which means it can be loaded by existing boot loaders. Whether the kernel later provides a floppy driver is a separate story.

This is also pretty common even if you don't use multiboot. The I/O services exposed by the BIOS or firmware during boot may not be usable once the kernel has started, and thus the kernel has to provide its own drivers.

Comment · 3 months ago
Comment · 3 months ago
Yeah, structs (records) is something I've been wanting to add and that became reasonably easy with the full rewrite of the compiler I did in 0.13. Probably in the next update!
Comment · 3 months ago
What do you mean? FUNCTIONs are supported, and their arguments and return values are strongly typed.
Comment · 4 months ago
Two years ago, I spent time studying the Windows NT kernel internals and ended up writing a comparison against Unix here: https://blogsystem5.substack.com/p/windows-nt-vs-unix-design . What I came out of that exercise with is that NT is actually well-made and was very ambitious and advanced at the time it was designed (although free systems have caught up by now).

But what I also came out thinking was: none of that shows. The kernel is great, sure, but all of the crap that has been built on top doesn't let it shine, and that's what people interact with. Take Windows 11 with is dog-slow file manager and the overall feeling that everything is bloated and designed to annoy you. I wish there was a simpler edition... but it ain't gonna happen.

Comment · 4 months ago
> Only the very first few models of Intel Macs had strictly 32-bit processors (the 2006 iMac and Mac minis with Core Solo/Core Duo processors), and none of them were realistically capable of playing Half-Life 2.

What? First, those chips were plenty powerful to run HL2 (the game predates them). And second, all x86_64 chips can run older x86 32-bit code unmodified.

The reason macOS stopped supporting 32-bit code has nothing to do with the processors but more about them wanting to remove support for 32-bit binaries from the kernel and from all user-space libraries. To run a 32-bit binary, you need itself and all libraries it depends on to be 32-bit too, including the syscall boundary, which is "fine" (both Windows and Linux do this just fine, so it's really on Apple to have removed this). And I suppose Apple removed those because it was building towards a 64-bit-only world to simplify the Apple Silicon transition.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton