With that: is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email)

and I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with and friends. This happened with other elements too.

I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "" emphasizes it by doing something other than bold for example

]]>Sat, 13 Jun 2026 04:59:38 +0000https://news.ycombinator.com/item?id=48513413jkrejchahttps://news.ycombinator.com/item?id=48513413https://news.ycombinator.com/item?id=48513413USB A? That's very much not legacy

If anything, it's probably like an order of magnitude more common, even for new designs

]]>Fri, 12 Jun 2026 23:32:52 +0000https://news.ycombinator.com/item?id=48510619jkrejchahttps://news.ycombinator.com/item?id=48510619https://news.ycombinator.com/item?id=48510619Pis/other SBCs and ESPs/STMs/etc are effectively a different subclass of embedded

Firstly, Pis and SBCs like it tend to be fully functional OOBE on their own. This has useful properties but also means that hooking them up and testing their use is a little bit simpler even compared to a microcontroller dev board

Secondly, it's a full Linux ecosystem and all of that that it entails. This ecosystem has more in it than these ecosystems (especially in the FOSS world) and it's also useful for projects that exceed a few MB of RAM. Sure if I want to do a few things a microcontroller like this is a very very good and probably the better option (it isn't that difficult to write a lil C to control these things) but SBCs can do lot more than that while still keeping many of the advantages, which may be the difference in some cases

]]>Fri, 12 Jun 2026 23:25:00 +0000https://news.ycombinator.com/item?id=48510558jkrejchahttps://news.ycombinator.com/item?id=48510558https://news.ycombinator.com/item?id=48510558I've seen this sentiment a bit and while I don't dispute that you can get a better SBC for cheaper, there are still a lot of issues and it tends to be around software support primarily that allows it to occupy a very sweet spot. It's a significant factor in deciding to use them. There are a lot of embedded use cases that can be solved by hooking up to an ESP32 but there are a bunch that need a little bit more than that. If you want to run a web server for example, you do have options on the ESP32 but also writing C/C++ for a web backend is both a little fraught and kinda miserable compared to Python or Go or something. I mean it's certainly doable, but it certainly isn't the first language I'd reach for. If you want to work a little bit with streaming video, same deal

So this is the embedded Linux usecase. And... the embedded Linux ecosystem seems kinda... hacked together? You a lot of the times get Yocto Linux which is its own can of worms because you tend to invariably get meta-vendor packages that patch everything from U-Boot to the kernel to random userspace utilities. There are better cases and it depends on how much the vendor works upstream. Sometimes the vendor doesn't even bother with maintaining the meta layer and it ends up getting into a "maintained mostly by one guy in Nebraska" scenario

Some other vendors seem to take U-Boot and a copy of the Ubuntu LTS sources from 10 years ago and hacked it until it was possible to get a root shell without the thing going into a kernel panic then put the resulting image on a Google Drive or FTP server somewhere but didn't go much further than that

What ends up being is that there is like a U-Boot and Linux kernel variant for either each different SBC (or sometimes vendor thereof) duck taped together. Support, even for the peripherals included, can be spotty at best, and there are many times where you have to patch the kernel or userspace to get it to work right. I've seen boards which run the weirdest stuff, ones whose kernel patches run into the megabytes with poor (if any) documentation, boards which apparently don't want to run anything but Android, etc. There are certainly vendors that work well and upstream and make everything nice and easy but they tend to be rarer and/or more expensive

