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.

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

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

> 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.

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.

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".

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.

> 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.

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

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.

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.

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.

Is conning a seller really worth it for a potential buyer? Details will help an expert find the flaw, but it still takes lots of work, and there is the risk of not finding it (and the seller will be careful next time).

> And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.

They also have the money to just buy an exploit.

> The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.

I'd imagine the skills needed to get paid from ransomware victims without getting caught to be very different from the skills needed to find a vulnerability.