Posts by bazza

Google engineer unplugged every fiber they could see and – surprise! – took down a chunk of the G-Cloud

Re: Engineer != Technician

Sounds like the circuit was being influenced by capacitive coupling with the screening can. That's probably an engineering design mistake!

CERN moves thousands of accelerator control computers to Debian

Re: Of course they do!

One of the key aspects of Scientific Linux from CERN was that it supported the PREEMPT_RT patch set. This was something that RHEL also supported. This allows for soft real-time scheduling (better than stock Linux, not as guaranteed as something like VxWorks, but good enough for a lot of purposes), which is a useful attribute when there are particles hurtling round a synchrotron and about to collide.

I was doing projects based on Scientific Linux back in about that time frame; actually, bits of CentOS mind-melded with Scientific Linux (the former didn't support PREEMPT_RT). Originally, we were going to be using RHEL, and were prepared to pay a license fee to do so, but then RedHat started charging an exorbitant rate for the RHEL Mesh, Real Time + Grid, and it was going to cost stupid money to run it. My guess was that RedHat had clocked that users of RHEL MRG included the high-speed share trading companies, for whom a stupid fee per year per CPU was not problem... So, mind-meld it was.

Back then, PREEMPT_RT was a bit tricky; it was essentially the result of one hero's work, and getting it working meant sticking to a limited set of kernel version recipes. The big difference now is that PREEMPT_RT is now part of the mainstream kernel project, and so it's pretty easy to get a real time kernel for - say, Debian, or Ubuntu. This is likely also a major enabler for CERN - if now right now, but going into the future.

Drivers are still a huge issue in Linux for this kind of thing. I know of systems still happily running 2.6 kernels because of the difficulty of supporting drivers. Unfortunately, there's no really good solution, at least not whilst the mainstream kernel project desires not to have a stable interface for drivers. Linux is one of the few OSes that performs well on large scale multicore CPUs. Things like VxWorks may also offer real time (in fact, superior real time performance), but were a bit of a let down on multi-core devices (maybe that's improved). So if one wants 1) a big CPU, 2) real-ish time performance, 3) support for weird or home grown hardware, it's Linux all the way and you're on your own with the drivers.

Word 97's ghost in the machine: The crash that vanished the moment anyone looked at it

Re: Permutate until pow

They couldn’t avoid interoperability testing with their own mobile phone modem development. Though they clearly took shortcuts in this in the early days, Apple’s modems couldn’t do cell tower handovers

Hardly anyone.

Intel a few years ago published an open letter pleading for microelectronics engineers. They said that the US jobs market essentially had none to offer, and no one was doing the subject at university either. The irony was that this was after they’d had a firing round after some chip taped out, so they’d not exactly encouraged anyone to take it on…

And when it comes to manufacturing the chips, we’ll, as we all know that’s got to the “one deep” stage long ago, which is why TSMC et al are so important.

Ancient ‘Who owns Linux?’ case now has one foot very deep in the grave

Let's drop a small black hole into the grave. That should stop any feet getting back out of that pit...

AMD grabs more CPU share while pricier PCs punish desktop demand

Just invested in some AMD CPUs. Most pleased, so far. Even the bargain basement ones are pretty phenomenal performers, excellent value for the money.

Blue Origin blames New Glenn fireball on engine oxygen valve

Re: Conflicted

It's usually pretty difficult to make a habit of it; the money runs out. However, in this day and age I'm not so sure...

A deep dive into Nvidia's Vera CPU and the Olympus cores that power it

Re: Not a modified Cortex

Depends on the license. Apple and some others are licensed to implement the ISA their own way.

What ARM provides to many licensees is prepackaged implementations, saving them from having to do all the work themselves.

And either way, ARM controls the ISA and expects compliance to the ISA from those doing their own implementations.

That doesn’t stop ISA implementors like Fujitsu adding to it; they’ve bolted on their own vector unit for the Fugaku supercomputer, giving their ARMs a whole set of instructions not found on other ARMs.

Re: Microsoft and Chip Design

I cut teeth on Transputers.

To be fair, Inmos weren’t much better at tools for MPP than anyone else. Sure, they could produce a compiler, but debug and general supporting libraries were woefully inadequate.

Also, even by the time transputers had come along the idea of SMP was well entrenched.

In short, the only appealing aspect of MPP at the time was that it was possible to assemble a large amount of compute. But one avoided doing so at all possible costs. When PowerPC hit the embedded systems market, I / we jumped from Inmos to Motorola with unseemly haste. It’s not even as if we stopped writing parallel code; it was simply far far easier to write for and debug multiple PowerPC cards in a single VME chassis running VxWorks than anything Inmos had aspired to.

Inmos’s big mistake was to assume that their serial interconnections between transputers was the only interface a transputer would need. They forgot the “development” use case. Has they added something like JTAG to every node so that at least debugging, loading and hardware config were easier, they may have survived.

There is a case for the return of MPP transputer like architectures, though I note that NVidia have not done that for this chip (cache coherency abounds). And these days. With both Go and Rust effectively reimplementing Transputer’s CSP (ironically on top of SMP environments), code written in these languages could be targeted at CSP hardware. Rust in particular with its Fearless Concurrency could be recast to do CSP automatically (which would be neat). And if CUDA isn’t all about parallelism, I don’t know what is.

Certainly such things - when grasped by the modern developer - generally perform well. The Cell processor in the PS3 had a lot in common with Transputer; you had to write software to push data around the SPEs instead of all memory being universally addressable (akin to sending data through a channel in Transputer). Whilst initially alien to many, those that mastered it got huge performance from it.

It took the SMP world many years to finally match the Cell processor, a couple of silicon process generations down the line.

MPP still rules in some places, eg the Fugaku supercomputer in Japan.