Compared that with the Pis and the difference is night and day enough that the raw specs matter less. Yes RasPi has their own kernel fork, but iirc they do work a bit upstream and the versions maintained are like 6.12 and not like 5 (which I've seen). They are also relatively easy to procure where more specialized vendors tend to be... less so. Flashing them is pretty simple and if you want to create your own image you can do that as well easily without Yocto or whatever. The HAT ecosystem is a nice way to add extensibility, the headers basically allow you to do a lot of ESPy type things as well (since Linux has native specific userspace support for GPIO, I2C, SPI, PWM, LED, hwmon, etc). And so on and so forth. And it all just kinda works

This in of itself, makes it a pretty decent option for industry, especially if it's like either n <= 1000 units or a relatively small part of the BOM itself. It often is very much the economically sensible option to stick a Pi in it rather than put many man hours into fixing problems that really shouldn't require me to open up menuconfig or apply a kernel patch again.

People like Geerling tend to come at it from the hobbyist or maker side of things but it does apply to the industrial side too. Yes in many cases knowing part XYZ will still be manufactured in 30 years is more important than the dev experience or some other factor is at play (power draw being another) but in a lot of cases its not (e.g. more portable code, stuff not requiring recertification) and the Pis also do have a relatively reasonable time guarantee too. It shouldn't be a bad experience to develop on these boards! But regardless, there are a lot of times that it is, and that's why I think the RasPi continues to do as well as it does.

This is also why I think, despite the price, it continues to do well in the hobbyist community. I can hook it up using the headers to anything SPI, I2C, etc, and start making it do things with very little software trouble and regardless if I want to do it in C or if I want to do it in Python

]]>Fri, 12 Jun 2026 22:28:35 +0000https://news.ycombinator.com/item?id=48510158jkrejchahttps://news.ycombinator.com/item?id=48510158https://news.ycombinator.com/item?id=48510158The main reason is that a lot of the reason comes around that it is incredibly difficult to do this in a general case just because of the grammar of SQL. Especially with the very different dialects, in the worst case you can get unintended remote code execution[1]

There's an incidental performance benefit on some database engines as well. When you write a SQL query, in general the database engine has to compile this to a form it can use

If you use raw string concatenation, "SELECT USERS FROM table WHERE id=1" might compile to something like (pseudocode below)

    def prepstatement1():
        ...

So if you use an explicit prepared statement[1], something like "SELECT USERS FROM table WHERE id=?" might compile to something like

    def prepstatement2(id: int):  # <--- notice the new parameter here
       ...

Some database engines also have the ability to cache a prepared statement and so these are a lil bit faster. Remember, your database has to still compile the string concatenated case, it's just a little bit hidden.

[1]: For example SQL Server has xp_cmdshell: https://learn.microsoft.com/en-us/sql/relational-databases/s...

[2]: https://en.wikipedia.org/wiki/Prepared_statement

]]>Wed, 10 Jun 2026 19:10:34 +0000https://news.ycombinator.com/item?id=48481172jkrejchahttps://news.ycombinator.com/item?id=48481172https://news.ycombinator.com/item?id=48481172Iirc Cygwin used to use it but iirc they moved away from it because they said that it was pretty slow

Though actually iirc werfault uses NtCreateUserProcess() to clone processes when writing out crash dumps to this day

]]>Sat, 06 Jun 2026 22:47:33 +0000https://news.ycombinator.com/item?id=48429805jkrejchahttps://news.ycombinator.com/item?id=48429805https://news.ycombinator.com/item?id=48429805> But how often would one actually need this?

Well, the idea is that it'd probably be close to the default API for spawning processes (and could even be the bedrock for posix_spawn and friends in libc (and potentially even "simple" fork cases[1])). fork/clone would be the special case

In most cases, most programs don't need special setup. Something like `ptrace_syscall` would also work for this and would be probably the way to do it with the backwards compat limitations of nowadays

ptrace-ability seems to be generally how permissions for this sort of thing are handled in general (see also procfs, process_vm_writev, ptrace, etc). The complication is a little bit around setuid programs but either you could special case execve to imply SIGCONT for setuid or have execve also imply a SIGCONT as well

[1]: Probably would be rare for a compiler to optimize it though

]]>Sat, 06 Jun 2026 22:40:18 +0000https://news.ycombinator.com/item?id=48429749jkrejchahttps://news.ycombinator.com/item?id=48429749https://news.ycombinator.com/item?id=48429749I kinda disagree, though I do see the usefulness here. While fork/exec can be useful in some cases, it'd be honestly pretty neat if the APIs took a pidfd argument (maybe with 0 meaning current process). Only program is setuid/setgid binaries I suppose but maybe this case is better handled by special casing `exec`.

