macOS is quite popular among tech literate people too, it's almost the default OS for most techies.
That's not my experience at all. Some tech companies are macOS shops and their employees will use macOS, but Windows still dominates the market.
Readit Newsjeroenhd commented on From M1 MacBook to Arch Linux: A month-long experiment that became permanenent ssp.sh/blog/macbook-to-ar... · Posted by u/articsputnik
I just had PTSD from reading your comment. Laptop + Nvidia drivers + Linux just do NOT work together.
Nvidia drivers almost bricked my laptop once, and I'm glad a random guy in a Discord server could help me out because I couldn't even get to the boot screen.
The biggest issue with Nvidia drivers, the mux chip issue, doesn't seem to be very prominent anymore these days. With modern laptops, you'll probably boot to desktop, though your experience will be terrible and pretty much unaccelerated.
Nvidia remains a problem on Linux, though they're making steps in the right direction. By putting all of their code in the secret and signed firmware, they can actually open source their drivers now, which is a lot better than how things used to be.
Still, I wouldn't buy Nvidia anything with a computer I want to run Linux on, it's not worth the hassle. Sucks that all developments related to AI are using Nvidia APIs though.
I don't know if anyone else agrees, but for some reason no one can replicate the smoothness of the Apple trackpad. And now with that PLUS the heatless apple silicon - I don't think I could go to another OS and the x86 hardware world. I would just feel like I'm in clunky-land. Now don't get me wrong, I like a lot about Linux desktops, but Mac gets a lot of things right. I don't want to take anything away from people migrating from Mac, but the PC didn't kill Desktop Linux, Mac did.
The only meaningful difference between my ThinkPad's trackpad and the one in my work Mac is that the Mac has a bigger one. I don't really get why some people seem to be under the impression that Windows laptops come with trackpads from the twenty years ago.
The CPU architecture is great and I hope Qualcomm will soon be able to replicate it in normal laptops. I don't think desktop users care about that as much, though, and macOS has just as many infuriating particularities as any desktop Linux OS. It just comes with better drivers.
jeroenhd commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon
Sounds mostly like a documentation issue, or the lack of thereof.
Because of how many parts of Zig change every other month, writing documentation doesn't seem to be a priority with Zig. The same way the Zig tutorial is just "here's a bunch of examples of Zig code" (that doesn't always compile on the latest version of the compiler), you're expected to read the source code for a lot of Zig standard library definitions.
For a lot of simple calls, that works out pretty well, once you know all the tricks to Zig's syntax. A lot of requirements and implications are generally written out in very simple and short functions that are often logically named. Things like Allocators are pretty easy conceptually even if you probably don't want to write one yourself.
It all breaks down when you start dealing with complex concepts. Zig's new I/O system looks a lot like Java's streams and wrappers and readers and writers, all wrapping around each other to make sending encrypted text over a secure channel as simple as output.write("hello").
I think the new I/O system combined with the lack of documentation about how to use it was a mistake. I'm not even sure if expressing a typing system as complicated as this in the Zig standard library is a good idea. The entire language runs on clear, concise, short and readable methods, and the new system doesn't seem idiomatic in that way.
jeroenhd commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon
Yuck. I thought some of the signatures you end up with when building “Modern C++” in the Andrei Alexandrescu style were hairy, but this looks sick. Not in a good way.
Probably does something cool for all that crazy though?
Every requirement on the types is commented on why it's necessary.
This is a generic method in the middle of some database DSL code that does a bunch of SQL operations on a type safe manner. Code like this takes "SELECT ?+* FROM ?+* WHERE ? ORDER BY ?+* LIMIT ? OFFSET ?", specifically the limit and offset part, and returns a type that will always map to the database column. If the query is selecting a count of how many Foo each Baz references, this will map to a paginated Foo to Baz count type.
The alternative is to manually write this stuff out in SQL, then manually cast the right types into the basic primitives, which is what a language like Zig probably does.
You'll find similar (though sometimes less type-safe) complex code in just about any ORM/DSL, whether it's written in Java or PHP.
I don't think you can accomplish this in C without some kind of recursive macro parser generating either structs or maybe function pointers on the fly. It'd be hell to make that stuff not leak or double free memory, though.
jeroenhd commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon
jeroenhd commented on I'm too dumb for Zig's new IO interface openmymind.net/Im-Too-Dum... · Posted by u/begoon
> I have never understood libraries or imterfaces that want me to allocate buffers for their type.
That doesn't seem that odd to me. It's a trade off: more flexibility, but more manual work. Maybe I have a buffer that I've allocated that I'm not using anymore (say I have a buffer pool) and want to use it again. If the type allocates its own behind the scenes, I can't do that. Or maybe I'm working in an environment where I need to statically allocate all of my resources up-front, and can't allocate later.
The big downside is that if 90% of people are just going to allocate a buffer and pass it in, it sucks that 90% of people need to do more work and understand more minutiae when only 10% of the people actually need to. The holy grail is to give lots of flexibility, but make the simple/common case easy.
A simple improvement to this interface might be to allow the caller to pass a zero-length buffer (or Zig's version of null), and then the type will allocate its own buffer. Of course, there's still a documentation burden so people know they can do that. Another option could be to have second constructor function that takes no buffer arguments at all, which allocates the buffers and passes them to the fully-flexible constructor function.
> If the type allocates its own behind the scenes, I can't do that.
Isn't that the reason why Zig passes around allocators everywhere? If you're using a buffer pool, you should probably be handing out some kind of buffer pool allocator.
Requiring all allocation to have happened before execution is still a good reason to pass buffers around, but I feel like the other situations you describe can be solved by just passing the right allocators.
jeroenhd commented on What about using rel="share-url" to expose sharing intents? shkspr.mobi/blog/2025/08/... · Posted by u/edent
OK well I think there's one superior aspect to the main post which is that it is short and not difficult to understand all of what will happen. This web-share-target requires more thinking about.
Also some stuff I dislike:
>The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
Yeah, specs that leave it open to site discretion whether or not to be abusive have a great deal of success.
>This specification has no known accessibility considerations.
No really!?
Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
I have found some bugs before in Google provided specs that were somewhat annoying for screenreader usage, and evidently the reasoning they must have had was that there were no known accessibility considerations because they sure didn't specify any.
> Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
Both Android and iOS have sharing mechanisms that work just fine with screen readers. They show the most common/likey/favourited options first, with an option to expand to other apps/share targets. My phone has dozens of options, but I rarely need to scroll beyond the first line to find the share target I'm looking for.
The share dialog is an OS/browser control, not something the web page needs to render, so it's as accessible as the browser decides it should be. Many Linux distros lack such a control, but on Android/iOS/Windows/presumably macOS, this is a solved problem.
jeroenhd commented on What about using rel="share-url" to expose sharing intents? shkspr.mobi/blog/2025/08/... · Posted by u/edent
This is what I currently use on my blog and it works particularly well:
navigator.share({
title: "hello",
text: "World",
url: window.location.href
});
That will work for sharing (except on Firefox), but only Chromium support actually receiving these share events, which is half the spec.
jeroenhd commented on What about using rel="share-url" to expose sharing intents? shkspr.mobi/blog/2025/08/... · Posted by u/edent
> There’s already a better spec from 2016
aka
This document is a draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
But unlike the proposal by the blog author, it's already been implemented by at least one browser vendor and received positive responses from another.
Sure, we could throw in another spec and maybe Mozilla will implement this one and maybe Safari won't be neutral to the new one, but why go through that effort when there's already a working solution to this problem?