So did MS kill off MPP? I don’t think so. Pragmatism is an important part of technology, and ecosystems matter to all but the academics. It was already too late for an SMP->MPP hardware transition to be quick and easy by the time the i860 came about, even though few of us had dual CPU machines. Had MS gone along with it, we’d all now be running Solaris on Sparc (because that’s what would have won).

Hmmm, no matter which way one looks at this, it’s going to be one juicy chip!

I’d like one…

Dev who gave HashiCorp its name returns with a faster terminal multiplexer

Re: I mean really...

Indeed, 100's of MB on something that was intended to be read by a human, or written into by a human, sounds like requirements creep!

So, like the OP, I'm a little lost on the "why?" of this...

After rewriting SQLite in Rust, Turso turns its sights on Postgres

In a way, it's been a "Unix" for a looooong time. It's had a POSIX layer for decades. I've had X-Server running on it for 30 years, with colour! It's native shell is definitely not a Unix shell, but there's not been much stopping one compiling up a sh if one wanted to.

One of the strengths of VxWorks I always felt was that it wasn't a Unix under the hood, in the sense that it didn't provide process separation. From an embedded real time system point of view, and especially when having to hack around inside one at arms length (e.g. earth to Mars), VxWorks' lack of process separation has enabled some truly epic saves. I don't know of any other operating system that provides the features of a full-up multitasking pre-emptive OS with MMU support, assured scheduling, etc. that has a wide open memory space across the whole system. It allows one to approach an embedded system a bit like it's a proper grown up microcontroller++ with proper memory management - a rarity.

I know they've since added a process separation to VxWorks, which no doubt suits some customer applications, but then it's kinda a run of the mill operating system again.

Those are old ideas that are possibly receive new attention, as folk discover they exist. To those that know these things of old, their benefits are familiar...

Ironically, in some Linux distros the GNU userland is being replaced by the equivalent re-written in Rust...

The lack of a stable approach to device drivers feels insane to many (including me!). But it's the kernel community's choice. There are external pressures on that, not least mobile phones (Google has already taken some independent action on this, effectively inserting a stable driver layer for the benefit of device manufacturers). Rust is an external pressure too, which they're finding increasingly difficult to ignore. History tells us that projects that completely fail to flow with the times eventually wither; in this world - even a non-commercial OSS world - it's a case of develop or die. One feels that if the Linux kernel project wholeheartedly embraced Rust and finally did stabilise its driver interface, the project would be set fair for a very long time to come.

Certainly, if they did announce "we're going to convert the whole kernel to Rust", there'd be a lot of interest from many parties in that endeavour. Whole governments would be keen for a start, and might shake loose some resources and assistance.

Linus did get lucky in some regards. The FreeBSD project is another close contemporary that hit the streets just a short while after Linus released his kernel. Had that come first, it's possible that it may have won.

Burnham's spanner in the works leaves UK government tech scattered across Whitehall

Re: risks incoherency

Incoherency across government is a live issue, not a hypothetical risk!

Intel working to ‘leapfrog’ ARM and AMD designs, says CEO Lip-Bu Tan

Re: Apple: 6502->68k->PPC->x86_64->ARM->RISC-V ?

Apple have certainly been a long term ARM fan. Apple's early interest contributed to ARM making it to the mobile phone boom time, so there's a long term thing going on there.

ARM themselves are a very different company to Intel, IBM, Motorola; they exist to serve the industry, rather than to own a massive chunk of it for themselves. They've done pretty well treading that narrow pathway between serving their client companies and annoying them; disputes over license costs are pretty rare (and mostly Qualcomm). The costs of maintaining an ARM license don't seem to be a massive factor in anyone's calculations.

I'm guessing that the benefits of the ARM ecosystem (even to a company as large and as complete as Apple) are such that no one ever really takes an ARM->RISC-V move very seriously.

Re: Conflicting Strategies

> But it's been sobering to see how quickly ChipZilla has shrunk to WimpZilla.

Sobering, but entirely predictable. When Intel back in - what was it, 2014? - at the peak of its game laid off a load of development engineers, the writing was on the wall right there. Within a chip generation, AMD started taking big bights out of their market and haven't looked back since.

When an engineering company lets an MBA get to be the boss and the MBA starts doing MBA things, the result is inevitable. In any enterprise where engineering or technology is a critical part of the business, it's a case of "develop, or die". Intel chose the "we'll cut this year's costs" option.

Most company bosses have no idea what talents their company really holds, and many assume that talent can be hired on a whim at a moments notice. Whilst that might be true in some widespread areas of engineering / technical expertise, it's not true if you're - for example - one of the very few CPU semiconductor design houses in the world.

Amazon doesn't get this - it's acting to become the world's only computer, but can't hold on to key experienced staff (who go) and then Amazon run into stupid outages caused by mistakes born out of inexperience. If it keeps behaving as if it won't succeed, it's never going to succeed. Bezos is supposed to be a relatively smart guy, but runs a company (or, lets it be run) in a way guaranteed to fail in its long term goals.

Linux kernel team publishes 432 CVEs in two days

Re: seL4 anybody?

Ah, ye fabled guaranteed correct kernel.

It's interesting to consider what it'd take to contain the blast radius. It's certainly true that in an SMP environment with a monolithic all-in-one-security-tier OS like Linux, it's maximally vulnerable to internal faults. It's fair to say that this was a conscious design choice back to the days of yore when Linus first wrote it, and there's nothing wrong with that approach depending on one's ambitions. Given that the ambitions of the Linux kernel community seems to be 1) making Linux a fast kernel on lots of different hardware, 2) reasonably correct, it's hard to argue that they've not met and delivered on those ambitions; personally, I think they've done pretty well. They're not promising anything, and yet deliver really quite a lot.

It's not their fault that other have taken it upon themselves to make assumptions about the correctness in their own environments, against their own threat base.