For example

   pidfd_t ps = spawn(); // creates a process stopped (kernel does this anyway by default)
   setuid(ps, 33);
   capset(ps, ...);
   socket(ps, ...);
   mmap(ps, ...);
   process_vm_writev(ps, ...);
   exec(ps, ...);
   signal(ps, SIGCONT);
   // error handling elided

I guess this is a little bit me being a bit of critical of the usual syscall APIs for not thinking about "what if I want to do this to another process I have access to" but...

It also makes things like thread safety even reasonably doable with fork. I do agree though that stuff like CreateProcess which take in a gazillion parameters don't really make for the greatest of userspace APIs

]]>Sat, 06 Jun 2026 21:50:47 +0000https://news.ycombinator.com/item?id=48429349jkrejchahttps://news.ycombinator.com/item?id=48429349https://news.ycombinator.com/item?id=48429349Windows has had native support for always on top windows for over 25 years

]]>Wed, 03 Jun 2026 12:22:18 +0000https://news.ycombinator.com/item?id=48383031jkrejchahttps://news.ycombinator.com/item?id=48383031https://news.ycombinator.com/item?id=48383031I've mentioned this elsewhere in the thread, but I think it's a difference of view on what malloc represents. Operating systems do have "reserve this part of the address space" APIs and these reservations don't get charged against your commit because you're simply reserving the space, not committing to using it, and so the operating system doesn't need to back it with anything.

In this worldview, malloc is like me buying a plane ticket at the counter for a specific flight that's going to leave soon. I'd be really annoyed if I were bumped off a flight I just paid for (and would've rather been told "that flight is full, try again later" (malloc returns NULL)). This is, for example what Windows does. Under memory pressure, it'll say to applications, "hey no I'm not in a giving mood for memory right now" (and will sometimes bump the size of the pagefile if configured to do this, but only up to a point).

The thought behind this is that well... applications have to handle malloc returning NULL anyway. Whether that's calling abort and giving up is one matter, another might be to retry the allocation at a later time (maybe after Windows has bumped the pagefile size), another might be to handle an error using some preallocated buffer or whatever.

]]>Tue, 02 Jun 2026 00:47:06 +0000https://news.ycombinator.com/item?id=48364456jkrejchahttps://news.ycombinator.com/item?id=48364456https://news.ycombinator.com/item?id=48364456malloc can just return NULL (in specific, mmap returns -ENOMEM and your libc translates that). Applications need to check for success anyway

]]>Tue, 02 Jun 2026 00:36:12 +0000https://news.ycombinator.com/item?id=48364380jkrejchahttps://news.ycombinator.com/item?id=48364380https://news.ycombinator.com/item?id=48364380To be 100% fair, it's rare that processes are cloned on Windows, if only because it's part of the Native API that applications generally don't use directly, and CreateProcess is easier and does all the housekeeping stuff, etc, that people writing Windows applications generally come to expect (or don't even know happens)

I do think overcommit was a poor design choice, but I think it probably mostly does logically follow from the fact that fork and friends are the only ways available to create a process that's available to userspace. It's quite unfortunate though.

Part of the problem is that some applications wanted to reserve lots of address space but didn't necessarily want to touch it right away (such as when they were using it sparsely). Something that VirtualAlloc(x, MEM_RESERVE) (or mmap(..., MAP_NORESERVE)) would be suited for. But while malloc exists, mreserve doesn't in libc, and I think it was pretty uncommon to use it.

]]>Tue, 02 Jun 2026 00:33:10 +0000https://news.ycombinator.com/item?id=48364359jkrejchahttps://news.ycombinator.com/item?id=48364359https://news.ycombinator.com/item?id=48364359Windows doesn't use fork/exec for process creation in any relevant way today

There are Native APIs for implementing fork (needed for the obsolete POSIX subsystem, primarily), but even on the Native API side, processes are usually spawned through NtCreateProcess or RtlCreateUserProcess, though there is a bunch of setup with regards to the Csr APIs for the Win32 CreateProcess[1]).

[1]: https://stackoverflow.com/a/69605729/2805120

]]>Mon, 01 Jun 2026 15:28:58 +0000https://news.ycombinator.com/item?id=48358150jkrejchahttps://news.ycombinator.com/item?id=48358150https://news.ycombinator.com/item?id=48358150It has also created this unfortunate assumption a lot of the time that malloc and friends are (infallible OR crash) and, separately, can sometimes have potentially weird tendencies to force undefined behaviors on otherwise well-defined programs (I think primarily around mmap, although I'm not remembering the details super well).

