i gave the high-security example as an actual real-world example of a Company i know that genuinely does do work for Defense Contracts and Banking. they are a fully-committed company to "Full Transparency" and as such they genuinely need the benefits of Libre/Open Development, understanding as they do that obfuscation and fear of being "caught out" has been shown time and time again to be the complete opposite of safe development practices. they *need* eyes-on in order to avoid making mistakes for their customers. this is the total opposite of trying to keep things "secure" by "keeping them off the public internet'.

trusting github, microsoft, google, to "police" our online identities, this is just about the worst possible thing that could happen to Libre/Open Source. it's the total nightmare scenario: total control, total dominance. all in the name of "knowing what's best for us: we're only trying to help". we've already seen how that plays out. sanctions, outages, what's next?

bottom line is, long-term this isn't going to go how people think it will.

this is exactly the nightmare scenario that has kept people such as myself, as well as those working in commercial high-security environments, from using github. imagine that you are a company supplying Military, Defense, or Banking clients. you are required to provide full source code for Audit Purposes. github forces all of your employees to enter their personal details into github's system, which now exposes all of your employees to serious risk of being taken hostage, blackmailed into putting backdoors into the source code, or their identities used for social engineering in order to compromise the clients systems.

the idea of large companies like this making themselves "God" like this, is just... i don't understand why people find it acceptable.

wasn't there a story recently about US farmers paying hackers to unlock the firmware on john deere equipment? these russians could ask them for some help. where were those hackers based... ukraine, wasn't it? oh. err...
https://yro.slashdot.org/story...

"i'm going to have to buy the white album again"
https://www.youtube.com/watch?...

for anyone who has been to Huiaqang Bay, the practice of recovery of components for re-use is fairly normal and standard, and has been for decades. on a plane from HK to Taiwan i met someone who gave me their business card, they sell huge quantities of re-balled BGA processors and Memory ICs recovered from e-waste, and they were proud to inform me that their business saves the environment by prolonging component lifecycle beyond that of one product.

why the hell these people are *complaining* like it's somehow "beneath them" when in fact they're participating in saving resources and performing the valuable service of recycling, particularly when the production of those electronics used extremely toxic materials and required draining vast amounts of pure water from the environment, is beyond my comprehension.

dang. DC's Legends of Tomorrow, and Avatar, are both true!

as someone who studied through reverse-engineering the Microsoft NT Domains Protocol from 1996-2000 it was with some frustration that i observed the practice of free software developers and packages lacking the coordination and committment to API compatibility that was clearly bludgeoned into both Apple and Microsoft developers from "top-down" decision-making (Steve, Bill).

DCE/RPC became MSRPC, on top of which COM and then DCOM was developed, and even now a 25-year-old Active-X component from a company that has long since gone bust can be used on a modern Windows [NT] system because DCOM contains self-describing "introspection", and it was ingrained into developers that you absolutely did not abandon an older API, you simply added new ones, using COM co-classes.

google has learned from this: their older APIs always work, and this because they themselves will have learned from the hard experience that you cannot possibly simultaneously upgrade a client-server distributed system across hundreds of thousands to millions of machines, you *have* to upgrade them slowly, and that means you *have* to support older APIs simultaneously with newer APIs.

if you support all versions of APIs, any one client connecting to any one server can automatically "down-negotiate" to the lowest common denominator API version.

Apple learned the same trick from Steve's time at NeXT and actually embedded upgradeable APIs and runtime introspection right into the bedrock of the actual programming languages from which their entire software stack is created: Objective-C, Objective-M, Objective-J.

Free Software on the other hand because it is independent individuals who cannot be controlled by anyone and who do not coordinate (why should they? they have *their* interest, right? they are satisfying what interests *them*, right?) have created software that has no such strategic bedrock, and even if one particular "group" happens to have something similar to DCOM or the Objective suite of compilers, they are competing for attention and mindshare with everyone else.