So, I don't think that Linux is going to under go a massive re-write to base itself on a kernel like SEL4.

Whether or not the (commercial? government?) world needs to switch to something else - well, that's questionable.

On the one hand, a guaranteed secure kernel incurring all its benefits on application, system and network security is a highly enticing goal. But it's a start-again-from-scratch job. That's a very costly proposition.

On the other hand, what's the cost of fixing something like Linux? We have to remember that, whilst the scary rate of CVE discovery is pretty high at the moment (hundreds per weekend?), this is a finite problem. As we've seen in other areas of ML / AI, whilst they show off impressive initial results, they tend to stop short of perfection (e.g. self-driving cars are still not good at driving cars). Critically, this is a mathematical consequence of what they are; they're simply applying some basic statistical techniques to large data sets to be able to engage in nothing more than some quite elaborate pattern matching. They cannot invent new information. Which means that they'll tend towards a limit of achievement.

For example, if there's N CVEs there to be found in a codebase like Linux, AI will discover N-(something) of them. Granted, as the models improve the (something) becomes small, and may even approach 0. But, they're not going to be able to invent a whole new class of vulnerability that the Internet doesn't already know about (which is what it'd take to make N a bigger number).

What that means is that - at some point - the fixes for found CVEs will catch up, and the rate of discovery of new CVEs (by any automated means) should dry up.

The $trillion question is what comes first / cheapest? Fix the CVEs and catch up, or replace everything?

Personally, I think we'll catch up with the CVEs. And yes, whilst something like Linux may be less than ideal from a design point of view if one wears a paranoid security hat, if it's "fixed" and people aren't finding new problems, then it's fixed. Achieving that probably means a feature freeze (or at least, not introducing features that aren't aimed at helping eliminate whole classes of problem).

There are other things that would help. SEL4 is no good if the underlying CPU hardware is no good, and as Meltdown and Spectre have indicated there's significant problems with an SMP environment given the realities of making fast systems. Purely NUMA systems are more robust (because one thread then cannot easily spy on the memory / cache subsystem serving another thread), but require a start-again on the software front. In theory, Rust (with it's knowledge of data ownership and its Fearless Concurrency, specifically, mapping its message passing to transfers of data between NUMA nodes) could be leveraged to automatically target Rust code at NUMA systems (think Transputer networks) or SMP environments, one way for the whole industry to insure itself against yet more discoveries about the vulnerabilities in SMP environments could be to start migrating away from them, possibly leveraging a re-worked Rust compiler as a stepping stone between the two.

Re: seL4 anybody?

SEL4 (the kernel) is already licensed under GPL2...

Though, you'd still need something on top. Linux provides scheduling, network and device drivers. SEL4 - so far as I can tell - provides scheduling, but not device drivers or networking.

Judgment day looms for UK's £8.35B Skynet military satellite comms upgrade

Re: Back To The Future.............

The F35 that fell off an aircraft carrier did so because some numpty of deck crew forgot to remove one of the inlet blanking plugs (that prevent FOD entering the engine whilst not operating). The one remaining open inlet admitted enough air to get the engine started, but the blockage only revealed its true impact by severely curtailing the power the engine could produce during the take off roll. I'm not quite sure why the aircraft couldn't be stopped prior to falling over the edge; probably, automation to have been overridden... This was in the Med, not the Gulf.

I'd be interested know what sort of other problems are being encountered.

But, yes, a very pricey plane. There's definitely a need for a more basic carrier aircraft. Operating F18's in parallel would be quite a good idea...

LisaFPGA brings Apple's magnificent misfire back in programmable logic

Re: FPGA?

Much is made of the parallelism one can have in an FPGA, but that's far from a unique trait, especially today. A GPU is fast only because it is very parallel. CPUs have had vector units for decades, and now have hundreds of cores and half a dozen memory interfaces. There's some very big chips available these days.

There's more to "hard to develop for" than the learning curve of the language. It's the place and route time. It's a nightmare to develop a system if you can do only 1 build per day (as was not unusual on large FPGA designs). Software takes considerably less time to compile, and you can far more iterations in a single day than with a large FPGA design. The tools may have improved place / route compute times, but that doesn't help if you make a big change.

Another area where a lot of development time is spent on FPGA systems is writing support code (for memory, other attached peripherals). Library code can help, but if you're assembling one's own board then there's a ton of work to do there. With a CPU, a good OS / sensible peripherals will just, well, work.

Re: FPGA?

Hmm, posts are slow in appearing today; I’ve just rewritten one I thought hadn’t got saved at the weekend!

Re: FPGA?

I'll chip in; many explanations don't ever cover the "realities" of such devices, which is often what is needed to understand them better.

The basics of an FPGA are that they're chips that contain a lot of logic gates, clock distribution circuitry, programmable look up tables for those logic gate, and the ability to join gates up to other gates in a reasonably arbitrary way. If you ever did any digital electronics using discrete logic chips like a 7400 (a chip that has 4 2-input NAND gates), then an FPGA allows you implement that logic circuit by programming its lookup tables (e.g. to give them the same truth table as a NAND) and defining the interconnect between gates that you want (which is like building the printed circuit board to hold your 74-series chips). The words are all there in the name: "Field Programmable" (the device is programmable and you don't need a lab to do it) "Gate Array" (a large number of logic gates that can be programmed).

This sort of chip emerged from earlier more primitive concepts, where the circuit was less arbitrary, couldn't be as complex. Programmable logic has long been a way for electronics engineers to build circuits out of fewer components with more flexibility than is achieved by soldering discrete 74-series fixed-function chips to a board that you can't readily change. FPGAs emerged at the larger end of this market segment.

In principle, you can recreate any logic circuit you like (within boundaries). And as a CPU is just a large amount of logic on a chip, if you have a big enough FPGA you can emulate that CPU, down to the last transistor (kinda).

