foresto

> It doesnt let you have unused variables

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

The first time I saw something like this was in a music-focused virtual world from the 2000s. Strangers would strike up conversations with each other, dance (in some cases to well-known artists), wander around to see what others were doing, and generally just hang out.

I think it was called vSide.

https://en.wikipedia.org/wiki/VSide

This title evokes memories of The Twilight Zone's To Serve Man episode.

> If the email matches their GitHub account, GitHub links the commit to their profile and grants them contributor status.

When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)

However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.

This could be read as reductive, presumptuous, ignorant, and insulting.

At the same time, it's often technically true, but for a good reason that you neglected to mention:

Those old tools tend to be very capable email clients, not web apps with their awkward attempts to simplify complex conversation structure. A good email client can handle large, high-traffic, frequently branching, long-lived threads with ease. All the web forums I've ever used fail miserably here.

The people who are tasked with participating in large scale discussion groups (like the LKML) know this through experience. They prefer email because it works better. It makes their lives easier. It helps them to be more efficient, which is absolutely necessary given the sheer volume of messaging that they handle.

Yes, a specialized tool is required to get these benefits, just as a specialized tool is required to make web server output easily readable. Thankfully, these tools have existed for decades.

In case anyone else likes to know the panel manufacturer before buying a display, it looks like this one is made by Samsung.

https://www.displayspecifications.com/en/model/f86e3770

https://www.displayspecifications.com/en/model/49bc3e67

> I helped them make the wrong choice, Mercurial.

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

Of course, it would also create a demand for open-source game server libraries, which would surely appear after a while and make the whole process much easier.

So while I believe you about all those difficulties existing today, it's plausible that they would mostly fade away over time. I think temporary growing pains would be an acceptable price for the significant long-term public benefit.

Thanks. Outside of LLM circles, DS4 is usually a video game controller.

> Government leaders will never give up their pipeline of knowing everything about everyone.

Then let us hire different leaders into government. Public servants, not overlords.

> for (third-party) sale

Many of us find it unethical to give money to scalpers.

> a handful of .net domains that are under $100

And this is why.

Good luck in your gamble.

That was clearly not true for domains directly under .us when I last read their rules, roughly a year ago.

