ninkendo

  export CARGO_TARGET_DIR="$HOME/.cache/cargo-target/myproject"

But this technique errs on the side of not using invalid artifacts, at the cost of not having a good system for expiring them. To maintain the goal of never having to worry about when to require a clean rebuild, solving cleaning of stale artifacts becomes a much harder problem.

This is one of those problems that’s both huge/important, and probably impossible to solve. It bites me all the time, I have a measly 1TB nvme disk and I basically have to wipe my target directory and docker build cache (I have a shared cargo cache volume across builds) every other day. I’ve had this workstation for 2.5 years now and I’m honestly worried about nand endurance coming to bite me soon.

How would one even solve this? When do you know a cache entry won’t be used any more? Trace back provenance of artifacts to their sources, and if the mtimes have been bumped just delete the artifacts? It’s not like resetting source files to older mtimes is a good idea anyway…

A tiling window manager is a lot more useful if it doesn’t always tile, yes. The ones I’ve tried don’t seem to have a graceful way of saying “allow overlapping just this once”, but I’ve only tried a few of them (i3 is the one I remember most. I honestly can’t remember if I tried hyprland. If I did it was probably only for a few minutes.)

Now, you seem to be upset that I don’t “have a point worth trying to understand”, perhaps you can enlighten the class and explain why your tiling window manager of choice does this better? I’ve already described my ideal interaction, so if your WM does this well I’d love to hear about it. As it is right now, you seem to be the one who’s withholding details.

Yeah and fuck them, right? Won't these parasite breeders learn that they have no right to take vacations? They should experience nothing but misery until their children are 5.

Unrelated, why are so few people opting to have kids?

More generally, tiling is what you want when you have a particular layout you like, each window has a reason for existence, and you want them all open and visible at the same time. That constitutes like, 10% of my time using a computer. Mostly I just want “give me a new window, let me do a thing, then it’s gone”, with said new window occupying 100% of my attention while it’s there. Having to carve out space for it in a tile layout (even if the tiling is automatic) just doesn’t make sense with the way I use my machine.

My first exposure to Solaris was in 2003 when Linux had Gnome 2.6 and Solaris had CDE. The UI on my Debian box seemed decades ahead of the Solaris machines I managed, which looked like Windows 3.1 and performed about as well.

Combined with Linux package managers being infinitely better, the GNU core utilities having so many more conveniences and options than the Solaris equivalents, I felt like Sun was this dinosaur that couldn’t die fast enough. I’ll still never understand why so many people praise Sun for its engineering culture when free software seemed so superior to me at the time.

My favorite anecdote exemplifying my opinion about Solaris at the time: you log into the console of your Sun workstation, running SunOS, with your Sun keyboard plugged in, and press backspace. It echoes ^H back to you. They couldn’t even figure out how to configure their own keyboards correctly out of the box.

Maybe in the 90s the standards were different. Maybe their tech was better. But by the time I ever used their software is was the butt of jokes.

If the pedestrian hasn't gotten to the driveway quite yet, and you're stopping to let them get there and cross out of an abundance of caution, then it may not have been legally required for you to yield. And the motorcyclist behind you could very reasonably have seen the pedestrian too (and reasoned that the pedestrian was still several seconds away from getting to the driveway) and not expected you to stop. In such a situation, such an abundance of caution could have easily "caused" an accident, in that not yielding and proceeding through would have been perfectly safe.

(I'm of course being steel-manning GP's argument here, it could have very easily been that the pedestrian was already crossing the driveway at that point, I didn't see the video. Point is, "more caution" doesn't always mean "less chance of an accident".)

Since Trump. Entirely.

I generally think there’s actually not that much corruption in politics in the US. Mostly just insider trading, if you count by dollar amount. But I think generally there have been studies on the net worth of people before they are elected to public office versus after, and it’s within a few percentage points of the general population. There’s also the issue of lobbying firms hiring ex politicians but to be honest there’s something to be said for an ex-politician as a lobbyist: they have expertise and connections, they’re valuable to lobbying firms even if there’s no favors involved.

What we have now is:

- The president openly hocking a cryptocurrency and making billions off of it

- Taking money for early access to his posts on truth social, which is essentially how he communicates to the public. “Give me money and I’ll tell you first”

- Giving pardons to his supporters in a brazen and obvious way

- Taking donations from private donors to fund his pet projects like the White House ballroom

