> The artifacts weren't a conscious design decision, they were a constraint.
Of course the artifacts were a constraint. Whether consciously considered or not, constraints influence design decisions.
> We don't know whether the designers would have chosen to keep them or not, if they had the choice.
Maybe Frédéric Chopin would have written his etudes and nocturnes for the Roland SC-55 Goblins instrument patch if that choice had been available to him, but it wasn't. What we do know of are the choices he actually made facing the constraints that he actually faced.
Similarly, maybe a GBA music composer would have preferred for the music to be a high fidelity recording of a full piano arrangement if that choice had been available to them. But it wasn't, so they didn't.
We can speculate all we want about what creative choices might have been made if the people behind them were dealt a different hand, but in reality choices don't exist in isolation of constraints, and I think any line of reasoning trying to divorce the two is futile.
I propose that there is a different kind of "AI slop" than the one normally considered. This other category concerns ill-considered, half baked ideas relating to AI, without necessarily being conceived by it.
It doesn't take that much experimentation, though. Either set up not enough swap and keep increasing it by a little bit until you stop needing to increase it, or set up too much, and monitor your max use for a while (days/weeks), and then decrease it to a little more than the max you used.
I went with "set up 0 swap" and then never needed to increase it. I built my PC in 2023, when RAM prices were still reasonable, stuck 128GiB of ECC DDR5 in, and haven't run into any need for swap. Start with 0, turn on zswap, and if you don't have enough RAM then make a swap file & set it up as backing for zswap.
"Keep swap space below few hundred megabytes but above zero" is a good example of a rule of thumb.
"Make the swap large enough to keep all inactive anonymous pages after the workload has stabilized, but not too large to cause swap thrashing and a delayed OOM kill if a fast memory leak happens" is not.
There's no need to even take it with a grain of salt. The factual circumstances described in the article are extremely mundane, but the article tries to paint her participation as a problem by supposing that anyone participating in a public event should only do so if they can answer for every disparate opinion of everyone else there.
Part of the hacker news guidelines is to assume that everyone read the article, so obviously you read the sentence that started with:
> One can never control what others say or do at any public gathering but if actions take place that I disagree with, once this has been pointed out, it is right and important to explain one’s own position
I did. Are you trying to make a point here? If so, what is your point? I see a lot of weaseling around what you want to get across, but no actual comment on anything I wrote.
I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files.
If you have a jumphost chain, you can configure that in the SSH config.
I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.
File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on.
> Which bit is made up? Can we tell at all if that group is "a hotbed of creative works"?
If we can't tell, the "they aren't" bit is of course made up. Are you not arguing in good faith, or are you just not paying attention to what you're quoting?
One thing is that Raspberry PI have a fewer of them. So less chance of one becoming faulty.
Regarding higher quality components, I think the for the usecase (I mean the kinds of thing it is supposed to be used for) of Raspberry PI, reliability is more important.
> Regarding higher quality components, I think the for the usecase (I mean the kinds of thing it is supposed to be used for) of Raspberry PI, reliability is more important.
That you think that reliability is more important for a Raspberry Pi usecase than a laptop doesn't somehow magically make it a fact that its components are of higher quality than your average laptop. You only speculate and then speculate further on the basis of your original speculation. That's not how you arrive at a basis for a factual claim or an estimate.
reply