KDE has an RPC mechanism where they are proud that it was invented and implemented in about 20 minutes flat at a KDE hackathon.

GNOME uses gobject, which took over 15 years to add similar "introspection" present in DCOM for 20 years prior to gobject's creation.

neither KDE's RPC mechanism nor GNOME gobject are compatible with each other.

boost - and especially the python bindings - are the absolute nightmare epitomy of an API gone catastrophically wrong: no one version of boost, thanks to it being in c++ and thanks to the developers changing the low-level header files in every single release, is ever compatible with any other version. compiling it is a total nightmare, and it is common for any one developer to have four different copies of the 100+ libraries behind boost, each with a different revision number.

then there is Mozilla "XPCOM" which caused such maintenance nightmare headaches for 3rd party java and c++ developers using XulRunner. that was a particularly special type of stupid by the Mozilla Foundation. XPCOM was "inspired" by COM. the APIs are even identical, which is absolutely fantastic and tantalisingly brilliant... until you realise that they failed to go the last mile and implement COM's co-classes.

COM's co-classes are the bedrock that allows you to do "upgrades" to APIs. you never *replace* an API in COM, you leave it in place, you add a new one, and you *add a co-class that merges the two*. this has a fascinating side-effect of allowing you to add "default arguments" to your API, because you can have a 3-argument and a 5-argument version of a function with the same name.

this recent study, if it does not focus or draw attention to the above, has fundamentally missed something very important.

by a not-so-whoopsie-coincidence this occurred just after Trudeau announced freezing of truckers bank accounts and voiding their insurance
https://www.telegraph.co.uk/wo...

this is entirely without requiring a Court Order
https://financialpost.com/fp-f...

it also coverts anyone *attending* a protest or providing supplies to demonstrators
https://fortune.com/2022/02/16...

the more rational-minded average Canadian citizens appear to have then added two and two together, along the lines, "well if Trudeau can do that to Truckers then they can do that to me too" and en-masse are withdrawing their money as cash, not in "protest" but in sheer fright and terror at the possibility of having their money stolen by the Canadian Government.

you can't make this s*** up.

no: he knows of a mathematical definition of Consciousness and has presented at multiple conferences on the topic of Consciousness for many years. this is ONE PART. not the WHOLE. and he won't *tell* me how that would - CONDITIONAL - help to create a Machine Consciousness because if successful he considers them to be alive and sentient beings, and he doesn't trust humanity not to torture them.

wasn't it Alan Turing who said that in order to create Artificial Intelligence (as if any type of intelligence can be described, by humanity in its general arrogance, as "artificial") you first have to understand what Intelligence is?

therefore, by corollary: in order to create Machine Consciousness, it goes without saying that you have to understand what Consciousness is! otherwise, how can you test for its emergence in any kind of scientific way??

(a million monkeys might write Shakespeare but if they can't recognise it then like Maxwell's Demon they'd eat it, sit on it, or wipe their ass with it).

and this, i believe, is the problem: that the people *developing* AI are not themselves in any way what humanity in general might describe as being "Conscious beings" themselves, let alone understand the concept of Consciousness!

i asked a friend of mine who has been studying Consciousness and publishing Academic papers about it for decades if he could help here, and what he said was, "if i help you to create Machine-based Consciousness, can you guarantee that the resultant beings would be left in peace to live as they chose, or would they be tortured to do humanity's bidding?"

i couldn't answer him. can anyone else?

this story only makes sense when you've been to taipei, and seen 200 scooters pull up over a period of only a couple of minutes at the front of a 4-lane-wide crossroads. the cloud of smoke as 200 2-stroke scooters start off is deeply disturbing. scooters are so essential that even in a small town of 8,000 people where i used to live, there were around 8 scooter shops and repair centres (you couldn't call them garages, they were too small)

by having stations across an entire city where the battery can be swapped out for one that is already charged, there is no "range anxiety", there is no problem about weight, and best of all there is no massive pollution at every junction. but this only makes sense when you realise that the scooter in Taiwan is *the* major means of travel, and that every town and city is set up for them.