I could go on but like I said, I’m not really interested in the actual debate here because nobody’s gonna change their minds if they haven’t already.

(To be clear, I absolutely believe the scale has increased tremendously, but arguing about this is gonna be fruitless because it’s all subjective, there’s no hard numbers for any of it, and anything I can point out, you can just say “well that’s because they’re doing it in the open now, they were always doing it”, which is just as unfalsifiable. There’s basically no good outcome to debating this.)

A large, mature codebase that predates LLM’s and for which changes need a high level of scrutiny regardless of who made them (think llvm, WebKit, important foundational software), you’re going to want humans in the loop as much as ever… I think reviewing LLM output is the most important thing a human can provide.

But for vibe coded apps where you can just one-shot another one if anything goes wrong? Just vibe the reviews too, who cares. Let the robots review the robots.

Be careful with doing AI review if your codebase is in the former category. Or your codebase will quickly turn into the latter. Complete with “you can just one-shot another one”, because if nobody understands the code any more, there’s not much lost by just you (or your competitors, etc) replacing it wholesale with an AI-written alternative.

I struggle with this a lot. 2 years ago we had a half dozen PR’s a day with a lot of careful review, and now there’s more like 30 of them per day and most people are just rubber stamping them after the AI reviews it. I’m still fighting the good fight trying to review every line of the PR’s I have time to look at, but that constitutes maybe 10% of them. Not only am I barely making a dent, but it’s awkward when I post nitpicks like “this function should go in this module”, etc, the author usually looks at me funny like “why are you even reading this”. Our codebase is gradually becoming more and more vibe coded, and it’s depressing me.

When google trained a neural net on Go moves, using some text notation for them, with no other vocabulary of any kind, just predict the next go move, they noticed a representation of a Go board had essentially formed in the network, all on its own. It had never “seen” a go board, or had one explained, but they could map neuron states to go board squares pretty much 1:1.

I truly think that LLM’s with hundreds of billions of parameters in their neural networks have all kinds of hidden “models” of things that arise from the simple act of predicting tokens. We’ve seen that the hidden layers in their networks model all sorts of program execution state for instance, when they’re working on coding tasks.

“Predict the next token” is a way of shaping/reshaping the neural network until it actually develops models of the things you’re giving it. Like the go board example. And I would wager that it has a compounding effect: once you have some useful models in the network, they can unlock the creation of other models, and so on.

(I don’t personally run my network as ULA-only, I do ULA+GUA as you describe, but I had to basically give up on being able to reliably tie traffic logs to a known source… hosts in my LAN always seem to use a GUA to talk to each other when discovering over mDNS, which of course means they use privacy addresses by default. My ULA uses DHCP so that I can get stable addresses and know who is who, but it’s useless when things just decide to use the GUA anyway.)

No, because that would be ludicrous, cookies are obviously necessary for the concept of a “login” or even just a “session” to exist.

Given that the stated purpose of the article is to literally explain how simple something is, not explaining that thing seems a bit misleading, no?

I’m gonna get rich when I make a website explaining all the technical concepts in AI. Every article will just say “lol google it”, it’s gonna be great.

It’s not that I can’t or don’t know how, it’s rather that the expectation should be that a website should… link you to the information it believes to be relevant background. It’s why it’s called a “web”, linking is a core concept.

Me personally, I have immense trouble believing that passively watching entertainment has the same effect on working memory as, say, playing video games. And even within video games there’s probably a distinction between the more story-driven games that are a lot more passive to play, versus puzzle games that require active reasoning, versus games that test reaction time or memorization, etc.

(Full disclosure: I was a child of the 80’s and raised by a Nintendo and my computer. I think I turned out ok but I don’t have any alternative childhood to compare to)

The toplevel “Hide My Email” iCloud feature is a different thing, can be done independently of a SIWA flow (you can just go into settings and make more addresses, all it needs is a name and a notes field) and uses @icloud.com in order to make your anonymized email address look indistinguishable from other iCloud users.

The former is “filterable”, yes, but it’s moot because you only get those if you offer Sign In With Apple in the first place, and if you want real emails, you would already know to just… not do that.

The latter is very much not filterable.

The confusing thing though, is that when a user uses Sign In With Apple, they are offered two options: “share my email” which gives the site your real address, and “hide my email” which gives an @private.appleid.com address. But this “hide my email” option is a totally different thing from the separate “hide my email” service, which lets you make arbitrarily many @icloud.com private aliases to forward to your real address. Critically, the latter toplevel Hide My Email feature works with sites that don’t use Sign In With Apple. It’s just stupidly unfortunate that Apple calls both of these features “hide my email.”