Early Problems

A major consequences of this approach was 1) cost, 2) speed, 3) thermals, 4) programming difficulties.

If you bought a chip capable of emulating 1000 logic gates, but used only 10, you were throwing money down the plughole.

The designers of the chip had to account for every conceivable clock configuration, and so the logic circuit you can implement can't be clocked very quickly.

By having far more transistors than was strictly necessary, there's power being dissipated for no good purpose.

And, as they got more complex, programming became harder and harder. And they are not infinite; use too small an FPGA for the circuit you want, start again on the board design. That's really news, late in a project. In the bad old days, if you had a large project you could also run into the problem of the FPGA build tools failing to complete place and route; it was purely a matter of random chance as to whether the initial "guess" it would have to take would successfully fit everything in. Folk literally ended up with code that - one day would build, another day it wouldn't. And it'd take a whole day to tell you it'd failed too.

All in all, kind of OK during development (at best), hopeless for production, and not competitive with a specifically designed chip for speed. About the only thing they're good at is having lots of copies of a logic circuit all running in parallel.

In fact, a valid question is, "why did they ever succeed in the market?". The short answer to that is that - really - they didn't. Whilst the likes of Intel and Co saw massive markets build up around their products, the FPGA manufacturers always seem to have struggled. All their frailties pointed to "niche", and that's the market they've filled; the niche where people will overlook their problems, to some extent.

Improvements

To address some of these frailties, the FPGA manufacturers started to do things like add "hard cores"; bits of silicon dedicated to specific functions. These range from the kind of logic one needs for some signal processing maths operations, to whole CPUs (ARM or PowerPC), bus interfaces (PCI), memory (DDR). The idea being that - probably - your design may want some of this and - instead of having to implement it in look up tables - can just wire up to these existing functions.

Why Isn't This Software?

Good question! The answer really lies in the programming. On a CPU, one has the idea of being able to load up any software one wants. Whereas an FPGA - whilst it doesn't have to be programmed in a lab using special tools - there is the general expectation that the programming would not be changed once programmed. Some FPGA technologies this is even physical; the look up tables and routing are programmed by un-burning anti-fuses (yes, that's right) in a one-time operation.

As with everything else in FPGAs these days, the lines are now somewhat blurry; you can on some models partially program them, and have them load up the rest later on (much like an OS and application).

However, their most useful attribute today is that the firmware they're programmed with can be either physically permanent, or very hard to alter (lots of cryptographic protection and authentication of firmware content). This is ideal in a security environment where you want to separate something from something else with some sort of processing / channel in between. Built that processing and channel inside a modern FPGA and you can have a ton of assurance about that implementation that you simply cannot achieve with an OS + software.

Signal Processing and other Maths

The vendors like to big up their chips as being good for maths and signal processing. And indeed, a modern FPGA can be pretty pokey when it comes to ops / sec.

However, their frailties still bite; a big, expensive modern FPGA may have a DDR interface on it, but a big cheap modern CPU might have 4 or more. And the FPGA might clock at only 400MHz, whilst the CPU can probably reach 4 or 5 GHz. And whilst the FPGA might still have a lot of "parallel", CPUs (with things like MMX, SSE, Altivec, AVX) aren't exactly short of parallelism either; a modern CPU can have 192 full CPU cores, each with 512bit vector units; that's a lot of parallelism clocked 10 times quicker. CPUs most severely and comprehensively outgun most FPGAs, especially when it comes to floating point arithmetic.

If - as often happens in FPGA projects - there is some uncertainty as to the exact required algorithm, and as the project evolves so does the algorithm's memory requirements, it reaches a point where the FPGA's internal memory is insufficient and it's now reliant on that external DDR connected memory. At that point it's game over; a CPU would certainly have been the better bet.

Real time? FPGAs are often cited as being good for real time; except, a modern CPU properly used is perfectly capable of being "real time" too. With a proper BIOS even Intel CPUs can be coerced into staying in a fixed power mode and not switching clock rates and voltages all the time. And a decent RTOS (VxWorks, Linux-PREEMPT_RT, INTEGRITY, etc) do a good enough job for most purposes.

Summary

In short, you've got to have some sort of burning engineering reason to want an application-specific integrated circuit in one's project, but can't afford to pay an ASIC manufacturer to make your part and o opt for an FPGA instead. And, not many of us do.

Which is why Intel sold off Altera - which it had bought only a few years previously - with the company being lucky if it does $1billion a year. Xilinx - the other big player in FPGAs - got bought by AMD, and so their performance is a little bit opaque at the moment; I think it was doing about $1billion a year too before acquisition. I very much doubt AMD makes much money out of Xilinx. Meanwhile NVidia - GPU''s being the other major alternative "CPU-maths" - are clearing $100billions+ a year.

So, Why Didn't AI pick on FPGAs?

Some folk did. But at the end of the day, NVidia did a good job with CUDA, and a GPU is comparatively cheap.

Another aspect is build time. If you're compiling CUDA code, it'll take, what, a few minutes at most? Whereas doing the place / route for a large FPGA can take a seriously large workstation an entire day. Your developer isn't doing much development for about 50% of the time. Being quicker to market matters, and you get their quicker with GPUs.

Disclosure

Personally, I hate FPGA for all but a very few specific use cases. Throughout all the time they've been around they've been marketed as the solution to all your problems, and universally failed to deliver on any of them. I've been stung by the manufacturers making things up, lying in data sheets and concealing silicon faults until you yourself stumbled across them (here's a lovely errata sheet instead of a working part). In contrast, I've built some fairly major specialised signal processing system with CPUs and rarely hit a problem at all. The lifecycle on FPGA projects is so slow that they're always behind the curve, always struggling for relevance.

Re: FPGA?

Whilst one can go off and read a text book definition, one cannot really appreciate a technology without some first or second hand experience.

