Posts by josh@social.joshtriplett.org
(DIR) Post #AVfj0ri4hGqfQ14Tdg by josh@social.joshtriplett.org
2023-05-15T06:42:49.995563Z
0 likes, 0 repeats
m4 proc macro when? :)
(DIR) Post #AVfj0sWlenOjxEmxea by josh@social.joshtriplett.org
2023-05-15T06:44:50.209895Z
1 likes, 0 repeats
"Rust has a nice macro system, but it lacks a proper preprocessor. It deserves better than cpp. In this essay, I will
(DIR) Post #AVkckPffgszBD6dUJc by josh@social.joshtriplett.org
2023-05-13T18:37:52.613744Z
0 likes, 0 repeats
I think people have some notion that if they complain hard enough or throw up enough roadblocks, the thing they prefer will magically start getting maintained. It's the same notion that arises around architecture archaeology, init intransigence, OS ossification, and other dead-end development.Closely related: most Open Source projects let obscure use cases get some free maintenance, both because we have sympathy for such cases and because they're *usually* not much trouble. People get used to the free maintenance. So, when a project comes along that says "no, that's not supported" because something *isn't* trivial to support, people get angry.
(DIR) Post #AWlFEPvRZxCbQVVGaG by josh@social.joshtriplett.org
2023-06-16T19:45:57.819902Z
0 likes, 0 repeats
This seems like a scenario where the very common middle ground is incredibly awful."IT is not competent enough to enforce security restrictions" has serious problems, but people can get work done in that environment."IT is competent enough to enforce security restrictions and both willing and able to take responsibility for making them reasonable and dealing with any issues that arise" has a different set of potential problems, but can work."IT is competent enough to enforce security restrictions but is not willing or able to take responsibility for the consequences of their restrictions" creates a horrible environment that developers should run away from very fast.People in scenario 1 are in a local maximum, and aren't confident (and often have ample evidence to the contrary) that they'll get to scenario 2 rather than 3, so they fight both 2 and 3 tooth-and-nail. And it seems like very few companies reach 2, far more end up at 3, and the ones in 3 think they're in 2 and blame the developers for not accepting it.
(DIR) Post #AXfyskNlRnSDgaoW7U by josh@social.joshtriplett.org
2023-07-13T23:18:00.812441Z
0 likes, 0 repeats
Three Joshes together at #FOSSY
(DIR) Post #AXwCjCpAHnwKzIy1gm by josh@social.joshtriplett.org
2023-07-22T01:50:26.373447Z
0 likes, 0 repeats
I think it's *entirely* reasonable for any such proposal to not receive charitable interpretations unless it shows a good understanding of the landscape. Anyone working in that area in good faith should be spelling out, extremely carefully, "this area has the potential for abuse and severe damage and here's everything we're doing to prevent that". And this spec just...hasn't.
(DIR) Post #AYI2H2Q2CMO0xq8UG8 by josh@social.joshtriplett.org
2023-08-01T14:12:15.089722Z
0 likes, 0 repeats
...yeah, that works, and it's substantially clearer and more portable. Thank you.
(DIR) Post #AYI2H3CFJ6x1NMgzPE by josh@social.joshtriplett.org
2023-08-01T14:12:46.533389Z
0 likes, 0 repeats
I've seen and used that syntax before, but it's sufficiently obscure that I'd forgotten about its existence.
(DIR) Post #Ab3blWTmfICylUn5hA by josh@social.joshtriplett.org
2023-10-23T08:39:16.533902Z
1 likes, 0 repeats
It has downsides: if you run `make` with `--output-sync=line` then you don't get any output from any individual command until the command finishes. That's fine if each individual compile takes relatively little time, but it's annoying if one command might take many seconds and you'd like the incremental progress. It's probably the right behavior in *most* cases, but it might be disruptive as a default.Also, it breaks anything expecting a terminal, so no colors, terminal formatting, or progress bars in your output.
(DIR) Post #AbLDHxo4xktNAGTuT2 by josh@social.joshtriplett.org
2023-10-31T16:42:29.039317Z
0 likes, 1 repeats
Fun date/time handling bug in macOS, which I haven't seen any mention of on the Internet:Time in UNIX system calls counts from the epoch, 1970-01-01. The `timespec` struct used in various system calls represents this as a number of seconds and a number of nanoseconds. Nanoseconds are required to be between 0 and 999,999,999, because the portion outside that range should be represented in the seconds field; if nanoseconds were larger than 999,999,999, the seconds field should go up instead.So, seconds=0 means 1970-01-01, seconds=86400 means 1970-01-02, etc.Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems that support times before the epoch, that's seconds=-86400, one day before the epoch. Perfectly reasonable so far.But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other words, a tenth of a second after one minute before the epoch.On most UNIX systems, that's represented as seconds=-60, nanoseconds=100000000.The macOS bug: it returns seconds=-59, nanoseconds=-900000000.I can see how they got that: it's 59.9 seconds before the epoch.But that violates the invariant of the timespec data structure: nanoseconds must be between 0 and 999,999,999. Which, in turn, caused an assertion in the Rust standard library.We can fix this, though: on macOS, if we get a `timespec` value with seconds less than or equal to zero, and nanoseconds between -999,999,999 and -1 (inclusive), we can borrow 1 from the seconds field and add 1,000,000,000 to the nanoseconds.The resulting timespec value is still accepted by macOS, and when fed back into the OS, produces the same results. (If you set a file's mtime with that timestamp, then read it back, you get back the one with negative nanoseconds again.)See https://github.com/rust-lang/rust/issues/108277#issuecomment-1787057158 for bug discussion, and see https://github.com/rust-lang/rust/pull/117451/ for https://github.com/Byron's PR fixing it.
(DIR) Post #AbM2od7hymjAEbzrQu by josh@social.joshtriplett.org
2023-11-01T06:40:21.716553Z
0 likes, 0 repeats
Sure, but that happened well after vendors had the option of ACPI and could just say "this new thing sucks, where do we shove all the proprietary custom stuff" and ignore it.Not saying it's politically feasible to push standardized interfaces with no custom code, just that the result seems wildly better.(Then again, at this point I'd just take "you can't get certified for Windows if you use SMI, ever".)
(DIR) Post #Abw3kcxW4Kf0g0iDWi by josh@social.joshtriplett.org
2023-11-17T15:05:31.491563Z
1 likes, 0 repeats
Version numbers are numbers in base infinity. Each "digit" of a version number is expressed as a base-10 number, with digits of the version number separated by dots to avoid ambiguity. No matter what you add or multiply into a digit of the version number, it will never carry into the next digit: no amount of patch versions carries into a minor version, and no amount of minor versions carries into a major version. Similarly, it's not possible to borrow from a higher digit, because you'd get an infinite amount of the next lower digit, which would immediately carry back into the higher digit because infinity - finite is still infinity.There's a classic joke that all bases are base 10 (in their own base). So, version numbers use base 1.0. 1.0 is infinity. Which explains why it's so hard to get to 1.0, and why you can do an infinite amount of work without getting there.
(DIR) Post #AhO80GbmGxkfsWDwbA by josh@social.joshtriplett.org
2024-04-29T17:27:58.064251Z
1 likes, 0 repeats
> the command line of run0 is intentionally kept close to sudo's.Could we get a -E/--preserve-env switch? (It'd also be nice if users can do per-user configuration to set that, or to set a variety of specific environment variable passthroughs.) There are a variety of environment variables that are useful to pass through, and I'd rather not specify them all every time or do configuration-via-shell-alias.
(DIR) Post #AhuFdcBM3xKg13f5do by josh@social.joshtriplett.org
2024-04-05T16:23:22.379475Z
0 likes, 0 repeats
All the research I've seen suggests that humans are wired to be able to do this within groups they consider their in-group, but not in a larger setting. Which doesn't mean we can't do it, but that it'll take overcoming the norm to do so.
(DIR) Post #ArZyvXkM3ePagMDkno by josh@social.joshtriplett.org
2025-02-28T13:08:39.229575Z
1 likes, 0 repeats
Welp. Firefox has really just completely abandoned every aspect of trustworthiness.
(DIR) Post #AtW02dJl3qKb2FAvZ2 by josh@social.joshtriplett.org
2025-04-27T10:12:34.803064Z
0 likes, 0 repeats
smol is alive and well, and well-regarded. One thing that makes it a little harder to notice is that crates which supported async-std tended to depend on async-std, while with smol it's more common to depend directly on the subset of underlying crates you need (e.g. async-io, futures-lite).