jimrandomh

The author doesn't claim it, but worth stating explicitly: tmux is a security-critical piece of software that doesn't get the attention it deserves.

When you're selling a physical product at the single-digit-hundreds scale, "thin margin" is a false economy at best, fatal self-sabotage at worst. You should have a thick margin, which you reinvest into scaling up.

Your price is too low. You should raise your price until you aren't selling out.

I tried Cursor, and will occasionally switch into it, but I'm having a hard time using it because its relationship to extensions (particularly extensions that the user develops and sideloads) is badly broken. I tried doing minor customization (forking the vim plugin from the github version, creating a vscode hello-world-style plugin), and while everything worked in VsCode, transferring those plugins into Cursor did not. There was no documentation for plugins in Cursor, you just had to hope that things were similar-enough to VsCode. And then they failed to load with no debugging leads.

I think this is an artifact of Cursor being a closed-source fork of an open-source project, with a plugin architecture that's heavily reliant on the IDE at least being source-available. And, frankly, taking an open-source project like VsCode and commercializing it without even making it source-available is a dishonorable thing to do, and I'm rooting against them.

The article links to another news article which links to http://dx.doi.org/10.1038/s43856-025-00775-0 which says:

> For IHM risk prediction, we utilized the LSTM model, CW-LSTM model, transformer, LR, AdaBoost, XGBoost, and random forest (RF) models. For 5-year BCS prediction, we used MLP, AdaBoost, XGBoost, and RF models.

All of those acronyms are obsolete machine learning techniques from prior to the current trend of large language models. In other words, this paper is not reporting that any actually-deployed AI is failing, it's reporting that a group of researchers tried to build an AI for evaluating health, but failed to do so.

This headline is a lie. A backdoor in a Bluetooth chip would be something which enabled a wireless attacker to gain code execution on the chip. This article reports on something which allows the device drivers of the attached device to gain code execution on the chip, which does not violate a security boundary.

(In a well-functioning journalism ecosystem, this would require a retraction and would significantly harm the reputation of the outlet that wrote it. Sadly this will not happen.)

The HN title added the word "rationalist", which isn't in the source article. This is editorializing in a way that feels kind of slander-y. Their relationship to the bay area rationalist community is that we kicked them out long before any of this started.

We see similar issues on LessWrong. We're constantly being hit by bots that are egregiously badly behaved. Common behaviors include making far more requests per second than our entire userbase combined, distributing those requests between many IPs in order to bypass the rate limit on our firewall, and making each request with a unique user-agent string randomly drawn from a big list of user agents, to prevent blocking them that way. They ignore robots.txt. Other than the IP address, there's no way to identify them or find an abuse contact.

This is yet another in a long line of glucose-measurement devices designed to sell to unsophisticated research grantmaking agencies, rather than to diabetics. Making a device that "measures" blood sugar in a watch form factor is easy, and many research groups have done so. Making one that's accurate enough to compete with the CGMs that are already on the market is a different matter entirely.

Mirror: https://arbital.greaterwrong.com/p/behaviorist?l=102

Talking about someone's track record of predictions is not an ad hominem, in the context of evaluating their credibility with respect to the subject of those predictions.

This is also standard procedure for Falcon 9 landings. They would do it this way even if the launch license didn't require it, because they know the probability of some sort of failure of the booster is high, and they don't want to destroy the launch tower if they can help it.

I looked at the license application that was linked to, and while it contains many tests measuring zinc and hexavalent chromium, none of them are "high levels" (as compared to EPA standards for drinking water).

This article appears to be about the false claim that the water-deluge system (which sprays water to protect the launch pad from heat and to dampen noise) was "industrial wastewater". The headline is pedantically true because environmentalists did say it, but is definitely and intentionally misleading.

What input method are you using such that this is even possible? Nearly all English speakers are using keyboards with a single apostrophe key which inserts \x27, and could not insert any of the other quote characters even if they wanted to. As a result, nearly all extant English-language text uses \x27 for both apostrophes and single quotes, and all this Unicode prescriptivism is describing a convention that is clearly not the one that English actually follows.

It's an LG 65QNED99UPA. There are a few caveats: using a 65" display up close imposes some requirements on your window manager (you want to treat the sides more like you'd treat a secondary monitor in a multimonitor setup, rather than have windows go all the way edge to edge); and you need to make sure that every GPU, KVM, and cable can handle 8k, in an ecosystem where most don't. If you can handle those two things, it's great.