Agreed though, overcommit is the culprit here. I get why it happened (unfortunate consequences of fork and friends existing as the way to spawn tasks and wanting those to be both performant and not fail in frustrating conditions), but I don't think it was a design that aged particularly well.

I actually like somewhat the notion of how Windows handles these two things

1. For address space reservations, you can reserve address space but in order to touch it you have to commit it. Commits have to be backed by something (RAM, a file, pagefiles if they exist) and if a commit fails, they'll get NULL back from malloc. It allows code to be more correct in the face of low-memory conditions or to try again later (Firefox for example, does this[1] on Windows).

2. Process creation is done with a specific API to create processes. The only problem with this I think is that you have to specify everything at creation time, but you could augment this by creating processes in a stopped state (iirc Linux has to do this anyway to set up some stuff before it can hand over control back to userland) and having the parent send FDs to the child or whatnot. Windows... doesn't do this, it has a couple of kitchen sink APIs for creating processes and setting up stuff like the standard streams... in any case I'm getting off topic.

Don't think there's much about that design that can be changed now though

[1]: https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...

]]>Mon, 01 Jun 2026 15:24:03 +0000https://news.ycombinator.com/item?id=48358085jkrejchahttps://news.ycombinator.com/item?id=48358085https://news.ycombinator.com/item?id=48358085> These days you can do oom score adjusting, which is not as strong as a pardon.

Writing -1000 to /proc//oom_score_adj will cause the OOM killer not to consider the process at all :)

From the man page proc_pid_oom_score_adj(5)

> The value of oom_score_adj is added to the badness score before it is used to determine which task to kill. Acceptable values range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). [...]. The lowest possible value, -1000, is equivalent to disabling OOM-killing entirely for that task, since it will always report a badness score of 0.

]]>Mon, 01 Jun 2026 15:07:06 +0000https://news.ycombinator.com/item?id=48357844jkrejchahttps://news.ycombinator.com/item?id=48357844https://news.ycombinator.com/item?id=48357844I'm not sure if it was what OP meant, but it's arguably a good availability technique (as long as you can generate the checksum, that is). Like, if I want to run custom firmware and flash it, having a checksum which verifies that the firmware isn't corrupted may help prevent bricking.

]]>Sat, 25 Apr 2026 08:44:54 +0000https://news.ycombinator.com/item?id=47899805jkrejchahttps://news.ycombinator.com/item?id=47899805https://news.ycombinator.com/item?id=47899805"Unable to reproduce" is a fair enough explicit close reason. This is more about those "stale" bots that exist that just kinda close the issues because there hasn't been any response for X days. The annoyance with the practice usually stems from the fact that many of the victims of this comes from a lack of maintainer response.

This sort of bot punishes users for making even valid reports that aren't fixed immediately or missed by the maintainers for whatever reason including transitory ones, etc.

Constantly bumping threads/issues/whatever is generally considered rude, so this is why issue reporters generally don't do it, plus generally the reporter isn't solely focused on that particular issue

]]>Mon, 20 Apr 2026 22:05:09 +0000https://news.ycombinator.com/item?id=47841614jkrejchahttps://news.ycombinator.com/item?id=47841614https://news.ycombinator.com/item?id=47841614Aside from the fact that you can do this statelessly (you could stuff a JWT or moral equivalent in the header as a Bearer token), if you were okay with server-side state, you can have the token be related to a principal or have permissions in of itself.

]]>Tue, 14 Apr 2026 16:43:21 +0000https://news.ycombinator.com/item?id=47767980jkrejchahttps://news.ycombinator.com/item?id=47767980https://news.ycombinator.com/item?id=47767980In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed

]]>Thu, 19 Mar 2026 23:05:04 +0000https://news.ycombinator.com/item?id=47447659jkrejchahttps://news.ycombinator.com/item?id=47447659https://news.ycombinator.com/item?id=47447659