Posts by bazza

Re: Nothing valuable appears to be lost doing this.

Most of the times I’ve updated my Ubuntu server installations there’s been a fresh shiny kernel to reboot into anyway, and a manual reboot is required anyway. That does rather negate the value of having a tool that tries to work out whether anything else needs a reboot.

Re: 1.5x slower....

Yep, and there's some CS types called for the abandonment of SMP. Attempting to make a "faked" SMP environment on today's chips is what's lead to such silicon flaws.

Rust is interesting because - with it's total knowledge of what is accessing what memory - is very well suited to CSP environments. If implemented in hardware (remember Transputers?) are far less likely to have flaws like Meltdown and Spectre. With Rust, passing data from function to function whilst having knowledge of ownership could be used to transfer data over CSP channels from CSP node to CSP node. I don't know if Rust actually does that at present, but it could. I know there's CSP implementations for Rust, just like Go.

So Rust might be a half-way house between SMP code and CSP code, in that it "feels" like you're writing for SMP, but actually underneath it could all be running on CSP hardware, and you'd never know the difference.

Which indeed is Rust, or another.

Thing is, C-like languages - to be rendered "safe", or at least "known behaviour" - require quite extensive runtimes, particularly if you've got separate threads sharing data. And that's how you end up with things like C#, Java, etc. I've not looked at either TopC or Fil-C, but I find it difficult to believe that they achieve complete memory safety when there's threads involved (unless they too have a heavy weight see-everything runtime). Taking away 90% of mistakes is a start, but I fear that the remaining 10% would be the really tough bugs to find, and also the most important ones to find.

I can see another advantage. C to Rust conversion is said to be tricky, I suspect because first you have to fix all the mistakes in the C/C++ before it's in a Rust-like shape. C/C++ compilers that - at run time - can give you error output akin to "ah well, you've got this wrong here" could serve a useful purpose in allowing code to be bashed into better shape in a language which is familiar, rather than doing so whilst also translating to a language that is not.

General Dilemna

Rust has certainly thrown in a curve ball. For the first time in decades, there is a truly plausible and arguably superior alternative to C / C++. Unless Rust actually dies, the arguments against migrating to it are going to get thinner and thinner. For large C/C++ projects, it's a horrid choice between sticking with what's known for an easy life and risk project death (as C/C++ gets abandoned) but hoping for the best, or bighting the bullet now and cracking on with converting, or (even harder) both.

This was always going to happen at some point of other in the history of computing. Indeed, it's already happened; once, there were assembler programmers convinced that assembler would live on forever in, say, OS development, hot apps. C soon wiped that out. If we're to draw a lesson from history at all, it's that C / C++ is going to lose and probably faster than anyone thinks.

Or just try another OS / C allocator pairing.

I've seen code (GNU Radio) run just fine on Linux, but the same thing compiled and run on FreeBSD segfaulted with a memory leak. No one was ever going to find that bug on Linux...

Ideally, OSes / libc's would offer two modes; hyper-optimised, minimum OS interaction, fastest possible allocation, or super-defensive, lots of space between allocations, all freed memory immediately unmapped and returned to the OS.

Re: "Qantas personnel in Sydney even requested removal of the report"

Shows how easily the pressures of conducting business can override safety.

That aircraft should not have been allowed to move 1 inch until that tool had been accounted for. That it did and flew 34 cycles speaks volumes about the motivations in play.

It also speaks volumes about the thoroughness of "walk arounds". That location where the tool was found is visible between the fan blades, if one makes the effort to look. I doubt they took the fan off to take this photograph! If one enlarges it one can clearly see that we're looking through the engine and out the other end of the bypass duct, with the tool stuck at the bottom of it. It means that, in the walk arounds before each one of those 34 flights, no one really looked "in" the engines from the front. Most likely they simply looked "at" the engines, which to be frank is ****ing pointless. I also think that it'd have been visible from the back end of the engine too, had anyone looked forwards through the bypass duct.

Granted, the engines on an A380 are pretty high up and you'd need a ladder to have a proper look. However, considering there was a tool missing you'd think that someone would have made the effort.

Qantas likes to pride itself on never having had a crash. Well, they came far too close to having one on this.