Here’s some second hand experience….

They are an array of programmable logic gates. The idea is that you can make any clocked logic circuit you like, within limits. They originated from earlier devices with few gates and more fixed wiring. If you want to make a CPU with one, you can. If you want a lot of copies of the same logic function, you can do that too.

There are drawbacks. They’re hard to program. They’re slow in comparison to dedicated logic (400 MHz top?). They have limited space on them and once full your project is generally in deep trouble, generally discovering this at the end of the project not the beginning. Most of the time you’re better off with a CPU or an ASIC or a GPU.

To address some of these shortcomings the manufacturers have added hard cores, things like PCI endpoints, DDR interfaces, actual CPU cores, signal processing accelerators, etc. But they remain problematic. For many applications a CPU or GPU is quicker, cheaper, and swifter to develop for.

One key benefit is their immutability. You can be very sure about the programming of the logic gates, in a way that’s hard to match in software on a CPU. They’re pretty good in certain security systems.

Overall, they fill certain niches. You have to be desperate to use one, but not so desperate as to develop an ASIC instead. That’s a pretty small market.

One man, two kernels, and a lot of RISC-V

I've always, always wanted to work with QNX; never really had the chance. VxWorks and Integrity - yes, but I'd like to round out the set.

A "dream project" that I wished existed is an Ubuntu runtime on top of a QNX kernel. Weird, maybe. The highly admirable Linux PREEMPT_RT goes a very long way to providing an OSS real time OS of note, but an OSS hard real time kernel / OS stack would be nice!

FOSS dev builds a BASIC compiler using LLVM

Blast from the Past

OS/9 eh? Well it's been at least 30 years since I last ventured there.

OS/9 was a reasonably good RTOS, but was expensive; you built on the target hardware, so your target hardware had to be beefy enough to support build. If you then ran on lesser hardware and experienced a bug, you'd have no dev tools to help.

Whereas, VxWorks was all about building off-target, and hosting all the dev tools off-target too; So, whilst its license was quite pricey, one's hardware could be really quite modest *and* you could debug deployable hardware without having to load that up with resources it didn't really need. The combination of Sun workstations and VxWorks was highly productive I found.

The irony now is that - with ARMs being tiny and highly capable - it's now entirely reasonable to have deployable hardware with the resources to host the dev tools and not cost a small fortune. And with Linux absorbing the PREEMPT_RT patch set so that it is now first-class supported code, one can have a (soft) real time system on a very cheap piece of hardware.

Apple gives Mac devs a WSL-ish thing to call their own

Re: UNIX

Yes indeed.

Linux - well, a lot of the stuff layered on top of Linux - is increasingly moving away from being Unix.

It's going to be interesting to see what the USA's Department of Defence does. They're the organisation that drove the development of open standards like POSIX / UNIX, VME, and in response to that various vendors were obliged to comply (hence MS's SFU for Windows, back in the day, OS/2's POSIX runtime, etc). They're still mandating open standards, more so than ever before; if your proposed system isn't using all relevant open standards, your proposal goes straight into the garbage can.

Yet, the likes of Amazon, various Linuxes, other Cloud providers are kinda ignoring these open standards yet are being offered into DoD contracts. At some point, someone in the DoD is going to say "it has to be compliant with an open standard", and then some really big companies may suddenly find that they've bet their house on Linux but now need it to be beaten into shape. And whilst the DoD is not the spending force it was - it can no long drive an entire technology sector to meet its will - it's still plenty potent enough for it to be worth someone's while investing.

Python JIT compiler project under threat after steering council says proper process wasn't followed

Re: Waterfall process much?

I certainly admit that "presumably" is doing some heavy lifting there!

>There are pros and cons to a JIT, you give up some things in return for others

As in, some features of the language are changed, removed? Yes, I can see that being problematic. Facebook famously had to change php when they crash-developed a compiler for php. I recall they managed to keep most of php the same, but it is a different language to interpreted php.

Clearly, code already in main has got there only because someone has accepted it into main, likely under the cover of the existing PEP. It sounds like this has amounted to a dawning realisation that all was not as anticipated. Possibly a good thing to do right now (even if a new PEP is agreed) would be to bight the bullet and pull all the previous work out into a separate branch, clean up main. That'd be something to be getting on with whilst a PEP is considered. Maybe there's value in that; whatever decisions were previously made about working in main, there's evidently reasons to not do that now. Having a branch and a clean main would alter the context of the work; it can proceed more on a "let's see" basis, rather than "this absolutely has to be right" basis.

Re: Waterfall process much?

Presumably the answer to a lot of those questions would be neutral. For example, if it did impact threading as it is now, it'd not by Python.

I think an interesting thing to ponder is if a JIT were in place why would anyone ever want an interpreter version? If the answer to that was "no one", then a lot of those questions really should be able to have a neutral answer. Obviously if it failed to be an improvement at all then that'd be a problem...

UK Typhoon jets fitted with bargain-bin drone busters for Middle East sorties

P&W can't build their GTF engine for airliners fast enough either...

The world can't wait forever. I expect RR are itching to have a go at a F35 engine; knowing them, it'd come out a bit more powerful too... They're getting ready (reportedly) to re-enter the single aisle market for airliner engines, in a way that'd likely threaten P&W's market share considerably.

Microsoft's bad obsession is showing up in shabby services and slipshod software. Here's proof

Re: GitHub mirror?

I don't know about full mirrors of GitHub, but it's interesting to observe that the world seems to be forgetting what Git actually does. From the article:

The second course is less than gourmet. GitHub is turning up late and cold. One of GitHub's biggest fans, Hashicorp co-founder Mitchell Hashimoto, says that the platform is now so unreliable due to daily outages it can't be considered as safe for production. This is much more significant than it seems on the surface. Hashimoto is a five star code chef, serving up unusual yet delicious dishes in unlikely genres, such as terminal software with elegant and useful innovations.

