Posts by that one in the corner 5065 publicly visible posts • joined 9 Nov 2021
> How will starship work on the moon with no pad
You mean, just the top bit, not the entire Earth-launch stack? Just the teeny bit from the very tippy top? How will that ever manage without a pad?
> and no suppression system etc ?
Flame and sound suppression on the Moon? How *are* they going to stop the sound waves propagating across all that vacuum? Hmmmm....
> we'll go continually backwards
The BBC showed us the result already: The History Of The World Backwards.
"set in a world where time flows forwards, but history flows backwards"
> It seems to me that practically everything the brain does can be reduced to pattern matching.
You need to allow for pattern creation, that is the interesting bit. Pattern matching goes on, but the patterns have (not yet) been determined to be intrinsic. Reference the experiments with development in an environment lacking in vertical or horizontal stimuli and the subsequent inability to recognise those stimuli later on.
Neural plasticity is not about pattern recognition, it is about (among other things, let us not be too simplistic) creating the ability to admit or prune signals based upon apparent significance and then set up means to recognise patterns in those signals
It is a hard and unsung life, being an AI researcher.
They take a problem, one that hasn't been solved before by anything other than a human being (and even then, not by all humans). As soon as they find a way to emulate the behaviour, then publish how they did it, everyone is all "well, *that* is obvious, isn't; call this AI research, all you've done is just...".
That is just - an "obvious" way to prune search trees, a statistics prediction method, a pattern matching exercise (*and* you threw away most of the image to do it").
If it can be made to work, then it isn't an AI method any more, it is just common sense; you failed, try again (or not, depending upon how vitriolic the person feels).
> the report concluded
Amazing.
Such a novel and well-reasoned course of action, totally unlike the way any company has ever responded to anything else.
This conclusion alone means that the report is worth reading. How they manage to think this stuff up just boggles the mind.
> the cash was often packaged in a suspicious manner, including inside hidden children's books, concealed inside fake birthday or holiday presents, buried within puzzle pieces, or wrapped within multiple magazines
Those sound like all the ways I'd stuff a £20 or £50 (for special days) into an otherwise cheap and grotty gift for the youngsters when I had no idea what they really wanted for Christmas.
Maybe that explains the vans - we all know the drain is further down the road...
LLMs are very much flavour of the day, in much the same way as everyone talks about the latest fantastic bridge project (the press around the building of the Clifton Suspension Bridge was vast and colourful[1]). Meanwhile, there are many more people are being regularly served by all the hundreds (thousands?) of smaller footbridges and unglamourous overpasses put up in the same timescale. Similarly, for each honking great LLM there are numerically many more tasks that can be tackled with smaller ML models.[2]
If d-Matrix can avoid getting sucked totally into the vision of selling increasingly large systems to make a small number of big sales, before being overrun by the likes of nVidia, there should be a healthy long-term market for decent model-running chips that can be used in smaller products, that sell in larger numbers. Some alternatives/competition down there would be a Good Thing, especially if it can bring down prices and become well-known outside of specialist circles. Okay, they are still up against nVidia (Jetson) but that is put at the pricey end, leaving much room below where there is, what, the K210, anything else?[3]
[1] actually, mostly b&w 'cos the newspapers back then - look, figure of speech, ok!
[2] not really an amazing observation: so long as it is possible to build a smaller working X you will see more mini-X than maxi-X in use: consider JCBs and the cute little mini-diggers.
[3] genuine question, do you know of other devices in that range or lower that help run your smaller ML models? Actually available as hardware, not just drop-in IP for your next fab run?
Most of the other sites reporting this are claiming that the hash used was MD5, but there is a distinct lack of corroborating evidence (like, say, a statement from Freecycle).
For example,Tom's Guide is citing Bleeping Computer, and they are citing: "The stolen information includes usernames, User IDs, email addresses, and MD5-hashed passwords, with no other information exposed, according to Freecycle."
BUT that last link, the one to Freecycle? There is no mention of MD5 in there. Hmm.
Other sites are just repeating this, generally without even bothering to give a citation at all: TechRadar gives no direct citation for MD5, ditto GridinSoft, ditto SecureBlink.
From all this, the fact that The Register doesn't claim it was MD5 can be attributed to their being the only ones who felt like _checking_!
There may actually be a genuine reason to believe it was using MD5, but none of the above could be bothered to provide a citation and I can't be bothered to check any more "news" websites or "professional company" blogs - it is all too, too depressing.
> The report concludes by noting that respondents with more AI experience were less likely to associate AI with productivity gains and faster cycle times.
So we are left with a large pool of people without "AI experience"[1] who are being naively optimistic during the development phases (including code review etc as outlined in the article).
I was going to make snide comments about entrusting testing decisions to the AI, then, hey, at least they are doing *some* testing!
Say, are there are any stats about how long after deployment the major CVEs start to appear? Are we expecting a few house of cards to come falling down in 6 months? A year? Two?
[1] and, btw, no solid definition of what "AI experience" means - someone who has run Stable Diffusion at home? Or has followed some tutorials on training a simple Neural Net? Or has a research degree in AI from 2020 which only really covered NNs? Or has been involved since the 1980s and has a broad grasp on different AI models?
> the cyclic references described won't be GC'ed
Great strawman skills, deliberately only quoting half the sentence. Try responding to this quote:
>> the cyclic references described won't be GC'ed because there is still at least one active reference to that structure.
Yes, clever boy, GC will collect cyclic structures. That has been the case since the 1960s.
BUT so long as you have an ACTIVE reference, the GC "mark" phase will, correctly, NOT set that structure up to be reaped by the "collect" phase.
In fact, you even describe various *forms* of active reference (weak, strong)!
Bad phrasing on my part: the cyclic references described won't be GC'ed because there is still at least one active reference to that structure (the one being used to scan what was intended to be a list).
The actual problem being highlit is that the program is in an infinite loop, counting the entries, because creating - incorrectly - the cycle wasn't prevented by GC (as was implied by the post I replied to - i.e. the claim that GC solves all memory errors).
> Also during debuging!
Once more: Huh?
Using a template (a competent) C++ debugger will sshow you the code as you wrote it and let you step into and through the template, just as it will a non-templated function.
During debugging, if you are using a m4 as you suggest, then you are not even debugging the code as you wrote it (although you can, of course, step through the macro's expansion - in fact, you have no choice about that as the debugger can't see any "step over" point.
Oh, and templated code can be compiled as a series of functions, once per argument type (set of types) which are then just invoked as normal functions; macros are expanded in-line every single time. One of the reasons for templates was to get rid of the code bloat that macros can introduce (early examples of template usage generally being about implementing type-safe lists and other pointer-oriented fun, which end up being expanded many, many times!).
> You've got it backwards. You need libraries for the benefits of something like crates. (Centralised artefact control, version/dependency management, etc etc).
You do not need to invent yet another thing like crates to provide that functionality - it already exists elsewhere and has done for a long time. All you are doing with crates is re-inventing the wheel and needlessly tying it into one specific programming language.
> You're suggesting a language designed in the 21st century shouldn't learn any lessons from what went before?
I'm suggesting that those features you list are NOTHING WHATSOEVER TO DO WITH *A* PROGRAMMING LANGUAGE and should not be tied into one.
In the 21st Centrury you should be using an entire environment, which caters for multiple programming languages, to gain all those features.
An actual language, in the 21st Century, should have realised that it is *NOT* the centre of the entire universe and there are many projects that use multiple languages (making a suitable choice for each portion of the project). If the new language really, really tries to push its own version of "crates" then it is either totally unaware of what has gone before (it has itself failed to learn) *or* it is deliberately making it difficult to introduce itself into a non-trivial project.
> They don't cope admirably. Dependency resolution can be a right PITA. (We have a folder full of all the delphi libraries we use, and a very long include directive developers just end up pasting into their IDE settings.)
It is not the job of the language to deal with those things. You have pointed out that all those good, well-tried-and-tested were, to you, a PITA. That is because you had not bothered to look for any tooling to help you - which is why you so like crates, as it has been dropped into your lap without your bothering to do any work.
I work with multiple languages across multiple platforms (host and target) and yet find dependencies really quite easy to handle. How? I have a Build Environment[1] (currently, built upon Gnu Make with a couple of extra little tools) - I list the libraries that I want to *explicitly* use and the Build sorts out all the dependencies, complains if it can't be done, and pulls it all neatly together. Similarly, I have a working version control setup. So on and so forth. None of this setup favours anything over anything else.
[1] I keep thinking I ought to write this up and publish it, that would make it so much easier to point to real examples, but so many more fun thingss to do.
>> Java has less control, but not so much at the build end
> Java has the (old) maven and gradle,
I explicitly say *not* at the build end - and all you can do is talk about the build end? BTW, mentioning yet more tools that are targeting one language (Java) over anything else, making realistic non-trivial projects a PITA.
> Exactly, that's the problem, people use the tooling badly, because they're either lazy, uneducated, rushed or simply don't care.
Yes, yes, absolutely. Which is why I am surprised at you supporting the tight connection (that people are pushing) between Rust and crates, when, after all your education and time spent on looking at the tools already available and working.
> Don't confuse people using tools badly with bad tools.
Huh? I thought I'd been yapping on (and on and on) about the fact that there are perfectly good tools out there! And bemoaning that people don't want to use them (harping back to an earlier comment of mine: people - put non-trivial configuration files under version control, please!).
> "Programming languages which use garbage collection don't allow developers to write code in a way that's memory unsafe"
GC is to help you because you can not figure out when to release memory and keep running out of heap.
GC does *not* innately protect you against running off the end of a block you have hold of, or incorrectly sharing it with someone else. Or even creating cyclic references that can't be GC'ed and lock your program in an infinite loop, counting the elements in the supposed linear list. Or just putting your variables too close to global scope so you still run out of heap because nothing gets released and you are using 126GB of core.
A language with GC may choose to implement some mechanisms on top of GC that help with those problems, but that is not a given.
> Helper tool rustup makes it easy to keep it up-to-date and even have nightly in parallel, to try out proposed new features
That just adds to the feeling that using Rust is still building on shifting sands.
Note: I said "feeling" - glad to be proven wrong - but I like nice stable environments that I can keep repeatable.
C compatibility is a weird one nowadays. The best that can be said now is that you can write code that is compilable as both, but you have to prepared to grit your teeth and not do something that would be reflex if you stuck to one or the other. And then passing those fixes upstream ("but *why* are you compiling our nice C library as C++? Go away, you nutter!").
For the curious, I have little libraries that I use on MCUs (e.g. My Favourite Scheduler) and not all MCUs have (had?) a C++ compiler (only a few, but for some reason I got handed them) - worse, the C isn't likely to be up to the latest standard. So the libraries are built both ways, with comments reminding me not to "tidy up" this bit.
You seem to be unwilling to present your arguments clearly. Constructive criticism is of no interest to you.
Science is not haranguing.
Beauty contest? There is beauty in the simple & clear, from hypothesis to law. Much science has come from looking at "the state of things" and seeing clutter, not beauty: I give you planetary epicycles and raise you the unifying of the weak and electric forces.
Ye Gods.
So referring to C and C++ as one thing and claiming that C++ can't do something because C does!
It gives you absolutely no credence even if you do manage to make a reasonable statement about one or the other!
Gawd, no wonder everyone is getting fed up with you and you prattle about your Sappeur.
At least *try* to listen to criticism and take it on board if you really, honestly, think you have something of value to present: if you do then you surely want to present it in the best light, don't you?
Must go and find a book to read and step away from this.
And ... Breathe.
> You can just about use C++ if you ignore most of the language features.
"Just about"? Huh? If you can do it in C you can do it in C++, no " just about" involved.
Don't get dragged into those stupid "if you aren't using Modern C++[1] then you aren't using C++ properly" twaddle. If there is no advantage to using someone's favourite library then don't use it, same as any language in any situation. If you can write "neater, safer C" just by encapsulating struct members into private class members with well-defined member functions, then you are using C++ properly. If it doesn't help to use virtual functions, don't use them - that is using C++ properly. If the task doesn'tbenefit from using Boost, don't use Boost. There are even other implementations of smart pointers, lusts, trees etc than STL - if they fit better, use that library: STL just a.n.other library after all.
Not using a facility that does not help your requirements is not "ignoring language features", it is understanding the language features - whichever language - and using it appropriately.
[1] which just boils down to "whatever is trendy today" :-(
Sigh.
> Why C and C++ Cannot Be Memory Safe
If you are dragging C into this, you have either totally missed the point (C is entirely pragmatic about letting you shoot yourself in the foot, with good reasons, and nobody ever claims it will automagically stop you doing anything at all) or you know this and are going to talk about whether it is possible to write something that acts in a memory safe way (which it can, it will neither help nor hinder - you can code safely or you can code unsafely).
> The root cause are their type systems and established usage patterns.
Usage patterns are just that - patterns. They can, do and (especially for C++) have changed over time. You can not make any argument about capabilities of any system based upon usage patterns, especially not "it can never do X because I have so many examples of it not doing X".
Coca-cola can not be used for rehydration purposes because the only time I see it is to do that trick with Mentos[1].
Ooh, ooh: remember what I said before about "possible to write"? That is usage, so, yes, you *are* allowing for that to be taken into account! We win, you definitely *can* write safe code in C, and by extension, C++, you just have to use it right.
> Both C and C++ have no concept of "data only reachable by local thread" and "data reachable by many threads"
You really should stop going on about C - every time you mention now, you are only bolstering the case in its favour, as we all know what C claims to do or not.
With respect to C++: what you have just described is a "trait" and C++ has long allowed us (even before "trait" was used so often in STL to mean a fairly specific subset of the concept that someone will pull me up for "using the word") to use types to declare and define " stuff with traits" and then refuse to compile if you mix'n'match badly. Of course, you can decide to go outside those neatly set up declarations (e.g. use a.n.other library that does the same but with different words) and mess things up, but that is why we have coding guidelines - just the same as stopping you from dragging in yet another PDF parsing lubrary when we have one already).
> The C language would have to be extended in order to make all pointers Smart Pointers.
Deep sigh. The C language was modified to allow you to make all pointers smart pointers, it is called C++. Come on man, focus! Next you'll be having a go at Assembly!
> unsafe vector operations like ::std::vector::operator[]() are also a rich source of memory errors. Compilers should be able to report their use as errors.
You don't want anyone to use a specific method call from a specific library? JUST DELETE IT from your copy and the compiler will refuse to let you call it!
Etc etc. E.g. unsafe cast from int to pointer? Aside from "valid but oh how I wish it weren't" usage when dealing low-level stuff, use the C++ cast syntax and you can spot it a mile away. No whining that you can still write yucky C style casts, we have already established that you are allowing discussion of usage, good and bad.
****
Oh thank heavens, there is the call I was waiting for, I can stop just filling in time on a Sunday morning with this ineptly argued drivel from Frank. How I envy everyone else who didn't have to fill in a moment of "can't go and do anything more useful for the world".
****
[1] which is true, we love that trick - with Polos - but this is not a Coke Corner. Bad for the grass, though.
Agree with the low-level nature of C, that it does allow you to blow your foot off if you ask it to, but we are talking programming and if that isn't the place for pedantry - oops, I meant to say "precise usage" - what is? So...
> You can write 1970's style C code and compile it on a modern C++ compiler.
Can you?
C didn't allow the parameter type to be included in the argument list until C89 (formally - some implementations allowed it before then: most such changes get tried out by various implementations until they are codified in the standard).
In the 1970s you were listing the parameters to C functions in the argument list (well, duh) and only defining their type - if you could be bothered - between that and the function body.
Now, I'm nowhere near a compiler to verify this[1], but I'm pretty sure that the old-style argument list plus definitions will get rejected by your modern C++ compiler.
I have a sneaky suspicion there were a couple of other bits from the 70s that didn't transfer over as well (Stroustrup being compatible the C as it was implemented from the mid-80s). Anyone? There was a change in the namespaces for struct and typedef, but that would not lead to an incompatibility in this direction? Over to you.
[1] I feel sure I'll soon be corrected, go on, do your worst:
Nope.
Your blood is red due to the presence of oxygen-carrying haemoglobin, where the oxygen molecule[1] is weakly, and reversibly, bound to an iron ion at the centre of the protein. The iron is in an oxidation state ('cos it is an ion in the protein molecule), either +2 or +3 (the latter when weakly bound to the oxygen molecule) and this then leads to the colour change to really lovely bright red (unlike the purpley red stuff the phlebotomist takes from you).
But the iron is NOT in the form of iron oxide.
No, not even that funky Fe25O32 oxide[2]. We probably be making weird crunching soumds if it were (well, and weird choking sounds).
[1] note: an entire molecule, although whilst being carried it does carry a charge and is therefore a "superoxide ion" - gets weird down there, they didn't tell us this in O-level chemistry!
[2] which, I'll be honest, I didn't know about - or its similarly fun-loving sibling Fe13O19 - until I looked up Fe oxidation states, 'cos I couldn't remember which was ferrous or ferric[3]! Then again, I did use Wikipedia and haven't followed the citations, so...
[3] I know, call myself a programmer, talking about spinning rust, and I can't even remember that.
> However, it's possible to write safe sudoers rules
It is possible to write safe C code as well. Just trickier than perhaps we'd like (you have to concentrate on what you're doing, unlike wildcards and regexs in configs - oh, wait...)
> but you can't mitigate software bugs as easily
(Bangs head on table) Configuration is also software. Configuration that is complex enough to be called "rules" is non-trivial software and suffers all the ills of its more discussed cousin. To the version control system with you!
In other words: if you are going to put in the effort to make sudo (or anything else) safe, then it is equally important to make sure its configuration is safe.[1]
After all, there are many, many more people writing configs than there are writing the things that read them, and, let us be honest, they are not all as well-trained in the Dark Arts as the latter.
But, yes, I take your (probable) point that the sudo (or whatever) executable is copied verbatim across many more machines than a duff config[2] so a flaw in it will require all of those machines to be updated - oh, except that nowadays disseminating software updates is actually pretty easy...
[1] yeah, I know, if we change the config then everyone has to update and they'll hate us for it, etc etc
[2] well, except for that duff example someone published on StackExchange...
True, you can switch off the Ada runtime checks (for very good, pragmatic reasons - aka 1980 computers, let alone the ones you could fit into anything mobile).
But there is a solid argument, when looking at a program, that you take into account its build system (its entire build environment) if you are actually concerned about the safety and security of the running system.
If you build spec states - and enforces (via your build system) - that the runtime checks that Ada defines are to be enabled, then they *are* present and can be relied upon as much as any other languages: any attempts by those naughty programmes to get around them (deliberately or not) will be caught.
The Ada spec defines those checks as part of the language, your setup insists that the entire spec is in play.
Not to say that it isn't better to have such checks - or, more accurately, the locations where such checks are abandoned - be visible in the text of the sources that more of your programmers are actually reading (please, learn about your build systems as well).
> ADA ... It's merely an amalgamation of C / C++ / COBOL and Java.
Ada[1] appeared in 1980
C++ appeared in the 1983-1985 timeframe (from cfront to The Book)
Java appeared in 1995
Ada was influenced more by Pascal/Modula than anything else.
Not clear what you think Ada took from COBOL - certainly not MODIFY!
> ADA isn't memory safe by any standard
Which standards are you measuring by? It doesn't support (void *) style trickery, it provides all the run-time checks against array bounds, it even allows for garbage collection (but AFAIK practical implementations don't provide it). You can use memory pools to control allocation at the level of different structs (to lapse into a C'ism) or finer.
And, unlike Rust, there is a specification for Ada - and you can even get it for free (unlike other languages, unbelievably: really, ISO?).
[1] note - only uses one uppercase letter; why do people insist on ALL CAPS when referring to Ada, Lua, Pascal - even Fortran gave up the last extra capital a long while back! But he managed to get Java correct.
Huh?
You do not need to invent something like "crates" to get all the benefits of libraries (and, yes, we *know* libraries exist for reuse, that is the only reason they exist for).
> Still no difference between C, C++, Rust, Java, TypeScript or Sappeur.
You do know that libraries predate C, let alone C++? And even C++ predates things like yum and apt-get?
Rust can not be used (except possibly trivially) without getting involved in crates - C/C++, Pascal, Modula2, Fortran all coped admirably without even yum, let alone apt-get. And still (can) do - one of their great advantages is that you get to determine what level of control you exercise (hopefully total control, being able to build all of the components of your product from locally held assets pulled from a specific version control tag, but, hey, each to their own).
Java has less control, but not so much at the build end (don't get me started on Java run times on User machines!).
Typescript - haven't used it, so I'll talk about JavaScript, the thing it compiles to IIRC: you do not *need* to use npm to use Javascript. People do, far too much. That is the problem. You can use JavaScript (and probably TypeScript) without uncontrolled library usage.
Sappeur - who gives a damn?
PS:
PDF parsing as a "basic" library?
Haven't seen that Netflix example (may try later) but the near-as-makes-no-odds real-time transcription at last year's EMFCamp was impressive. I assumed (ok, yes, never do that) that was machine transcription, given the nature of that camp.
But even if you have a few boners in the transcript, at that price it is still good value.
> That'll start to add up if they want recordings/transcriptions of every meeting for regulatory recording keeping purposes.
These are brand new regs, are they?
Otherwise, how are they complying already at a rate of 5.4 cents a minute (assuming you get charged to record in order to transcribe)? That sounds like an absolute bargain for transcriptions![1]
[1] random "first page I found": The average price charged by transcription businesses in the UK for standard two speaker interviews, conversations or discussions is about 90p to £1.50 per minute, although for a traditional transcription business this price will very much depend on the turnaround time. Recordings for 3 or more speakers can be considerably higher as they are much harder to transcribe.
Idea for app: put up a price ticker on the meeting room big screen, which shows the current MS Teams cost so far - and the name of the manager whose budget it is coming from.
Oh, and a variant that shows the total being charged to the company account for *all* the meetings in progress and monthly total. For use by the CFO.
Goal: reduce the length of meetings[1] and increase employee productivity.
[1] oh, sometimes I really crack myself up; as if anything could ever shorten meetings! Ah me. They'll be taking it out of the biscuit fund instead.
Big difference is that CGI came on-stream very, very slowly over decades: we got some really ropey stuff that was only used because it was still better than using a black backdrop with holes for starfields. As it got better, everyone could adjust. It helped that a lot of it was laughable - e.g. the animated acrobatics in that daft Van Helsing movie.
Plus acting against a real set still has advantages of quality, knowing where everything is without having to keep it all imagined - or just not corpsing when trying to keep an eyeline with a tennis ball on a stick (blooper reels can be an education in themselves!).
Actors have adjusted to the use of Serkis Folk and seeing themselves replaced by CGI, but they still did the acting.
But this step is a short, sharp, shock as they get snipped out of the process entirely.
The only "word processing"[1] I need to do nowadays (thankfully) is the occasional one or two page letter for hard copy - WordPad allows that to be written easily & without having to wait for LibreOffice to load up (well, that is what it feels like). And it is a lot less cluttered (I don't need to use all that WordPad can do, let alone LO!).
Very glad to have seen the URL to the MS github, above; hope I don't forget to snarf a copy of that!
Still need to keep LO around for all those folks who send out weird format files in huge emails...
[1] proper big documents - like documentation - get written in plain-text with markup, pick whichever is suitable (Doxygen, Markdown, LaTeX, weird home-grown macro language thing), kept under version control and run off as a PDF if anyone wants a collated printable copy.
Given how the meter needle is deliberately built without any damping mechanism at all, it will react to any old noise strong enough[1] to be picked up - which is one of the classical[2] ways of making an RNG.
[1] funny how everyone in the Sea Org is suddenly "unclean"[3] whenever the diesel generator kicks in
[2] now begins the discussion about how biassed such an RNG will be, it isn't _really_ random, not good enough to be included within /dev/rnd...
[3] unclean, unthetan, unclear, unmutual - who knows.
> not one of England's surviving architecturally impressive barns was a tithe barn
According to <a href="http://www.horburyhistory.org/Tithe-Barn-Street/>the local history site</a> that tithe barn was part-converted to housing in/after 1850 and the remaining half burnt down in 1904, so looks like everybody wins this round.
If these people had any sense[1] then they'd only ever call their woo stuff like "Biodynamic Sequentials" or "Bio-Syncreticism"[2] or "Brisingamen Stones"[3].
Then whenever anyone says "that is all just BS" they can reply "yes, I'm glad you know so much about our beliefs already, may I interest you in a pamphlet?".
[1] yes, I know, irony overload
[2] "bio" is a very useful prefix for this
[3] nope, bored of "bio" now
> E-meters have software now
Well, even back in 2018 they had LCD digital readouts so they needed something to put some digits up on them.
Just look at all those knobs!
Hang on, did you take a set of Excel sheets and convert them once, then keep using them for many moons?
Or are you actually taking new Excel sheets continually, then compiling them down into WASM? Which is certainly what it sounds like you are doing.
That is, is what you are working on a compiler for Excel that targets WASM? Because, if so, that it a different use-case than most of the other discussions here and, with the sole exception of the "changing the logic in an iOS program" [1] prompts all sorts of questions about "Why WASM?" Like: cool the WASM runs in many places, but if your compiler used another backend it could be generating native code for each anyway (more than one method for that these days).
But this all seems even further removed from the browser; the W in WASM stands for - Wibble!
[1] which I had understood to be a no-no and a reason they blocked a slew of scripting languages from the app store? Correct, me, please, I'm not an iOS person, just a bystander.
> The purpose of WASM is to allow other languages (like C++ and RUST) to run in the browser environment.
And yet the article is all about everything EXCEPT running in a browser!
It is all about using a VM that you can run in your VMs, um, instead of using Docker? Hang on, why not just take an existing CPU instruction set (say, Arm) and an existing system level API (say, Linux) and run those? What is so great about WASM in this respect? Oh, Arm is copyright & licenced? Ok, base it on RISC-V[1]! Oh, WASM is smaller (or less convoluted than all the RISC-V variants)? Well, just you wait until WASM ver 6 when we add the third GPU emulation opcodes into it[2]!
You know, we are running so much WASM ver 8 code now, I bet we could run it direct on silicon, but we'd need to add a supervisor mode of course, and this bit so we can support a proper UEFI boot.
Yes, indeed, this is all about the browser.
[1] RISC-V got autocorrected to "rose-coloured" - how lovely; glad it wasn't "rose-tinted"!
[2] you know, the ones that let us recognise we can JIT this direct to an AMD GPU, because the ver 5 only mapped to CUDA.
Sarcasm Overload, Baby!
Unless you mean that you can still run all the compiled Java, just so long as you have kept a copy of every single (just to be sure - you did give four 9s) Java Runtime, each one installed on its own machine (let you use VMs, to be kind) so that you have a fighting chance of finding one that will run your code and all of its dependencies?