I don’t think I could imagine a stupider idea than this if I tried. To paraphrase Babbage: I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a solution.

Because that would be super out of place, and you understand that intuitively.

That’s all nohello is about. It’s not trying to say “don’t be nice and say hi”, it’s saying “batch your hello and your question in the same message please”. Asynchronous communication mediums need an asynchronous communication style, it’s not that hard.

> It's bad civic hygiene to build technologies that could someday be used to facilitate a police state

Not “avoid building technologies that could be used by a police state”, as the HN title currently says.

The HN title reads like any technology a police state could ever use should be avoided. Like cars, or pencils. Anything.

Schneier’s quote says “used to facilitate a police state” is a lot more specific: could be used to bring a police state into existence where it wouldn’t have been possible before, like having a database of everyone’s sexuality, etc.

A recent example I saw was an agent leaving a comment "// return an error here instead of panicking, as a panic will abort the process". Because likely the original human in the loop caught the AI putting a panic in there and told them not to, and then the comment to not do panics was placed in there. But to a future agent, it'll see that and think "ok, this comment must be here because we usually do use panics instead of returning errors, this place must be an exception", and now its context window is primed to think of using panics first.

It's pretty well-documented at this point that spending a lot of tokens explaining what not to do can actually increase the likelihood of an LLM doing that thing, especially when its context window is getting full.

It's like if you go to the grocery store and see a sign saying "Vegan tomatoes". It sounds fine until you think "wait, aren't all tomatoes vegan?" and now you start doubting yourself and start imagining what a non-vegan tomato would be.

Another semi-related issue is the tendency for LLM's to make up their own dumb little short-hand words for things that it has been talking about over and over in the context window. "The lock that prevents a user from being deleted while another thread is updating it" becomes a "user-fence", and now there's comments saying "// this function returns a user-fence", and I have absolutely no idea what that's supposed to even mean.

It's doubly insidious because it trips up the human brain too: When I'm reading a PR saying "fix lock ordering to avoid deadlocks on user deletion", and there's a comment somewhere in the diff saying "// use the fixed lock ordering here", my brain tends to completely forget the fact that the comment doesn't make any sense in its surrounding context. Because it makes perfect sense in the context of being the human reviewing the diff. But it's a slight bit of mental effort to remind yourself "what is this comment going to look like to someone reading the code after this is merged?"

I wouldn't be surprised whatsoever if the RLHF supervisors forget to apply that extra bit of mental effort and say "yup, this comment looks great", forgetting to check the surrounding code to see if it makes sense on its own.

Do these plugins mean you don't get to store them in git? You're just going to open up the developer studio and YOLO a change to the stored procedure, live in production? Because the whole argument is that the way we do version control, code review, bisecting, single-artifact deployment, etc is generally at odds with how stored procedures work. Saying "but my IDE has a good plugin" solves maybe 1/100th of the problem.

Some answers to doing stored procedures in a version control system that I've seen:

- Put everything in a migrations directory, and every time you change the stored procedure, introduce a new migration that completely rewrites it. (Merge conflicts are hell with this, plus all the massive amount of waste it generates in the checked-out tree)

- Put the stored procedures in a directory as normal code and then "sync" them to the database at runtime (with all the massive foot-guns this entails, trying to detect if they've changed versus what's in the database, etc)

- Eschewing stored procedures in favor of using prepared statements and having your ORM figure out when to use them

There may be others but I think they're all going to look like some form of one of the above.

> and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to.

(Emphasis mine.)

In the Flash case, they changed the direction memcpy works in, in a way that didn’t actually improve any performance (Linus did benchmarks to show it) and Linus’s point was that there’s no upside to the change, and only downsides, so on the whole it makes no sense to keep the changed memcpy.

You could imagine plenty of scenarios where existing behavior truly is broken, and show that no popular software depends on the brokenness (which is why distros are in a great place to do these kinds of smoke tests, they have thousands of packages they can test), and make a judgement call.

A “zero regressions no matter what” policy is impossible in practice due to Hyrum’s law, at some point you have to use common sense and draw the line somewhere sensible.

By that definition, any change of any kind will break ABI, Hyrum’s law and spacebar heating and all that.