Fortunately, the risk of this being ingested by the engine core (where it could cause real damage) was pretty low. The flow of air through there tends to move things outwards. To have reached the engine core, the tool would have to have migrated inwards against the flow of air. One of the issues facing engine designers is actually getting air to flow into the engine core in the first place, when it doesn't want to. It's largely why the fan blades themselves have a twist - starting nearly straight at the root to let the air reach the inlet for the core itself, and twisting further out to have a shape that'll actually generate thrust.

What would have happened eventually is that the tool would have disintegrated, probably on take off (peak thrust), blowing lumps of nylon all over the runway, probably without harming the A380 in any noticeable way (unless there are any delicate sensors jutting out into the bypass duct further back). However, the next aircraft to take off could be hitting that debris, maybe suffer a bunch of tyre blow outs, and have itself a take off crash. That is the risk I think Qantas ran.

Re: Why?

There is no doubt some element of that. The difficulty this time is that Rust might not go away in five or six years. It's certainly the strongest challenger there's ever been.

I think the strength of Rust is causing a lot of understandable angst. If one has decades of C/C++ behind one's career - like I do - Rust is threatening to reduce us all back to square one. That is threatening, as one can no longer say that one has 20+ years more experience than, say, a kid fresh out of college. However, it's largely a matter of attitude. Learning it is achievable, and if achieved, one is ready to go. And, there's an awful lot more to programming experience than just "what language one talks".

We have been here before. Once, there were a lot of assembler programmers convinced they'd got jobs for life. That didn't last...

For projects, it's a real problem. Staying in C, now, could mean having a dead project in 5 to 6 years if the world decides to go for Rust. Yet, converting to Rust now might be a wasted effort. Some cautious transitioning (given that it's achievable) is probably a good idea, just to get a toe-hold in the Rust world. Linus seems to think along those lines, though not everyone in the LKP seems convinced.

I think that the real indicator would be if Rust got standardised. Once there is ISO Rust (or, similar), then it's something that becomes very hard to say is temporary. In fact, I'd not wait for it to become standardised; I'd start when it became clear that ISO were starting to standardise it.

Re: Why?

If it comes to that, neither C nor C++ support dynamic linking. Dynamic linking is really an OS thing, and whether or not there are library functions related to tapping that OS functionality.

There's another way of doing inheritance. Rust - thanks to its strong knowledge of ownership - is an ideal language in which to implement CSP (like, Golang has also implemented CSP). And, there are CSP implementations for Rust. CSP is interesting because it opens up a whole different view of Object Orientated Programming, Encapsulation, Inheritance, etc.

Encapsulation is a CSP process with its own internal data. That data is not directly accessible to another CSP process (like it would be from another thread in the same process in an SMP environment). A process is an opaque "Object" with interfaces (channels). A method is invoked by sending messages to the process via a CSP channel, causing the process to do something. A result may be returned down another channel. Inheritance is easy; a process incorporates another process, and passes any messages it receives that it doesn't recognise down into that inner process. Multiple inheritance is easy - a process incorporates two or more other processes.

This way of looking at CSP is quite useful for helping those with a long and deep experience in object orientated programming to switch over to CSP. It's also very useful in that - a collection of CSP processes instead of a collection of C++ objects - the deployment of those processes suddenly becomes very "agile". Go and Rust do not extend CSP channels over network connections, but it would be very nice if they did (and, there's already enough in the language to allow them to work that our for themselves if that's what they wanted to do). Erlang does (I think).

A closely related idea - Actor model programming - is more easily network distributed. Libraries such as ZeroMQ make that veeeery easy indeed.

The interesting thing to consider is whether - in this day and age - ideas like CSP / Actor model are any slower than conventional code written for SMP environment (i.e. memory shared between processes / threads, guarded by locks, etc). In today's multi-core multi-CPU machines, data is not shared; to be "shared", it's got to be copied into all the relevant caches, and there's a lot of cache-coherency traffic between cores to make sure they all have the same "version" of the data. Whereas with CSP / Actor model programming, you just copy it from A to B. There is no cache-coherency to guarantee. So down at the microelectronic level, there can be precious little difference. There's quite a few computer scientists these days who think we should go the whole hog and abandon SMP, simply to get rid of defects like MELTDOWN and SPECTRE forever.

C++ can never be provably safer that Rust. They'd have to depracate most of the language to achieve that. It could equal Rust, but I can't see how it could ever be safer (unless it becomes Rust without the unsafe keyworkd). As others have said, Rust does support dynamic linking. It would be nice if there were an ISO Rust, but it's

