moring

Self-inflicted by who?

A bit late, but I'll try...

This assumes that Gear Set Alley is near you. At >3km you'd go by car and the "meet people on the way" breaks down. At >100km you'd rather call them and miss the wrecking yards and other factories nearby.

In China, Gear Set Alley may easily be 1000km from you. Or it may be <3km from you, if you're lucky. The point is that China, taken as a whole, has no advantage over EU or US in geographical proximity. Certain regions may have that advantage, but that is totally possible in every country on earth (beyond a certain, very tiny minimum size).

China is huge in area too. You don't have one billion people right across the street. Anything that is across the street is, by definition, a localized thing involving far fewer people, which you can totally have in US+CA+EU too.

> But it’s hard to deny scale: the US is a populous country. But there are more than ONE BILLION more people in China.

This is true for the US alone, but US+Canada+EU is on the same order of magnitude, all of which prefer a more-than-zero-trust situation.

> The first thing in the decision tree is "do you send a crew?" and you're trading off the hard problem of teleoperating the thing (...)

Tele-operating a whole facility and more is something where you can make huge improvements down here on earth, before you even start into space, and even make a profit from it.

Two things that come to my mind:

1. Sometimes "lock-free" actually means using lower-level primitives that use locks internally but don't expose them, with fewer caveats than using them at a higher level. For example, compare-and-set instructions offered by CPUs, which may use bus locks internally but don't expose them to software.

2. Depending on the lower-level implementation, a simple lock may not be enough. For example, in a multi-CPU system with weaker cache coherency, a simple lock will not get rid of outdated copies of data (in caches, queues, ...). Here I write "simple" lock because some concepts of a lock, such as Java's "synchronized" statement, bundle the actual lock together with guaranteed cache synchronization, whether that happens in hardware or software.

I understood the criticism to be about describing it as open source when it isn't, i.e. that

"We say it's open source because we expect the reader to know that we're not telling the truth"

should be replaced by

"It's open source except for the BLE firmware blob, which can't be open source due to regulatory reasons."

To be fair, the article just repeated the claims made on the GitHub page for the SDK.

> The goal of closing duplicates promptly is to prevent them from being answered and enable that redirect. As a result, people who search for the question and find a duplicate, actually find the target instead.

Why would you want to prevent answers to a question, just because another unrelated question exists? Remember that the whole thread is not about actual duplicates, but about unrelated questions falsely marked as duplicates.

> ... because objectively the answers on the target answer their question ... > ... because of a failure to do the expected investigative work first ...

Almost everybody describing their experience with duplicates in this comment section tells the story of questions for which other questions have been found, linked from the supposedly-duplicate question, and described why the answers to that other question do NOT answer their own question.

The expected investigative work HAS been done; they explained why the other question is NOT a duplicate. The key point is that all of this has been ignored by the person closing the question.

Some rambling...

I always wonder if something like these undocumented opcodes could be used as a concept in more modern processors. Backend, transistors were a precious resource, and the result was those opcodes. Nowadays, instruction encoding space is more precious because of pressure on the instruction cache. Decoding performance might also be relevant.

The result of these thoughts is something I called "PISC", programmable instruction set computer, which basically means an unchanged back-end (something like RISC + vector) but a programmable decoder in front of it. So then different pieces of code could use different encodings, optimized for each case.

...which you get in RISC with subroutines + instruction cache, if you regard the CALL instructions as "encoded custom instructions", but not quite because CALLs waste a lot of bits, and you need additional instructions to pass arguments.

For pure RISC, all of this would at best take some pressure of the instruction cache, so probably not worth it. Might be more interestring for VLIW backends.

> because the point of the site is not to give you a personalized answer, but to build a reference where the questions are useful to everyone

This is a strawman. Marking two different questions as duplicates of each other has nothing to do with a personalized answer, and answering both would absolutely be useful to everyone because a subset of visitors will look for answers to one question, and another subset will be looking for answers to the other question.

To emphasize the difference: Personalized answers would be about having a single question and giving different answers to different audiences. This is not at all the same as having two different _questions_.

> "It's not a good idea for me to be trying to kill demons while I'm driving,"

Driving was the first thing that came to my mind. It's also dangerous to drive when tired, distracted, drunk, or one of a hundred other conditions. Yet somehow GTP is portrayed as the problem here when, in fact, driving a car is simply one of the most dangerous daily activities, even absurdly dangerous compared to other tasks.

The garbage that dominates the web has everything to do with centralization of power, and nothing with HTML vs JS. The former is a people problem and the latter is just tech.

The rest of the world has decided that the web is for applications at least as much as it is for documents.

I'm not arguing against a re-submission check. You'll need that anyway to prevent attackers from bypassing the browser and messing up your data.

But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.

The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.

Which part exactly?

Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.

Identifying the order using an ID in the URL is standard practice everywhere.

When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.

You have now stated that "those people should feel bad" for the second time. Personal attacks will hardly bring any change into this world. I'd instead suggest that you propose actual ways to solve the same problems that Javascript-based SPAs have solved which the non-JS web is still stuck with.

This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already.

The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.

The meaning of a value (data type in programming lingo) is not a preference because it is objective, not subjective. It depends on the cell being displayed, not on the viewer in front of the screen.

Offtopic, but do you know some good sources to read on that matter?

Layman's guess: Both were synced to the mains frequency.

Google doesn't "vaccuum up" anything. Every site indexed by Google is still available without using Google at all. They are _copying_ information, not moving or removing it.

When it comes to "patterns" and "anti-patterns", double standards are common.

For a teaching tool, you can get the best of both worlds by simply restricting RISC-V to fewer registers. Something like: "Write this in RISC-V assembly, but only use registers 0..3, and 31 for the return address."

If you are using a 3d engine that doesn't support actual isometric views, you can put the "iso" in isometric by moving the camera far away and at the same time zooming in on the object. This has the effect that all points of the object have roughly the same distance from the camera (compared to the huge distance you moved the camera away), so there is no perspective "shortening" of points farther away. This is especially important if you have rectangular wall segments that must fit together.

Note that while it seems that you need an account to download the audio files, this isn't actually the case. It's just the stupid UI on their web site that makes it look like that. If you find your way through that UI, you can get the audio files without logging in, and the pen announces itself to the host computer as a thumb drive -- just copy the files into the root directory.

At least that was the case 2-3 years ago.

Snail mail has never claimed that a history of all messages, with that history having a current state, exists. If you send a paper letter, you don't have it yourself anymore. You might keep a copy, but that's a _copy_, not the letter you sent.

Messenger apps claim that such a history exists by showing you, well, that history. In the same way, messengers claim that a message order exists, by showing you the messages in that order. If something exists, then it is independent of the viewer. So the assumption that the message order is the same for all viewers is founded in how two people look at physical objects.

Linux's security model doesn't become better just because everybody is doing it that way, and besides that, everybody is doing it because they are copying Linux.

Browser navigation (especially "open in new tab") and the back button were broken by global (server-side) session state long before SPAs were a thing. If anything, SPAs improved on that, because very few server-side web frameworks ever handled state well (Wicket being by favorite exception).

Why is the pool of goo under C21 when it is C22 that is flipped?

> In science nothing can be proven.

Asking here because it is mostly on-topic: This phrase is repeated often, but shouldn't it actually be, "In science, a hypothesis is either fundamentally verifiable or fundamentally falsifiable, but never both"? The two simply being the logical negation of each other.

"All swans are white" is fundamentally falsifiable (by seeing a black swan) but not verifiable, as you described.

"Black swans exist" is fundamentally verifiable (by seeing a black swan), but not falsifiable.