GitHub, nor any other third-part hosted service like GitLab, probably shouldn't be part of one's production environment anyway. And of course, with Git, one can move one's repos anywhere and everywhere with ease. But what doesn't travel is things like the issue-handling & build sides of these tools, and it's these that are perhaps as important to owning / developing a software product as the source code is. So something like GitHub becomes production-critical only because its where one's issues, build, etc. are.

Actual source code - the whole history - is trivially portable and with care about submodules those too can be harvested and re-hosted too.

So, whilst Git itself solved the problem of repository failure / resiliency by making it simple for everyone to have their own copy of the repository and makes merging of separate copies a sane (or at least, semi-sane) task, the other problems remain.

A question then is: is it possible to build in an issue-tracking feature directly into Git, and make that mergable in a sane way? The answer is probably yes (with some work). Sorta like making Git-Bug a standard part of Git. [I'd not heard of Git-Bug until in writing this thinking to search to see if such a thing existed. And, it does! Git-Bug is quite intruiging]

How about some of the other features of sites like Github? What about user rights, e.g. you have your own copy of someone else's repo, you can make your own branches but Git won't let you merge into main in your own copy (because you've not got the keys). That's leading up to, could Git itself have a means by which pull requests are accepted remotely? E.g. you've sent a patch to the originator of the software as a form of "pull request" email, and they send back some key or other that is their acceptance of that. You apply that key to your own copy of the repo, and your branch can now be merged into main, and the two separate repos still agree on what main is. From what I can see from a quick search, all such user control is currently implemented by a server of some sort (GitHub, BitBucket, etc).

It would also be cool if Git could incorporate a standardised approach to build too. I'm not talking about just shoving a collection of vagrant* files into a repo. Quite often such things end up being local-network specific and meaningless somewhere else. I'm thinking more along the lines of something that is shaped in general terms and Git gets a description of the local environment from your local git configuration and can build you a build / dev / test / prod environment accordingly. That might be, "build Ansible into Git", though I'm not sure.

This is probably all some sort of pipe dream; there's loads more involved in "software development". It's just a pity that Git's universality as a means of everyone having a copy of the repo isn't matched by a unversality of how other aspects of software development are done. A lot of the rest of it is done in ways that amount to Walled Gardens, again.

*other environment specification systems are available

AWS racks M3 Ultra Macs that boast specs you can’t currently buy

Re: In the post-consumer world we will own nothing...

There was a slight difference; one's hosting institution had the mainframe, and could prioritise around the goals of the institution. With Cloud, one is subject to the pressures of a much larger market and one has no way to buy a way to certainty (unless one buy's Amazon). It's an invitation to be commercially blackmailed! I've already seen companies realise this and get back into - if not on-prem - at least renting rackspace for one's own hardware.

I didn't know Ethernet started off as a radio transmission, though it makes a lot of sense. The original 10-Base5 is very "radio" in the sense that it's a single, shared medium with an access control algorithm. Not like today's star connected UTP or fibre networks; they're like having a dedicated spectrum per host... The irony of course today is that many high speed digital signals such as Ethernet, the CPU RAM bus, PCIe, USB, etc; they're all complex modulated radio signals loosely guided by the wiring. Long gone are the days you could put a 'scope probe on a PCB trace to see what level was there. Even bits inside devices are beginning to not be bits (e.g. multi-level flash).

Re: In the post-consumer world we will own nothing...

Pretty sure you're guess is on the money. There was an article in the tech press (on El Reg if my memory is correct) suggesting that none of the silicon manufacturers had any plans to expand their production capacity beyond normal planning, to be sure of not having too much when the bubble bursts.

Re: In the post-consumer world we will own nothing...

High performance compute is rapidly getting into trouble, and on-prem especially so. The performance of the "average" CPU is now more than enough for 99% of use cases - datacentre or home. If the remaining 1% of users / uses gets eroded by Cloud provision of "top-end" compute, then what's left of the on-prem market may find that the suppliers no long care for their piddly insignificant market presence.

Which is a problem, because for a long time Super Computers have relied on there being top-end silicon widely used and widely available off-the-shelf across vast swathes of the economy. Very few supers are funded to the point where they can dictate and manufacture their own silicon. And, no, Cloud is not really a "super-computer for everybody". Cloud node are interconnected to most efficiently serve the needs of the vast majority of the market. It's not interconnected to be efficient for, say, large scale finite element analysis. Sure, you could run such models on Cloud, but it'd be disproportionately expensive.

And as for those power users who for various reasons do not want to be internet connected, they face being disposed of usable tools entirely. Which would be a pity, because quite a lot of the work done that way is really, really important.

Veteran network architect proposes IPv8 – to improve IPv4, not leapfrog v6

Re: Regulatory Hurdle

>So what do you think was the driver behind having every IPv6 device discoverable

IPv6 was a poor idea, though at least it did not require your own personal government-issued signing key applied to every single packet you sent.

>So tell me, how's that one working out for Huawei?

Er, that has nothing to do with it. I was referring to an attempt to turn a standard into a thing that one would not want in one's country, and the mechanisms within the treaties that would simultaneously make it hard to uniaterally (or even multi-laterally) reject it as a standard and probably lead to all manufacturers globally implementing it, friendly or not.

Huawei implemented standards (S7, 2/3/4/5G, etc) with which everyone was entirely happy, just that some countries didn't like Huawei's implementations due to the other things that they did or did not do.

Regulatory Hurdle

It wasn't so long ago that China was trying to drive NewIP through the I.T.U. as a new standard. That had some nasty, state-control-friendly features. It nearly made it, though at the last minute the West applied sufficient diplomatic muscle to stop it getting voted in.

The reason this was important is that it's the ITU that manages the standards for IP, not IETF, and there's treaties around their adoption. Signatories to the relevant treaties (basically, everyone everywhere) are obliged to let goods that conform to ITU standards into their market. The fear with NewIP was that - if it became an ITU standard - it (and the control it offered nation states such as China) would have to be let into countries like the USA, UK, Europe or break treaties (with the diploshame to go with that).

That effectively weaponised the standards building process, which may not bode well for any new IP standard.

Musk has never built a wafer fab, but he wants to burn $119B on one anyway

I'd be surprised if the best of those hadn't already been snapped up by the likes of Apple, Qualcomm and AMD...

I'd be pretty wary of betting a career on this plan of Musk's succeeding. The semiconductor industry is totally globalised, and there's key suppliers that either he'd have to persuade to join in with his vision and ramp up their capacity, or he'd have to replicate them. The reason the industry is globalised is because it's far from trivial to replicate the specialisms that are involved. All it'd take is for Musk's plan to fail at one single point in the supply chain, and the whole enterprise is toast.

If he manages it - well, I guess I'd be impressed. Because previous attempts (including the CHIPS act) haven't really produced the goods in terms of getting the US semiconductor manufacturing sector back to being World leading.

QUIC will soon be as important as TCP – but it's vastly different

Adding a double decker bus to this year's F1 would only improve the spectacle...

Re: The problem is not TCP - is HTTP

TCP is still a problem though. It makes assumptions about end to end network propagation times, which aren't always true (especially long distance).

E.g. to get TCP working via a geostationary satellite is not really possible. The 0.5 seconds delay leads to very inefficient network usage. What most VSAT terminals do is to terminate your TCP connection at the modem / ground station, and they implement a different protocol on the sat link itself and re-birth a tcp connection at the other end.

QUIC is interesting because it seems to me to bump the responsibility for link management up to the application, and out of the hands of the OS. Of course, on Windows, MacOS, and everything else but Linux the TCP stack is a user space library anyway and not part of the kernel and thus is also "in the application". But it's probably a good thing; applications (esp a browser) can have such a complex relationship with a server that the idea of one simple tcp byte stream between client / server is a pretty cumbersome thing.

It would be better if it was more efficiently defined (a schema would be nice fellas - let's get with the 20th century and use automatic code generation; even dBus does schema driven code generation)

Re: There was nothing wrong with DCOM (or CORBA) IDL !

Of course, the mistake made by DCOM, DCE, Soap, gRPC, dBus, etc. is that the perfect serialisation framework already existed, still does today, is still updating and is pretty much perfect for any given scenario: ASN.1. What's actually happened instead is that many projects have decided "we need a serialisation framework", and most have launched straight into "let's brew our own up".

Even Google had to admit at the conference where they introduced GPB that Google had not used Google to Google for "binary serialisation technology", and created the not-very-good Protocol Buffers largely out of ignorance of the existence of something already there. Google could have saved a ton of money and exceeded GPB's design goals if they'd simply read the ITU ASN.1 standards and implemented them instead; One of Google's original motivations was to use fewer bits to store information (hence their varint format). Ok, it's better than bloaty text representations like XML, but it's no where near as compact as ASN.1 uPER...

ASN.1's origins in the late 1980's, early 1990's are deceptive. Today, it's perfectly happy speaking JSON and XML, as well as all its traditional text and binary wireformats. ASN.1 schema are interchangable with XML schema, and by extension JSON schema (but you get all the other ASN.1 benefits on top). Even more fun is that now there is also CSN.1 - Concrete Syntax Notation #1 - which is a schema language in which you really are defining what each and every bit of the wire data means (concrete, as in the opposite of abstract).

I think the reasons ASN.1 is barely known of, not more widely adopted are

1) it's a product of the telephony industry / ITU and not the IETF,

2) good tools for it cost money, and