Re: Stop with the useless A better than B crap

I remember reading an article in a journal from the UK's IEE (now, IET), back in the days when the IEE really was a hotbed of engineering study and standards setting. The article was the results of a study and analysis of real safety critical systems in actual use. This was a very long time ago - early 1990s I think - and I'm afraid I can't remember the title or any reference, and it's pre-Internet.

The systems were mixed - air traffic control, nuclear reactor control, flight control, etc. All stuff that mattered. A variety of languages had been used - C, Ada, even Fortran I think. All had cost a large amount of money, and all had good operational reputation. The systems were studied for two categories - symantic errors per 1000 lines of code (ie.code that was compiled, but wrong against the specification), and operational errors per 1000 hours of operation.

They were all pretty good, but none were perfect. The interesting thing was that the very best was an air traffic control system, written by IBM, in C. The worst was some system written in Ada (I can't remember what it was).

The analysis considered this, and determined that for the IBM ATC system. IBM had rolled out its very best, most experienced A-Team developers, and the dangerous-chainsaw view of C was referenced (if you have a chainsaw with zero safety features, blatantly dangerous to use, you may very well take a lot of care in using it!). The Ada did less well, because they'd had a less experienced team. The IBM ATC system was (I think) also the most expensive...

Modern World

One of the challenges these days is getting anyone to do any coding in anything like a rigourous manner. For a lot of systems that get built these days, there's little expectation of producing a high quality result, and the end users have little faith in getting one. Bugs / system cruddiness has become far too "normal".

Re: Which language do you think is used to implement all those memory-safe languages?

>.NET has been written in C# for some years now.

>Prior to that Delphi was written in Delphi from the start.

>(mentioned becuse it had the same creator as C#)

>And Go is written in Go.

Er, apologies for the pedantry, but if I take even the merest of casual glances around https://github.com/dotnet/runtime, I seem to find an awful lot of C and C++ files. There is C# code there too, but it's clearly a long long way from being entirely written in C#. I gather that the C# compiler is written in C#, but the .NET runtime is (at least in large parts) not. But, more on that later.

However, I firmly agree in general terms. Once a language and/or environment is boostrapped into itself, you're up and running. One might have got to a running Go compiler by writing one in C++ first, but indeed, so what? That's not the compiler that matters, its the one that's in use (the one written in Go) that matters.

Runtimes

Runtimes are interesting, because of what they have to do. For example, a C program cannot print anything on a terminal without using functions in (for example) glibc, and those functions work only because they've been written to load up the appropriate registers with the appropriate data and generate an interrupt to initiate a kernel / system call. In theory you don't need glibc for C, because if one really wanted to your own program could make the system call itself.

Such things are not options for all languages. There's many languages that have no concept of registers and interrupts within them, and don't include any means of inlining assembler to do it either. So, one cannot write their runtimes (that have to interact with an operating system) purely in that language; there has to be a language to native transition somewhere within the runtime. Presently, that means having to use C, C++ or assembler (or other language that lets one mess around with actual registers and interrupts) for the runtime.

Rust is interesting because, whilst it shares much of the look and feel of a high level language, it is possible in Rust to make operating system calls directly from within Rust. So, all of Rust (including its runtime) can be written in Rust, with no trace of C / C++ at all (unless one starts considering the implementation of the syscall inside the OS itself!). So, one could perhaps "improve" languages / platforms like C#, Java, by re-writing their runtimes in Rust.

Which, if done, would eliminate the "Which language do you think is used to implement all those memory safe languages?" question altogether.

Has anyone done a Python implementation in Rust yet?!?!?!? Oh yes!

System Calls from High Level Languages?

C# is interesting, because of C++/CLI. I've often used C++/CLI as a means to integrate calls to native code into .NET, because it makes it so trivial to do so. C# can do it, but there's a lot of marshalling, and pinvokeing going on. C++/CLI, you just call it (and, I guess, it's hidden all the marshalling and pinvoking from you).

What I've not explored is whether or not one could make a system call in C++/CLI. One doesn't need to (or indeed, know how to) on Windows (that's what Win32.dll is there for), and I don't know if C++/CLI can run in .NET Core on Linux (I think it might be from .NET Core 3.1). However, my point is that there is a .NET language that can (or very nearly can) make system calls directly from within the language. That suggests that without too much extension or difficulty, a high level language like C# could be given the means to make system calls, and then both it and its runtime could be written entirely in the language itself.

Re: It's not the language, it's just the way it's "talking"

>I do however like the idea that F-35s etc may in future be powered by Rust, if they're not already.

Not yet - Rust is too new. Parts of F-35 rely on INTEGRITY - the OS from Greenhills, and that's written in C (using Greenhill's own C/C++ compiler and C/C++ runtime libraries). If you want compilers, libraries and an OS that has strong assurances of being correct - look no further.

But it does smell like the US Gov (which will include the DoD) will start getting quite insistant on Rust being used, and I can see why.

What Else?

Rust is one component of it. Adopt it, forbid the "unsafe" keyword, and in theory you end up with code far less prone to memory mis-use errors.

However, when one looks at today's hardware, MELTDOWN / SPECTRE and similar are all about memory misuse / mishandling within CPUs. And it's interesting to consider what can be done about that. There have been articles here on El Reg on the topic of the need to get rid of C in the hardware sense too. C / C++ and today's libraries for them all assume that its running on a Symmetric Multi Processing hardware environment (for multicore hardware). But, the hardware hasn't actually looked like that for decades; SMP is a synthetic hardware environment built on top of things like QPI, or HyperTransport (or newer equivalents), and these cache-coherency networks are what is causing MELTDOWN / SPECTRE faults which the CPU designers are seemingly powerless to fix. Apple's own silicon has recently been found to have such faults - they're unfixable in M1, M2, and they've not disabled the miscreant feature in M3 even though they can.

So, it looks like we should be getting rid of SMP. That would leave us with - NUMA.

We've had such systems before - Transputers are one such example. The Cell processor in PS3 was a bit NUMAry also (in how one used the SPEs). Super Computer clusters are like this too (no direct addressability of data held on another node). Various researchers are getting re-enthused about such architectures, pointing out that even 7 year old kids can be taught how to program for them.

Of course, such a hardware switch devastates existing SMP-centric code bases, like Linux.

What Does This Have to do with Rust? I hear you ask? Well, Rust has (in theory) perfect knowledge of what owns what data and when. You pass ownership of a piece of data from one thread to another, and it knows you've done this. An object cannot be mutable in two places at once in Rust. It is almost completely ideal for conversion from running on an SMP environment to running on a purely NUMA environment. Whereas passing ownership at present is simply used to determine what code can use some memory, it could also serve to prod the runtime that data needs to be moved from from NUMA node to another.

In otherwords, Rust is a pretty good candidate as a language that suits both SMP and NUMA architectures.

Golang is another - in fact, Golang makes no bones about being a recreation of the the Transputer's CSP architecture. GoLang is quite hilarious / ironic in the sense that it implements CSP, and has to do so in an faked SMP hardware environment, where most of today's hardware has more in common with the Transputers that with actual SMP hardware of the 1980s / 1990s.

Python multiprocessing is another. Copy data from process to process - don't share it.

This then opens up the possibility that the US Gov - having "forced" Rust on to the software world, got a Rust OS - might then start requiring hardware architectures to drop SMP too.

The Future

That hardware shift is some way off, and a bit of a long shot. However, if it does come, persisting with C / C++ code bases for whatever reason could become an even bigger liability in the future than anyone is thinking of at the moment. Not only might it become hard to find developers willing to write in it, or customers willing to accept code written in it, it may become difficult to find hardware to run it on.

That ought to worry the likes of Linux more than it appears to be doing so.

To be certain that today's SMP environments will survive and will be able to keep running C/C++, these projects need the hardware manufacturers to fix cache coherency / hardware memory faults for once and for all. Though there seems little prospect of that.

Shared Memory is, Today, no Different to Copied Memory

The classic "don't copy data, send a pointer to data if you want it to be fast" is maxim that should have died decades ago. It was only ever true in actual SMP environments like Intel's NetBurst of the 1990s.

Today, for one core to access data in memory attached to a different core, pretty much the same microelectronic transactions have to take place as would be required to simply copy the data. If code on Core 0 accesses an address actually in memory attached to Core 1, then a copy of that data somehow has to find its way into Core 0's L1 cache before the code can actually do anything with it. But, that is a copy. The problem today is that it's a copy that - because this is an SMP environment and Core 1 has also (probably) accessed that address recently, there has to be a lot of transaction between the Core 0 memory subsystem and Core 1's, to make sure that all the caches everywhere all have the current content of that address.

If you look at any Intel CPU today, you may end up with copies of the data in CPU0 / Core0's L1 and L2 caches, and in CPU1 / Core2's L1 and L2 caches, and probably also in one of the L3 caches somewhere as well as in some DDR5 memory chips. That's six copies of the data, all of which need to be kept in sync with each other.

Just think how much easier the hardware would be, if such sharing were entirely up to the software to resolve, and how sweet that'd be if it was all resolved because the programming language's syntax made it very clear where the data needed to physically be?

That's how important Rust could end up being, giving us a bridge from yesteryear's outdated and difficult hardware architectures to tomorrow's.

Re: It's not the language, it's just the way it's "talking"

Just because the means to allocate memory is a function in a library does not mean that the language itself is memory safe. You can declare a pointer, assign some random address to it, and dereference it, all without any external libraries. The code may even work - sorta - on some platforms - depending - but quite a lot of the time it's either going to crash, of cause havoc, or both.

Such code would never pass any resaonable programmer's definition of "memory safe code". C is not an inherently "safe" language. Anyone claiming that it is has a rather too blinkered view of the language.

C++ is even worse, as new is a keyword and part of the language from day one.

Re: No, of course I've no idea if this remotely resembles the actual syntax used...

The Ariane 5 first launch failure was primarily a management failure. The developers had made a mistake that was assessed and accepted for Ariane 4, which was very successful. Management didn’t allow a reassessment of this for Ariane 5!

Re: What is old is new again

One of the problems with Ada was that it featured parallelism (threads) in an era when most OSes had no such concept. It was only when Greenhills did an Ada compiler that targeted VxWorks and used OS threads (tasks in that OS) for Ada threads that Ada became a practical (for some measure of practical) language.

Prior to then Ada compilers had had to implement their own mini OS / scheduler runtime to be parcelled up with the program. And that didn’t work very well. In that era I worked for a bunch who’d bet a whole project on Ada but had so much of it that the program couldn’t be compiled…

Gets a bit tricky if POTUS ever boarded a RAF flight...

Re: Funding round ? For Boeing ?

It's not in the US Gov's gift to save Boeing, except by fully acquiring, owning and running the company for itself.

A "saved" Boeing to most people's way of thinking is the company restored to both engineering and financial health, operating as a business on the world market. However, unless they get a whole lot better very soon, the world market is going to have moved away from Boeing. Both suppliers and airlines are desperately trying to do so already, in effect pleading with Airbus to make more aircraft than they already are. The suppliers and airlines simply cannot afford to not to deliver parts or take delivery of completed aircraft. They have to seek alternative supply. Airbus is reportedly slowly caving in to demand, but if it sets up another A320 FAL that's it.

And in case one thinks that that is a far off distant possibility, think again. During this strike, Boeing's suppliers have already been asking Airbus for work. All it takes is for one of those - a critical one - to decide that they've had enough of working with Boeing and have decided to accept regular work and paid invoices from Airbus instead, and Boeing comes back from this strike finding that it can't complete aircraft any longer. Then what?

And, Embraer too has been joining in, talking to airlines about a 737 replacement of their own. They're more than capable of building it, and if they got a move on they could probably start delivery inside 5, 6 years. If Boeing isn't fixed well before then, Boeing could find that they're getting a lot of cancellations, orders going to Embraer instead.

And then there's the FAA. Boeing's order book is largely meaningless, unless the FAA's reputation abroad is trusted by its peer regulators. Boeing cannot sell aircraft outside of the USA unless the likes of EASA, CAA, CAAC, etc. are content with the FAA's oversight. But we have Elon Musk seemingly challenging the FAA's power to impose fines in the US Supreme Court. If he wins, the FAA could be seen to no longer be an effective regulator of US aerospace in the eyes of overseas regulators. If that happens, Boeing are toast.

In short, there are many reasons why there may not be a Boeing left for the US government to save. If they were going to intervene, the ideal time was 20 years ago, except they denuded the FAA of resources and made it hard for the regulator to control the company. Now, or any time in the next year or so, is probably their last chance to influence the company in a way that leaves the company as an commercial business.

There's also the geopolitics; the US Gov simply handing Boeing $60billion to clear their debt would amount to the largest ever subsidy. That's not going to look very good on the world stage, having spent years complaining about Airbus's loans from European governments.

One also has to look at it in other ways. Boeing is not popular in DoD - quality has impacted them badly too. Overall, the US gov is probably more interested in maintaining capability in the USA than in maintaining a specific company. That could be, Airbus grows in Alabama, becomes a bit more American.

Re: Funding round ? For Boeing ?

They're not too big to fail. Arguably, they already have failed in that they're not a profitable, healthy company operating in a way that is useful to the US gov and beneficial to the US economy. They're dragging lots of other companies down with them whilst they fail too - suppliers, airlines, all over the world.

And the way things are going, there won't be anything left to save.

Yep. Only a few years ago they were busily engaging in stock buy backs. The irony...

It's a text book example of a management mortagaging the future to enrich the shareholders today including themselves.

International Atomic Time

Really, all IT, technology, software should be working from the TAI (International Atomic Time - with a French accent). That follows the time rules that are commonly used in software (365 days a year, 1 day extra in leap years, no leap seconds, 7 days a week), and is aligned to what GMT at some point back in the 1970s.

All representational time - i.e. "computer" time presented to a human for consumption, should be converted (if required) into the local time zone, and if it really matters converted with the appropriate number of leap seconds.

This solution would make computer time far simpler to handle in software, far more reliable for records keeping, the lot. Instead, we have a mishmash of what "time" is in software, with most being mere approximations to UTC, and most dealing badly with leap seconds. The mishmash came to a head a couple of years ago when it was realised that the world's "bodges" for dealing with things like leapseconds had finally gone irretrievably wrong, as the IERS announced its intention for an anti-leapsecond. Yes, the earth's rotation has got faster.

This has been a clumsy and ill-handled issue in the field of operating systems and software development for decades, and it's faintly ridiculous that it continues to be so.

Re: How many western governments use Linux?

Quite possibly.

It's highly unfortunate that OSS is getting caught up in the geopolitics, but it was probably always inevitable. A really successful OSS project is always going to be one that's found widespread use - economically important use. And, whilst there's trouble in the world, it's economic role is always going to make it of great interest to good and bad actors.

Or to put it more bluntly, there's nowt that catches crap as much as a brand new hat. It's pretty much true of any good thing.

It's difficult things like that that I really wished universities taught, or taught more thorougly. For engineers, developers, etc to successfully find their way through the world, they need to be made thoroughly aware of the crap that'll come their way and how to deal with it (law, money, geopolitics, patent laws and their rights under these laws, etc). Engineers / developers who are less naive to the world's perils likely end up better off as a result of it.

Re: How many western governments use Linux?

It's more significantly phrased as, "how many western economies are depenedent on Linux?". I'm thinking banks, businesses, etc.

All of them, basically, one way or other.

Remember the attempted attack earlier this year on OpenSSH via a social engineering attack on a dependency that inserted a back door into OpenSSH? That ought to have been a bit of a wake up call. OSS projects are especially vulnerable to such attacks, but proprietary code isn't immune. Moves such as this one by Linus are, to some extent, "security theatre", in that it's not a foolproof means of achieving the desired effect. If there are enough layers of "security theatre", it does become an impediment; just look at airport / aviation security...

Ultimately, code review - excruciatingly detailed code review (and review of the build system for the code) by a trusted person / team is what does give strong assurance, accompanied by strong signing of the reviewed code to prove it's not been changed since. Though as everyone knows that's preciesly what very few people want to do.

It's also important to remember that - qualitatively, motivationally - there can be no difference between an exploitable bug and a deliberate back door. It's important with that in mind to maintain a balanced view as to who is and is not a bad actor (most bugs are just innocent bugs, probably)!

There are ways of addressing such things by changing choices of technology. There's been a plethora of attacks / vulnerabilities due to interfaces not validating data properly. HEARTBLEED springs to mind. Yet, we have plenty of technologies where interfaces can be wholly schema defined, machine built, with input / output validation automatically included. And then there's language; writing in Rust is clearly better (from a bug point of view) than writing in C/C++. OSS projects could make better tech choices to give themselves a chance of automatically avoiding mistakes, meaning that whatever review effort is available can be more efficiently used.

Re: Isolation is hard

Er, the whole point of spectre and meltdown is that, yes, guests can contrive to get access beyond their bounds. This whole article is about just such a process gaining access to arbitrary kernel memory, which is pretty terrifying.