moring

The article shows nicely how "every byte matters" is false. First, it starts off by talking about the cost of a new field, when the actual topic is array-of-structs vs. struct-of-arrays. Then, this:

> How much of an impact can this have? > Reading is:alive (1 byte) Across 1M Monsters

You aren't reading one byte here, you are reading 1M bytes! Of course, optimizing the access to 1M bytes is something to consider. Optimizing the access to one byte isn't.

The article is definitely worth reading IMHO, but it really needs a better headline!

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.

> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

I claimed that it is possible, not that it is easy.

Ideally, the permission list is meant for curators which end-users trust and can rely on.

Also, historically, permission lists have been fine-grained but too coarse at the same time, meaning they were "fine" in the wrong way, based on what is easy to implement instead of what the user needs.

> You can't have an extension system that (...)

Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both".

Taking your examples:

> run a locally installed linter

VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something.

This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata.

Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access".

Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too.

> view the status of docker containers

"This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window".

> users will scream and cry about extensions being limited

Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".

To do things that a human could have done in theory, but did not do because it would have been too expensive.

> It seems like one needs a big machine farm and a vast corpus of training data with a lot of manual curation to get started creating a competitive LLM, plus whatever technical expertise that I don't even know about. The stuff that makes LLMs exist now and not earlier.

"big machine farm" reminds me of folding@home, which needed the same and got it.

"manual curation" is what Wikipedia did, as well as the free software community.

"technical expertise" is present in the free software world too. It is sparse since it is sparse in the world as a whole, but it exists.

"no Linus Torvalds figure" might be the main problem ATM.

Bonus points for the kafkaesque responses you get as the end-user when you try to actually pass that information upstream where it could be fixed...

So? Many would prefer a DoS-type event over spending $WHATEVER_THEIR_HARD_CAP_IS. This is kinda the definition of a hard cap, so you would place it sufficiently high that DoSing your system is indeed preferable.

Also, doing this on a per-service basis doesn't seem that far-fetched to me, so you'd only kill that service and get at least some chance that the rest of your system remains usable.

It seems hard to believe that a one-hour delay on such a counter is impossible to achieve, and one hour would reduce the risk from "catastrophic" to "serious problem" in most cases.

Also, if implementing a cap is a desired feature that justifies trade-offs to be made, then it is psosible to translate the budget cap (in terms of money) back into service-specific caps that are easier to keep consistent. Such as "autoscale this set of VMs" and "my budget cap is $1000/hour", with the VM type being priced at $10/hour, translated to "autoscale to at most 100 instances". That would need dev work (i.e. this feature being considered important) and would not respect the budget cap in a cross-service way automatically, but still it is another piece in the puzzle.

> If you made a local-first, P2P version of Figma what would break first?

The guy who has to keep it running day by day, next to the other 30 local-first systems.

> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?

Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.

I think there is: It is the line between "not spending extra money to make sure it works" and "spending extra money to make sure it won't work".

There is a related problem with warranty: an inferior third-party replacement part may cause damage to higher-quality original parts. There is a line here between "making sure you don't have to deal with follow-up damage caused by inferior parts" and "preventing the use of inferior parts". This is a bit more blurry because most cases won't be clear-cut, and dealing with them will be a burden on the original manufacturer.

I think it is important that we reward the nice players as much as we punish the bad ones. A blanket "all companies bad" just means that no company has an incentive to be anything less than bad.