3) the standards are extensive and complex

which is a big pity, because one can pretty much retire all system integration risk at design time using it.

Taiwan cops say student's radio kit brought bullet trains to a standstill

Who knows. Likely it amounted to nothing more than corruption of the protocol stack, and a reasonable response for such devices when they realise that the radio network is borked would be to assume the worst. A "general alarm" sounds like it could fit into that kind of scenario.

A replay of a bit of recorded signal could easily (to the rest of the network) look like one base station is seriously out of sync. Quite a lot of cellular or cellular-esque networks are highly dependent on timing consistency across the whole network to be able to operate and quickly get into trouble when that's not true. This is one of the many reasons to worry about potential loss of GPS, which could bork mobile comms pretty quickly.

An SDR filter is an odd turn of phrase, but one can do filtering digitally if one wishes to.

Re: OK, I'll bite

Probably looked up sales of SDRs and such like in the locality, and went from there on.

Assuming that this is no more than student curiosity, and creative way to deal with this would be to set him to work in their Electronic Warfare R&D for their military, pay him to do it professionally.

Where to buy a non-Apple, non-Google smartphone

The Law?

Er, won’t that impending change by Google instantly fall foul of European and UK law? I thought the EU had compelled Apple to support side loading from other app stores. I see no reason why Google would be exempt.

User found the perfect formula to make Excel misbehave

Re: Analogue clocks

I think we should ditch decimal and adopt sexagesimal for everything!

Re: Analogue clocks

We do make it hard for kids. First, it's counting in decimal, we drum 1-to-10 into them, they have 10 fingers, off they go.

And then at school we say, "here's something called time that it's going to be really, really important to be able to count". The kids are like "ok, so I can count, no dramas, what's the big deal?". And then the teacher says (in effect) "Well we're going to count it in sexagesimal because <reasons>. And you can't actually see the things to be counted, they're called seconds but there's no firsts, and they're anyway third after hours and minutes. And for some of the bits of time we'll be counting we count only to 24, or sometimes to 12 twice, and you can't see those either but they take a lot longer to count". And the most thorough of teachers would add, "And sometimes we count only to 59, or to 61 or 62, but only at the end of December or June and only if you felt the Earth wobble in a particular way. And then the DST comes along and steals one hour from you, but gives it back later in the year".

