only in embedded products where compatibility and interoperability
is completely unimportant. a classic example is the Trinamic Stepper
Motor Driver ICs that adopted such an early version of RISC-V that
the standard hadn't even been ratified yet, but it in absolutely no way
mattered because the compilers worked, binutils worked, they could
*PRIVATELY* make as many custom modifications as they wanted,
shove the binary into metal masks and absolutely nobody would know.

in this situation (private, custom, secretive, proprietary usage) you
are absolutely right: there is absolutely no problem whatsoever.

if you try that with the custom opcode space and you're publishing
binaries that are expected to be interoperable (native Android apps for
example) then you're absolutely screwed. or, more to the point, you've
screwed the custom opcode space for absolutely everyone else: you've
basically "de-facto dominated" those opcodes because they're no longer
available for anyone else:

* anyone (any silicon) *not* implementing those custom opcodes will have
    binaries that are incompatible.
* anyone implementing OTHER OPERATIONS using those exact same
    custom opcodes (and also publishing public binaries) is in real serious
    trouble.
* where it gets even more serious is when a programmer wants *BOTH*
    conflicting - public - custom opcodes in the same binary (because the
    features of the publc custom opcodes are so important to speed or
    power consumption that they're absolutely necessary to the software).

it's a total mess in other words, that needed to be planned for well in advance:
to provide proper conflict resolution. and that simply hasn't been done.
there is an train-wreck coming, and it's going to take several more years
for that train-wreck to occur, but it is unfortunately already unstoppable.

no, really, it isn't. read this - it's the best independent analysis i've encountered which
outlines the problem:
https://news.ycombinator.com/i...
summary: the over-simplification of the RISC-V ISA comes with a price:
larger binary size and greater hardware complexity to compensate. RISC-V
advocates claim that "Compressed" compensates compared to other ISAs
(it doesn't: adrian_b explains why).

what *will* take several years is for "everyone expecting optimal-performance
hardware to turn up" to realise what that person (adrian_b) is talking about.
what's actually happening is that large organisations betting on RISC-V in
high-performance are being backed with extremely large grants and large
investment, only to find that RISC-V cannot deliver. the problem is that the
committment in terms of funding and time to get to an actual ASIC is so large
that they can't back out.

to illustrate: the only reason that the Alibaba Group's Xiantue910 could claim
better performance than a high-performance ARM Cortex A73 was because
they added FIFTY PERCENT more Custom (rogue) instructions to the RISC-V
ISA.

oink.

by complete contrast, in the *low-end* embedded arena where the binary
size is immaterial vs the cost of licensing an ARM Cortex M0/3/4, RISC-V
is taking the world by storm, because zero royalties is unbeatable.

what i heard from someone who has experience with infections is that the human body immune system goes into such complete fanatical overdrive when first detecting any infection that any *new* infection is obliterated. what Richard Webby is saying seems to concur with that [simplistic] perspective.
what the person also told me is, if you *do* get more than one infection at a time, it's because you're dying (basically). your body - including your entire immune system - is shutting down.

the bit that's new to me is that Foxman's team appears to be saying that the actual *viruses themselves* tend to clobber other viruses, which is really very interesting.

there's more to it: microsoft have been merging login accounts by buying up various *other* companies and merging them - without consent - into a single unified "microsoft passport" system. which is not appropriate in the first place, but is even less appropriate in the context where someone (myself) registered the *exact same email address* on a personal service (game) *and a business service* (skype) both of which got bought.

this may not sound particularly relevant until you appreciate that i registered the personal service (game) on my daughter's behalf (so she could play minecraft). now all of a sudden she potentially has access to my *business* confidential login because microsoft merged the accounts without my consent.

Researchers from The Netherlands, i.e. Dutch researchers.....
(it may be the only exception to the rule, but there is just one exception where the adjective and name of the country do not line up).

The problem is that the electromagnetic spectrum is quite wide. If you know they will have a scanner that scans including the 433 MHz band and the 2.4GHz band, you can prepare a device that works at 147MHz (there is an amateur band there somewhere) or 5GHz (you know modern wifi).

Whatever the scanners scan for you can find a way around it.

With the public wanting to follow the game "live" the state of the game is available for everybody. So the only thing is to get the "suggested move" in to the player. Scanning the players is no good, the transmitter is outside. Thus any "ambient radiation" may be the cheater's partner transmitting the winning move.

The only way to fix this is to delay the "live" broadcast of the game by say 2*average length of move (or more). Now the cheater would have to make the board position known outside their room where they are playing. That's much easier to detect.

that'll help them overcome the performance losses caused by speculative mitigation in the linux kernel, then, eh?

this was tried 20 years ago: the results were absolutely disastrous. some Westerners interfered and provided fertiliser, machines, and western genetic-base Maize.

year 1: great crops.

year 2: great crops throughout the area which meant that native maize was not grown and discarded.

year 3: drought. the Western-based maize crops failed. absolutely nobody got *any* food.

the problem it turned out was that the genetically-diverse maize, which didn't grow very well *in general* contained genetic resistance to drought, genetic resistance to local pests, genetic resistance to local flooding, the genetic-based ability to grow without needing fertiliser even in poor soil, and so on.

thus whilst they got shit yields compared to Western farming practices *at least they got something every year*

it was i think about a decade before the country recovered due to every single damn farmer in the country having thrown away the *local* maize "because financial pressure".

that the Gates Foundation does not know their history and the damage caused by interference of this type, does not surprise me in the least. i'm glad they're not getting anywhere because they shouldn't fucking well be intefering in the local affairs of another country, forgetting the millenia of genetic diversity that gives that country food in the first place.

"Dropping 32-bit support on the Pixel Tablet will likely reduce RAM usage, but the tablet wonâ(TM)t be able to run 32-bit applications,"

the size of binaries increases and RAM usage *increases* by recompiling as 64-bit, due to integers and memory pointers being twice as long as they were in a 32-bit program. it is also well-known that power consumption also goes up, by around 10-15%, mostly due to the increased size of L1 cache needed to cater for the larger binary size. if you look at comparative 32-bit ARM Cortex cores they have 64k L1 cache, but 64-bit ARM Cortex cores all come with 96k.

Western launches are held to a standard that must ensure a chance of less than 1E-6 or something that someone dies. The chinese either estimate the chances of someone getting hurt by this falling rocket low enough to satisfy that, or they are using a slightly different number.

It is not black and white. If a western rocket scientist says he thinks it is unsafe, that means he thinks the chances of someone getting hurt is larger than that 1 in a million. Still the chances are pretty slim that anybody is going to get hurt by this. I'm a bit fed up with everybody shouting it is super dangerous.

well, they should not have sent letters to the Chinese Government, pissing them off so badly that they're ordering suppliers to cease using Intel parts. yes, all Intel parts. that has a cascade-effect where S.E. Asia OEMs start to follow that lead.

this came up in OPF discussions, as well, particularly LibreBMC which has of course to choose a suitable license for both hardware and software. it turns out that google's "favourite" license - Apache2 - is missing wording that provides *hardware* patent rights to be waived.

in other words, what these non-patent-waiving licenses are saying is: "yeah you can use the code TOTALLY for free... oh but we reserve the right to sue the shit out of you for patent infringment if you do so"

it's much worse than that. i've posted on this before. you have to understand the semiconductor manufacturing process. automotive grade is unique:

1) the cost pressure is much higher
2) the speed of components (max clock rate) is far lower. even 16 mhz is 16x faster than actually needed
3) the current and voltage is 100 to 1,000 times greater than those used by ICs used in the average consumer product. 50V and 10A to drive a Fuel injector.
4) the usage conditions are unbelievably hostile: sustained ambient temperatures of 110C are normal and the EMI would fry a consumer-grade IC in seconds.