This may sound absurd, but it was a mental breakthrough for me to realize that all these "what-ifs" (multicore 6502 computers or whatever) are really simple to simulate in software only, with a bespoke simulator, WAY above register transfer level. There is really no need to deal with the peculiarities of FPGAs or Verilog; just write an instruction-level simulator for the ISA you choose (that's really simple for the 6502), make it run several instances for multicore architectures, and there you go for your custom computer.

I mean this as a hint for people who are similarly stuck with RTL tinkering when they actually want to tinker with system architecture.

By that logic, operating system developers struggle to understand that putting two files with the same name into the same folder(1) is very much possible in the physical world.

(1) or referencing them from the same directory, which was the earlier metaphor.

Questioning standard nomenclature is useful too, as long as it provides insight and is not just bike-shedding. "optimization" (in the context of an optimizing compiler) is generally expected not to alter the semantics of a program.

Your comment seems to miss that the author is speaking about technical drawings, not sketches, in particular this part:

> And I would argue also that this scarcity of ability was already a problem for the last 100 years. The whole iterative process of ideation (ie. designing, sketching) gets so much less intuitive, if one has to pull out a ruler first, or boot up his machine.

You mention sketching explicitly, which is exlcuded by the author. And making technical drawings without a ruler seems insane to me.

> In dev-speak, removing hand-drawing from the skill set of architects entirely is as if you were deliberately removing HMR from your local web dev-setup.

That would be true if you removed sketching, but removing hand-drawn technical drawings is more like replacing hand-crafted optimized assembler code with an optimizing compiler.

Paysafe cards. A store near me has them.

Yes, I do. It just means that you have to manually "recharge" your Steam wallet when it runs low. That's some effort, but it limits the possible damage if something goes wrong.

IMHO this supports the original point that payment via Steam would be an upgrade:

Sending cash to a postal address isn't low-effort nor low-risk.

Payment by cheque is something I have never done, nor would I know how to do it. I'd have to ask at my bank -- not low effort. I don't know if I'm an outlier here but I have never heard from any of my peers who ever did such a thing.

The same or even worse is true for international money orders. The whole concept of making a money transfer to a postal address is something I have never heard of. Where's the IBAN?

The Wine team is right to put even PayPal before all of these.

Requires PayPal or credit card. The suggestion was to pay with your Steam Wallet or whatever payment method already used when you buy a Proton-based game on Steam.

That is only historic influence, though. Britain does not control the English language and cannot exert any further influence through it.

Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.

My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).

An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.

Just remember that you can't define what is "fun".

> Obviously it is true in a single threaded system.

But only if you disable interrupts, right? Of course, if you are working that close to the hardware, it makes sense to include "no interrupts" in your definition of "single threaded".

> Note that garbage collection itself can have a switch, not involving disabling interrupts.

I don't understand this. If you get thrashed with interrupts then no switch will remove the overhead of the interrupt handler, so you'd need an upper bound on the time for that handler AND the frequency of hardware interrupts to achieve hard real-time.

Sorry for being ignorant of the basics, but how does the following work?

> However, seg-ments of code that are provably free of garbage collection > have deterministic timing and can satisfy hard timing con-straints, as they > are certainly not interrupted by garbage collection.

You are only ever "certainly not interrupted" if you turn off interrupts, which requires a high level of privileges. And not being interrupted still does not mean you have uncontended access to main memory or shared caches, which is a relevant factor for hard real-time. Nor do you have uncontended access to execution facilities (e.g. multipliers or floating-point ALUs), but at least for those you might be able to find an upper bound even for contended access.

I'm working on a similar thing, but due to various problems I encountered (auto-grading, scheduling, guidance, ...) I have, for now, concentrated on making a curated collection of problems / exercises. It's not yet a generator but rather "one of each kind of problem".

The idea is that _any_ user-facing tool, whether an app, worksheet generator or whatever, will need something like this for content, so I'm making this available for free and hoping for others to build on top of it.

I'm sticking to university-level stuff because I feel that school-level, especially math, is over-saturated already.

Technically, it is currently built as a React app, but that is mostly me sticking to tools that get out of my way. Generating PDFs or Anki files should be relatively straightforward.

https://github.com/janitza-mage/spot-problems-4

> Somehow everyone accepts

Everyone did accept that because when you needed information from a page that pulls that shit, you don't have a choice, and when you did have a choice, all the others did it too.

Nowadays people just ask ChatGPT for the information they need so they don't have to visit those awful sites anymore.

> That's just because corporations got greedy and made their apps suck.

It is true for me with Linux. I code for a living and I can't change anything because I can't even build most software -- the usual configure/make/make install runs into tons of compiler errors most of the time.

Loss of control is an issue. I'm curious if AI tools will change that though.

> HN, and firefox users, can never decide where the money should go or what the goals should be.

Without ever having dealt with this problem, it sounds like an embarrassingly solved problem, in the sense of: He who gives the money, decides where it goes.

The other half is to provide features that are actually detrimental if you don't want them as plug-ins / extensions / whatever. Pocket is an example for this. Firefox OS is not because it's not force-bundled with Firefox to begin with.

> They're switching to Chrome because they just don't care about being fucked up the ass, or worse, they secretly want to be.

The point where you stop trying to understand your users is the point where you start losing them.