More ancient Linux device support faces the chop

Ethernet has - kinda - won.

In the military equipment space (VITA, OpenVPX), it's now all Ethernet interconnect within chassis and outside of chassis. They used to have Serial RapidI/O which - when new - significantly out-performed Ethernet. It had switch chips, and the DMA data transfers one could do between cards were pretty low latency and plenty swift (GByte/sec sustained, no trouble).

The reason why it's now all Ethernet is not so much cost (well, it is cost), but market size. The cost now to develop a competitive switch chip is $billions x lots. The size of the military equipment market (for radar processors, electronic warfare systems, etc) simply isn't big enough for the market to fund the development of their own switch chip for their own network standard. What's also helped is that today's CPUs are true monsters, compute-wise. Whereas in the old days a computation had to be spread out across a chassis full of CPUs (necessitating a low-latency, high speed data transfer network such as Serial RapidIO), a modern CPU can swallow the whole problem in on singular gulp and have CPU cores to spare (removing the need for low latency transfers between boards). So instead, they now put in large Ethernet switch chips and run parallel Ethernet lanes between boards to get vast bandwidths (albeit at Ethernet-like latencies) between boards. It also gets rid of a whole software layer.

Ethernet is not everywhere though. The Japanese super computers K and Fugaku have Tofu - a CPU to CPU data transfer network that is wired in up (I'll try and get this right) in a 6-dimensional hypertoroidal interconnect interwoven with a 4-dimensional hypercube (= every node is connected to a lot of other nodes), and that gets huge bandwidths at low latency and Ethernet cannot match it. There's no switches, which helps (the software has to do its own switching).

There's a kind of affinity between Ethernet and IP. IP assumes a packet switched network exists underneath it, and that's what Ethernet (and much of networking today) provides. TCP is a layer that provides nice, reliable, ordered data transmission over such (potentially chaotic) networks.

ATM sets up a virtual circuit, and in that sense it is already providing a reliable end-to-end data transfer. Looked at this way, adding TCP/IP on top is not necessary for making the connection reliable, it's just wasted overhead.

Here in the UK with BT's System X (which was a masterpiece for its day) was also a thing. That too was circuit switched nationally, and was capapable of providing huge bandwidths across the nation with guaranteed delivery. I don't recall anyone ever hooking a computer up to that directly for the purposes of WANing, but it had the potential to be "the network we use for everything (wired).".

Had the world gone down the route of ditching Ethernet and adopting either ATM or SystemX, things like video streaming could have panned out very differently. Today, it's all http over tcp. But some of the protocols being created nowaday by Google, etc. feel better suited to networks like ATM (or at least, they'd be far simpler and more effective if ATM underpinned data transfers).

Re: Nvidia 470

I guess that on the assumption that most Linux developers are using Linux as a desktop and likely have an NVidia GPU installed, most Linux developers are tainting their own running kernels.

Also, the copyright for Linux is not held by any one single individual (corporeal or corporate). The EFF does not hold the copyright, and cannot by itself just kick off a case; the actual copyright holder has to be involved. I strongly suspect that most don't care to get that involved in legal issue.

>The whole idea of the non-stable driver ABI is to force in-tree development of modules - which frankly would be a lot more effective to enforce via enforcement of the GPLv2.

If that is the reason, it's somewhat problematic. There's all sorts of rows about code in the tree - style, quality, etc. Look at the fuss there was initially about Paragon's NTFS driver (which was being given to Linux for free, but didn't fit the established coding styles). There's other sorts of politics; look at the fuss over the use of Rust. And at the end of the day, someone from outside cannot force their code into the tree if the insders don't want it there. The pull request will simply get ignored.

So the way the project overall behaves and is set up means 1) it's far from guaranteed that one's efforts will be accepted by the kernel community, and 2) they make it hard for one to be fully independent, working to an ABI (because there isn't a stable one).

Companies like Intel have tried to play nice; contributing USB drivers (there were arguments about those), and drivers for Intel graphics. Now, Intel has withdrawn; no more coding effort from them. Where Linux used to rely on "at least the Intel GPU driver will work on this machine" safety, that's going to go away... If Linuxers find that getting a desktop of any sort running starts to become harder and harder, maybe that's what'd driver a change in the project's outlook. It's similarly hard in Android mobile phones. There, Google has introduced a shim translation layer to isolate actual driver code from the prevailing driver ABI. That way the "drivers" can remain the same even if the kernel (+ the shim) gets updated. The Android spin on Linux is effectively fully proprietary; you can get source for bits of it, but not the whole thing. Then there's the RedHat angle too. Their spin on Linux is now essentially fully proprietary. Sure, you can still ask for and receive the code if you're a paying customer, but if you ever dare distribute that source code then they'll decline to sell you the next version.

Pass the key, passwords have passed their sell-by date

Re: Dislike passkeys

Also Passkey still requires the user to choose and remember a password for account recovery purposes. If you lose that mobile phone then you need a password to get set up again on a new one.

And that recovery service needs to be readily findable, require only a password, and must provide a way of revoking existing passkeys lest they get used by someone else who has stolen the phone, or similar. They’re as open to misuse and abuse by attackers as any other security measure.

I know the advocates of passkeys acknowledge this, but claim that they’re better than using a password all of the time. That’s a somewhat subjective claim, still based on the vagaries of human nature. Careless or ignorant users will still do careless or ill informed things, like use one recovery password for all accounts. Telling them they’re smart for getting with the program isn’t actually going to help…

You can now run WSL on Windows 95, in case you're crazy, too

ReflectionX was another, and was pretty good