therefore it is not only laughable to expect to use consumer-grade 45nm Foundry geometries or lower, it is just flat-out stupid. in 3D printing terms it would be like using a 0.2mm nozzle to 3D print a 10ft x 30ft x 5ft object: stupid.

it should therefore come as no surprise to learn that automotive grade ICs are typically manuactured in 250 nm. no consumer-grade IC goes anywhere near this dumb-sounding geometry. it should also come as no surprise that the layer stack is also completely different.

only a handful of Foundries in the world have - had - the capability to manufacture 250 nm. the masks (made of glass, stored at the Foundry) were not allowed out of the Foundry, even though they were paid for by the IC designer. they wouldn't fit a competitor's Foundry anyway.

and then shit happened. orders stopped.

now, one crucial aspect of Foundry equipment is: you can't ever stop. you cannot let it cool down. if a Foundry has no orders, which they hate, they run blank wafers to keep the equipment up to temperature.

what do you think happened when 40-year-old equipment suddenly received no orders for 18 months?

they scrapped it, didn't they?

all these morons had to do was keep on ordering parts, even just a trickle. except, i don't know if you're aware of "Factoring"? letters of credit? with all the big car manufacturers ceasing orders, all the Factoring also ceased. so none of the suppliers could guarantee that they would be paid, so of course they stopped manufacturing.

bottom line is: it is the cessation of credit facilities (Letters of Credit) from the AAA+ rated companies like Ford, GM, Chrysler, that is actually the underlying cause of the collapse. the rest is just consequences.

the same logic that applies to debian's distribution of the existing rust compiler would also make distribution of gcc violate the Trademark owned by the Mozilla Foundation.
https://bugs.debian.org/cgi-bi...

until they're dead.
https://www.dailymail.co.uk/ne...