I suppose it might be true for .city.state.us subdomains, but those fail my first criterion (they're not short), and are themselves a privacy hazard since they substantially narrow the search space for personal info about the domain owner. So it doesn't refute my criticism.

Having a domain under the .us TLD once seemed appealing to me for practical reasons: It's short, consistently inexpensive, and hasn't already sold the vast majority of its useful namespace to squatters.

Unfortunately, it forbids WHOIS privacy services, which makes it a privacy and security hazard for personal domains. Pity, that.

This one?

https://en.wikipedia.org/wiki/DEX_(protocol)

https://www.cable-tester.com/dex-connector-pin-out/

https://www.storedex.com/abcs-of-dex

I'm aware of serial breaks, but this is the first I've heard of them being interpreted as SysRq by Linux. That could be handy. Thanks for the tip.

I assume the possibility of spurious Rx state is why FTDI chose to wire Rx to the tip pin of the female TRS connector: It's the last pin to make contact with anything when plugging in, and therefore least likely to be bridged to ground. I suppose the mechanical design of any particular jack would determine whether it's possible at all.

Well, not every vendor does it differently, because there are far more vendors than possible wiring permutations on a 3-contact connector... but I understand what you mean.

The same issue applies to PCB header pins.

And the same goes for 25-pin D-sub connectors, which have been widely used as RS-232, parallel printer, and SCSI ports.

Voltages vary, too.

This is why we check before wiring them to other things.

What byte sequence on a Tx/Rx/Gnd serial line can trigger Sysrq key sequences?

My scenario is connecting terminal emulators to getty or u-boot, which I think is a common one. A blip of line noise when plugging in would be barely considered an annoyance, easily cleared by pressing Backspace.

But yes, if someone happens to be using their serial line for some kind of sensitive signaling, then I would agree that choosing a more isolated connector (or just avoiding hotplug) would make sense.

They're not random connections; they're predictable. I'm not worried about Tx briefly touching Rx or ground in these devices.

FTDI (the company practically synonymous with TTL serial adapters) uses 3.5mm tip-ring-sleeve connectors for this. In other words, a common headphone jack.

I added one to my single-board computer enclosure, following FTDI's wiring. Now I can easily connect whenever I need to use the serial console, and a standard 3.5mm audio extension cable will let me reach across the room without moving my main computer. Replacement parts, if I ever need them, are cheap and easy to find.

Here's the pinout:

https://www.ftdichip.com/Support/Documents/DataSheets/Cables...

A stdlib doesn't have to provide everything under the sun in order to be helpful here.

Languages with rich standard libraries provide enough common components that it's feasible to build things using only a small handful of external dependencies. Each of those can be carefully chosen, monitored, and potentially even audited, by an individual or small team.

That doesn't make the resulting software exploit-proof, of course, but it seems to me much less risky than an ecosystem where most programs pull in hundreds of dependencies, all of which receive far less scrutiny than a language's standard library.

> That's not a special,

It is a special when the usual price is $2 each.

> Why not?

Because I'm not interested.

> The computers are not dumb.

Nobody has suggested that they malfunction.

I thought this was obvious, but to spell it out: I was suggesting that they might not necessarily be programmed to apply a different price depending on quantity. An item might have a flat price of $1 each, but labeled on the shelf/bin as "special: five for $5" to encourage larger purchases.

I have personally encountered this. Meanwhile, I do not recall an example of buying a quantity smaller than suggested and being charged a higher price per item. Hence my question about labeling and law.

> Also, if you do not have a member/loyalty account, you do not get those discounts.

I'm not talking about membership discounts.

> the 8 oz will be on sale but only if you buy at least 2 or 3, its incredibly frustrating.

Have you tested this by buying just one, and checking the price on the receipt?

I ask because someone once told me this was illegal in the US; that a shop was allowed to display the sale price only for a larger quantity, but they had to honor the same price per unit if you only bought one. (I think we were discussing produce at the time, in case that matters.) I've long wondered if that was true or just an urban legend.

Thanks for confirming!

I'm pretty sure that conversion was done by the C library, just as stated in the article. Not by DOS. ASCII 0x0A '\n' is always one byte*, and C library implementations for DOS would insert an ASCII 0x0D '\r' byte before it at output time if the C FILE stream had been opened in text mode.

Note that printf(), which you use in your example, is a C library function that writes writes to a predefined text mode stream. So it follows the same rules.

I wasn't able to dig up the source code of a vintage DOS compiler's C library in a few minutes of looking, so I can't prove it right now, but this section of the C standard (7.21.2 - Streams) hints that my recollection is correct:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#p...

*(On systems where the char type is one byte, of course, which is the case for DOS C compilers.)

Are the developers allowed to sell those keys for less than the Steam price?

> It only works with Steam, it can't work on a desktop OS without it, despite standard layout.

This review says otherwise:

https://www.gamingonlinux.com/2026/05/the-new-steam-controll...

> Using The Steam Controller Completely Outside Of Steam

> [...] However, at least on the newly released Fedora KDE 44, the system does appear to detect it as a basic gamepad out of the box.

> [...] I installed LIMBO from GOG with GE-Proton and it worked great even with vibration.

More example games are described there as well. A few apparently get confused by the Steam Controller presenting itself as a game controller, a keyboard, and a mouse, but most seem to be fine.

Those tests were done on Linux. I wonder if it's any different on Windows.

> Their new refund policy is great,

The "played for less than two hours" refund policy is more of a compromise than great, IMHO.

It works well for games that are quick to run and enjoy. However, quite a few of the games I've played will easily burn two hours on loading, compiling shaders, watching unskippable branding animations (splash screens), tuning graphics settings, setting up key bindings, and working past miscellaneous bugs.

Steam's "play time" clock starts when the game executable is launched, and keeps running during all of that nonsense, even at title screens and menus. Some games have run past Valve's return window before I got even a minute of play time.

It would be nice if one of Steam's widely used APIs (Steamworks?) included a way for a game to register when it is actually being played, as opposed to loading or setting up or sitting at a pause screen. I think this would help with the return window problem, and finally make the played hours count on our Steam profiles somewhat accurate.