I tried, and went back to laptop+monitor. In theory it would be great when on the go, but it doesn't really function without a laptop present, which makes it pretty unwieldy as you need two devices. In theory it would be good in a the back seat of a car or when walking around, except the software doesn't allow you to do that (windows are pinned to space outside the car, you can't make them follow you). When I'm at a desk, I guess it would be better than a _bad_ monitor, but I have a nice big 8k screen and it's both better looking and more comfortable.

That's fine for when users are interactively typing commands, but it doesn't work when the command is being run by a non-busybox program which expects commands to exist in the standard locations.

The Reuters article says:

> "The decision to freeze Starlink's accounts stems from a separate dispute over unpaid fines X was ordered to pay due to its failure to turn over some documents."

This is deliberately misleading. The dispute stems from X having revealed a history of the government of Brazil demanding it censor and deanonymize political opponents and people alleging corruption, and refusing to continue doing so.

If Windows Update replaced components of Wine, that would (a) break people's Wine installs, and (b) give those users a way to legally get Microsoft's versions of those components for use outside of Windows.

GPT-3.5 is not the same thing. When people talk about LLMs having capabilities like complex reasoning, they're talking about current-gen models (eg Claude 3.5 Sonnet, GPT-4, Llama-405B).

If this were a normal commodity like chairs, the prices could not differ like that because people would buy it in a place where it's cheap, transport it to the US, and resell it.

The reason this doesn't happen for medications is that if you do this at scale, the FDA will have you arrested. If you remove the FDA's power to do that, the price of medications will fall immediately, and drastically.

If you need to go proprietary to make enough money that's fine, but this is not open source and in particular it is not compatible with the GPLv3 license stated in the README. You have likely already given some users the right to redistribute Luminaire under GPLv3.

There might be reasons to use `bc` like this if you don't know the type of `age` and it could be a non-numeric string. Buuuuut a programming language where a simple integer-comparison leads to two subprocesses is going to be slower than the slowest existing programming languages, by orders of magnitude.

I have it, and am barely using it. It can't do much of anything without being paired to a Macbook, due to being restricted to only running iPad apps (ie no software development tools, only a tablet-oriented browser with weird tablet quirks). This makes it not very portable in practice. The one place where I would want to use it is in the back seat of car rides, but it's entirely nonfunctional in that context.

Because there was a significant time period in which the rest of the world had access to Covid-19 tests but the US didn't, and this created political that forced the FDA to allow them. There isn't any similar pressure for other viruses, so the FDA maintains its ban on their production and sale.

I doubt the "internal technical error" was a technical issue. Someone sent the email unilaterally, and other people were upset by what it said.

They only said it wasn't fact-checked and "may" be inaccurate; they didn't actually say it was false. This is because if they claimed their member employment rate was higher than it is, that could be sued for it.

Setuid is a mechanism where you take a program, and mark it so it always runs as root (or some other user, but in this case root). The idea is that an unprivileged user can run a setuid program, and the program itself decides what privileges to allow.

The problem is that the user controls the program's view of the filesystem, environment variables, and other attributes, and this is an attack surface that can be used to trick it into loading and running code provided by the unprivileged user, which runs as root. For example, ordinary programs have a preamble inserted by the compiler where they load a programming-language runtime, usually from somewhere like /usr/lib; but a setuid program can't safely do this, because the user could use a chroot to replace /usr/lib with something different.

In practice, this means that writing a setuid program correctly is exceptionally difficult and error prone, can only be done in C, and imposes security requirements on the compiler flags/makefiles rather than the source code, which creates a large risk of distro- or compiler-specific vulnerabilities. In practice, sudo is the only program people allow to use the setuid mechanism, and sudo is a unique and dangerous snowflake.

I wouldn't worry too much about that. It's a tricky piece of security-critical software, receiving its first round of outside auditing; of course it has vulnerabilities. Sudo does have the advantage of being much more battle-tested, but that will even out with time; what will matter is how secure it is two years from now.

> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn't have all the permissions it needs, so you add "sudo" as an adverb.

Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in.

And sometimes the thing you're running is a complicated shell script or shell-script-like object, eg "sudo make install". In this case, you don't really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it'll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags.

And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.