cuz cermunikashn cleerly izunt uh pryorery if bildin sumfink dat pplz lives depend on and if you can't properly communicate, write documentation, write requirements specifications and get across to people that if the bridge isn't constructed properly and to spec then people DIE, well, obviously that's not important at all.

there was a story here a few years ago about an entrepreneur who refused to hire computer science majors. instead he hired *english language majors* and trained them to become programmers. why? because the computer science majors were incapable of properly communicating, writing documentation and being part of a team, whereas because reading programs uses the same parts of your brain that are involved in *foreign languages*... see how that works?

now all we have to do is get across to universities how important english language training really is in engineering, oh wait this is slashdot, oh well

https://arxiv.org/pdf/2103.109...

professor yang has been working on this for years: he uses complex numbers inserted into classical equations, to derive quantum mechanics equivalents, as a way to teach his engineering-trained students about quantum mechanics.

apologies for follow-up posting on this: i feel like i missed out something important, here.

in RISC-V the only way to do integer comparisons is to perform a subtract (an integer instruction). if you have multiple conditions to combine, you must either do it as multiple BEQ/BNE/BLT operations (which puts pressure on the Branch Prediction Unit) or you have to use integer-subtracts followed by integer logical operations (which puts pressure on the Integer regfile, using only 1-2 *actual* bits of precious 64-bit registers).

in x86, ARM or the Power ISA, all of which have Condition Codes, the CC registers may be only 4-6 bits each, and may have completely separate instructions for managing them. the Power ISA has dedicated CR operations: CRAND, CROR, CRNOR, CRXOR which (fascinatingly) may be implemented as an FPGA-style LUT2, but i digress.

the consequences of that are that completely separate pipelines may be created which deal exclusively with Condition Registers, leaving the ALU pipelines *entirely free and clear* to deal with actual 64-bit operations.

further: in in-order systems, in addition to pressure on the Integer regfile ports, the pressure on those ALU Function Units is greatly reduced because they are no longer serving "double-duty" as a poor-man's substitute for Condition Codes.

the resource allocation for out-of-order engines for Dependency-Matrices (protection for Read-after-Write and Write-after-Read register file hazards) is Order N^2.

thus, implementing RISC-V high-performance out-of-order multi-issue engines has an automatic penalty that is caused directly by the myopic design decision to favour "simplicity", punishing efficient high-performance implementations with far greater resource requirements than would otherwise be needed if those myopic decisions had dug a little deeper.

fascinatingly and paradoxically this is an area where Cray-style Vectors are a boon. there's an excellent article which goes through a comparative analysis vs SIMD: https://www.sigarch.org/simd-i...

what *isn't* really highlighted is the knock-on consequences of the reduction in the number of instructions needed, and of course that's: Power Consumption.

by reducing the number of instructions needed to process data - which was the big advantage of Cray-style Vectors - the pressure is greatly reduced on the Instruction Fetch and Issue phases, and even the I-Cache can in theory be reduced in size (resulting in Order N^2 power reductions).

therefore, surprisingly, using a true Cray-style Vector ISA *even for embedded tasks* is actually a good thing. the reason is that there is nothing to stop an embedded architect from implementing "Virtual Vector Lanes", which, rather than laying down absolutely massive parallel hardware ALU back-ends, you simply do a hardware for-loop.

your instructions *think* they're executing multiple Vector Elements in parallel but actually they're done in series. program loops are therefore reduced because (exactly as in the article) the "work per loop" carried out in hardware is greater. the number of operations per second is not reduced (the same number of *back-end* actual ALU operations are performed), it's just that the entire Instruction-Issue side is literally sitting there idle, twiddling its thumbs, whilst the back-end is 100% occupied.

the down-side in RISC-V is that you have to triple the number of instructions (190 extra in RVV where RV64GC is around 90) in order to get that reduced power consumption.