Posts by Kristian Walsh

Re: Meh!..Meh, Meh

Yes, 6502 was her original influence, but ARM was always a 6502 programmer’s wish-list for a better ISA.

The first time I saw the “conditional instruction” idea I was amazed at how something so simple could fix such a common performance issue - branches are fairly expensive, but code is filled with short conditional jumps. For example, code like "if (x==0) y=1 else y=2” need five instructions on a typical ISA (load, branch-if-zero +2, load #1, branch-unconditionally +1, load #2), but only three on ARM (load, load-if-zero #1, load-if-not-zero #2). Saves space and memory, Genius.

The problem is that aside from the phantom braking there are also instances of Tesla cars on Autopilot driving straight into genuine obstacles: eighteen-wheeler trucks, highway gore barriers, and even parked police cars with full lights flashing.

It’s hard to make the argument that the system is over-cautious.

... Yes, in each of those, the driver is ultimately responsible, but in each of those, it’s also very hard to see how a normal Autonomous Emergency Braking system that doesn’t rely solely on visual image processing would have allowed the car to strike a large, solid object.

Re: Chemicals & Services

And how they find the construction companies is by tracking their inputs. It’s hard to build anything without materials, and the suppliers are far more diligent with their paperwork - if they’re not, they don’t stay in business for long.

It’s actually pretty hard to fiddle your taxes these days if you have any kind of input costs. Once caught, you open yourself to some very severe penalties, and there’s very little room for argument.

The reason is that there are two taxes in play: income tax on profits, and VAT on inputs; and the amount you claim/remit in VAT and the income you report for income-tax need to tally - the ratio doesn’t matter, so long as it’s within the acceptable range for your business type and region, but the revenue offices have very good models for different types of business, and they know within a copuple of percent how these figures need to line up.

To avoid tax, therefore, you have to underdeclare not just profit but also inputs. The problem is that if you underdeclare VAT, you’re directly stealing from the government, and the penalties for this are swift and severe. But, if you underdeclare income for tax, while paying your correct VAT to avoid prosecution, now your input costs don’t match your declared profits, and you get audited and eventually end up with a big tax demand.

Re: Chemicals & Services

It’s very different. In both of these cases, you gave your consent in advance of the purchaes for the autorities to have your details; and you are the direct beneficiary of the purchases (I don’t know French laws on this, but I suspect it is a criminal offence to buy controlled poisons for an unidintified third party).

That’s very different to the government going to a pool-cleaning supplier and demanding their customer lists for the sole purposes of conducting a tax investigation. There’s no public safety grounds for doing this that would override the lack of consent from the purchasers.

However, if the French taxman is like his Irish cousin (who I do know about), they can —and will— look at the tax returns of the construction and pool-cleaning companies to estimate how many pools there are in each company’s catchment, and they can then compare that with the property improvement declarations in that are to see if they tally. If not, an on-the-ground investigation can be conducted to find out who’s dodging. All of this can be discovered without knowing one customer name or address, so GDPR does not apply. This story sounds like they used the satellite imagery as a replacement for that on-the-ground survey in certain Départments where there was already an anomoly, rather than them starting from a blank sheet.

As we’ve somehow lurched from enterprise applications to microcontrollers (...?), my experience of embedded is that it’s Linux that has the worse support. Or rather, it has either good support, or none, depending on the device you’re using. That’s not a viable platform to work from if you want to do this as a living (yeah, tools really matter, but clients often have invested in a particular micro for lots of good business reasons, and they won’t throw away those years of code just because some bolshy dev says Linux is cool).

If you’re lucky enough to target a device in the "has Linux support" category, then you can certainly feel that Linux is “better”, especially if all of your experience (and thus all of your ability to script and automate the horrible bits of developing on limited systems) is on Linux already. Even then, a client will send you a datasheet for some peripheral IC, and that’ll have a progammable core, and... oh look, a Windows-only toolchain to code for it.

I do embedded development, on Windows, and I use the Windows Subsystem for Linux to manage a lot of the nasty stuff around the edges. However, I’d never move to Linux. Firstly, my target chip has even poorer tool support on Linux than it has on Windows (and that is saying something!), but to be honest, for me the only good thing about Linux is the commandline userspace, and WSL gives me those already, so moving over to just Linux means mostly losing out on Windows-only stuff.

Your recollection is incomplete. 90% was the peak figure for user desktop replacements, but very quickly those users began to request a return to Windows as the Linux-based solutions were missing key functions.

The Linux ecosystem has no centre, and its continuous development model makes it much more of a moving target for internal application developers than Windows is, unless you expend a fair amount of effort maintaining your own distro. (Package maintainers are the real heroes of Linux - it’s a thankless, time-consuming job, but without them the whole ecosystem would collapse).

The nail in the coffin was the prospect of decentralised working. There simply wasn’t any good private-cloud solution for collaborative work. For several classes of application, Munich basically came to the realisation that to make Linux work for it, it would have to permantently invest in its own team of programmers and maintainers in addition to its existing IT staff (who also had their own grievances regarding provisioning and monitoring). It was a buy/build decision, and the real costs of “build” were now known to be far higher than simply paying for a ready-made product. After all, the city doesn’t build and maintain its own trams - the latest lot was bought from Siemens - so what made software any different?

Other organisations have fared better with Linux, however, but they were more pragmatic: adopting it where it was a viable and mature alternative. The mistake Munich made was the (ultimately ideological) decision to do a top-to-bottom replacement of every software system with a FOSS alternative. That really makes no sense - you might not like Exchange, but is there really a FOSS alternative that’s anywhere near as good at managing office communications?

Re: Ours

The meaning of that original statement is very clear: all of the UK Conservative Party’s bleating about being the defenders of British industry, and all of their anti-foreigner rhetoric pales into insignificance when presented with the opportunity to earn quick cash (and pocket a personal payoff as a consultant after retirement).

Re: Fast chargers

Everyone homes in on DC fast-charging because it looks most like the way you fill up a petrol car, but it’s really not how the majority of EV recharging will happen. Private cars spend 95% of their time parked, so given the ubiquity of electrical supply, that parked-time is when they will charge. Any residence with a driveway can use AC home charging at 7kW (rising to 22kW in countries with 3-phase domestic supplies), which is cheaper and more convenient than forecourt charging. AC charging can be rolled out across pay-parking facilities, commercial premises and workplaces too without much techical difficulty. On-street charging is still a challenge, but it’s a very solvable problem: the difficulties are mostly political and commercial, not technological.

You say filling up with petrol is “convenience”, but is it really? Having the car charge up overnight — or while you do your day’s work— is in a different league when it comes to convenience: just unplug, and go. No wasting your time detouring to a station, or queueing at the till... and it’s cheaper too.

The only place where fast-charging becomes relevant is for very long distance journeys (exceeding 75% of your battery’s range). But with current capacities, those journeys are very rare. Yes, there are people out there who have to drive more than 200 miles at a go, but they really are outliers. For them, a diesel car is still the best option, but eventually EVs will catch up there too.

The electrical grid is entirely able to accommodate EVs. Demand on the grid today is not in any way constant, and it has to be able to operate at a peak that is far in excess of the normal loading. Nightly charging actually solves a problem that has plagued electricity generators since Edison’s day: the most efficient way to operate most types of generation is to run them continuously, but demand fluctuates wildly over the day and week, and if you over generate, you have to dump the power.. (Search for “duck curve”, and follow the articles you find to learn more about this topic).

EVs actually help the grid. They aren’t steady-state dumb-loads, they have intelligence, and are all capable of negotiating with the supply (the charging connector has a serial datacomms link, and the protocols used on it include a Vehicle-to-Grid facility). Right now, you can schedule cars to take electricity at any time of your choosing (to reduce your home bill), but there’s no technological impediment to prevent the electrical utilities and vehicles negotiating their charging periods to react to instantaneous power surpluses in the grid. There’s also the prospect of using your EV battery as a domestic demand buffer, for which the utility will reward you with cheaper electricity.

Regarding capacity, it might interest you to know that domestic electricty demand peaked in the early 1990s, and has declined since (Datacentres have picked up some of the slack, but not all). A lot of infrastructure was put in place based on that level of demand, and mass adoption of EVs will just bring things back towards those projections.

But, it’s not like grid infrastructure is immutable once installed. Unless you’re misfortunate enought to live in Texas, the electrical grid is constantly maintained and expanded to meet demand for electricity; and it’s not like a hundred million EVs are just going to wink into existence and plug in next week: the transition will take decades, and decades is long enough to adapt any grid.

Re: Fahrenheit? More Precise?

True, although once we’re being technical, I’m sure you remember that water actually freezes at its triple-point, which is 0.01 ºC (273.16 K), not zero, and that the boiling point is only 100 ºC at 1013.25 hectopascals of air pressure (= 1 atmosphere); in a hard vacuum, pure water has no liquid state, and so boils at any temperature over its triple-point, and freezes at any temperature below.

Re: Fahrenheit? More Precise?

We have decimal places for when we want to be precise. There's no need to convert out to an odd-shaped unit with an offset baseline.

Re: powershell command missing

The bash solution becomes ugly very quickly once your needs diverge from "results sorted by directory size". The PowerShell version, on the other hand, is trivial to adapt to sorting by any attribute of the system.

You can also trivially adapt the PS version to give you sizes, sorted by most-recently modified directories, or excluding directories that have not changed since a given date. Try that in a bash one-liner if you really want to learn the darker corners of bash (but really, don’t do it: complex functions belong in scripts, not one-line alias macros)

Lest I be accused of fanboyism, I should mention that I don’t use PS very much: I overwhelmingly write scripts in bash (or more accurately, the subset that’s approximates the original Bourne Shell - a habit formed from writing for embedded systems using dash and other lightweight shells). But I’m not some kind of idiotic zealot who thinks that just because something is from Microsoft, it’s inferior to whatever came from Unix. The reason I don’t use PS because it’s not well supported on Linux, where I do most of my scripting; and on Windows, its default commands are all different to what I know from Unix.

But if you’ve ever had to parse the crap emitted by linux tools like ip, you'd wish that Linux had something like PowerShell’s object-stream approach to pipelines.

Making the most common Linux tools produce key-value output (even if it has to be in a lousy format like JSON) would be a start, but that requires cross-project collaboration, which is something the Linux world has proven to be very bad at.

Re: I would get it fired for inventing Powershell

I suspect you don’t do much shell programming. Consider this bash snippet:

X=009

test $X = 9

... should that return true or false? It returns false, because '=' compares text. There’s a difference between lexical comparison (characters must all match) and value compare (parse to numeric, then numeric results must match), and numeric comparison is what -eq, -le, -gt and company do on the unix `test` command ([ is an alias for test, chosen to make shell-scripts a little more readable).

Powershell is similar, but you first need to know that PS is a typed runtime (like Python). The equivalent code:

set X 009

if ( $X -eq 9 ) { echo "true" }

will report true, because X is a number. Change that initial assignment to be a string, and the comparison now fails.

set X "009"

if ( $X -eq 9 ) { echo "true" }

If you want to force integer comparison, you can cast the operand:

set X "009"

if ( [int]$X -eq 9 ) { echo "true" }

It would be a massive reduction for Ireland, given that so much of the DC equipment located in Ireland is providing services for EU and global customers.

The uptick in demand is one of the knock-on factors of Brexit. EU customers want their data-processing to be carried out within the EU. Most of the transatlantic fiber makes landfall in the British Isles, but with the UK now outside the EU, Ireland has become a preferred location, despite its thorny planning process.

The usual suspects will say this is all about tax rates of course, but datacenters are cost-centres, and their location has nothing to do with where profits are booked. Amazon, for instance, located is first AWS Europe region in Dublin, but it has no business operations in Ireland at all: even its shop website is a redirect to amazon.co.uk. Amazon’s European operations are run by a Luxembourg company.

I suppose when you got a laser printer, you started to print all your documents at 3 point text too because you could...

Resolution is not the same as size. Bumping up the number of pixels on your display doesn’t give you more space to lay out your work - or improve your eyesight. And making the display itself bigger also comes with a penalty.

First off, the limiting factor for information density on any interactive display is the human operator. Text needs to be large enough to be clearly readable at the typical viewing distance. That means larger type size (in pixels) and greater line-spacing. The reason your modern UI’s default settings on a 4k monitor still uses the same physical character size today as a VT100 (around 2.0 x 3.5 mm) is because that character size was not pulled out of a hat; it is the result of detailed study of human vision and ergonomics.

UI controls also need to be larger, but for a different reason. Monitors have got bigger physically. Whereas twenty years ago a single 17 inch monitor was the norm, and 30 inch the practical limit, now that norm is 24 inches, and the maximum can be multiple 35-inch displays. Because the distance you have to move the mouse cursor can now be much, much bigger than before, it is much harder to accurately position that cursor on buttons that are further away - so because the average display surface areas get bigger, the controls must get bigger too for the system to remain usable. (The theoretical basis of this has been understood since the 1950s, see https://en.wikipedia.org/wiki/Fitts's_law)

But the problems with this KDE release aren’t density, but misunderstanding of the rules they’re working with, and instead aping the mistakes made by an existing popular system (the fallacy of assuming that popularity means high quality). They have made the same mistake that Apple made with iOS7 when they tried to copy Windows Phone’s minimalist UI - they went too far, and simply removed all the button-borders and other visual signifiers from their UI without providing anything else in their place. The result is a mess.

Windows Phone gets a lot of blame for this, but it’s misplaced. Anyone who has actually used a Windows Phone device will tell you that its UI may have been flat, but it was still distinguishable: yes, there were only a handful of visual cues, but they were used consistently across the whole UI - and the Windows Phone UI did feature boxed buttons; frameless buttons are an abomination that the world can than Apple for. As an example, colour was consistently used as an interaction cue: pretty much any text drawn in the UI highlight colour would react to touch - Apple badly broke this basic rule when it did iOS 7, indiscriminately using colour both as a decoration and as a interaction cue. The irony that it was Apple being so ignorant of basic design principles isn’t lost on this ex-employee, but that’s what you get when you fire all your UI designers (the Human Interface Group was closed back in the late 1990s) and expect graphic artists to have the same skillset. “Looks like” is not “works like”

Re: Let's Qualify that 5.5GHz Figure

Yes, it was fine when the node measurement was just something that was used internally at the fabs, but tech bloggers with not quite enough knowledge have unfortunately turned it into a Holy Number. No surprise, as we’ve been here before several times with “numbers”, most recently with the confusion about high versus low TDP, cores versus threads, 64-bit versus 32-bit, and of course, the granddaddy of them all: Megahertz.

Alder Lake is built on what, until very recently, Intel called its “10 nm Enhanced Super-Fin” process. Despite having that “10 nm” in its name, this is actually able to pack more gates onto a die (100 Million transistors per square mm) than the slightly older TSMC “7nm” process (92 Million transistors per square millimetre) that AMD is using right now.

However, TSMC has a newer “5nm” process (albeit only for ARM SoCs) that packs in around 165 Million transistors per square millimetre, and Intel has no answer to that until its “Intel 4” process starts up, allegedly later this year, with an expected density of around 180-200 Million transistors per square millimetre. In other words, when it comes to wafer fabrication, whoever has the newest thing has the best thing.

But AMD is expected to jump to that TSMC 5mm process later this year, and so will take back the process lead; Intel’s first “Intel 4” CPUs, meanwhile, will be “Meteor Lake” in mid-2023.

Re: I saw the reveal presentation, and, while I'm no fanboy, I was amazed

My experience is different: I have upgraded RAM in every system I’ve ever owned, both Mac and PC (my last Mac laptop, a 2015 MacBook, had a RAM upgrade in its lifetime too). It’s the one thing that I do tend to run out of in my workloads, but then, I had a period of developing systems that required a lot of containers and virtualised systems, and they tend to consume lots of RAM.

Storage is another thing that I have always ended up upgrading, but then it has been for speed (SATA 3 to SATA 6 to NMVe), rather than capacity. I don’t think I’ll need more than 1 Tbyte onboard for a long time to come.

The issue of expandability came to my mind because I have just replaced my own desktop system, and I fitted it with 32G of DDR5. I may end up needing 64G in a year or two, but the price of DDR5 is so crazy right now that it just wasn’t financially sound to buy that much until I really needed it. By then, the usual pricing curve for electronics will make it much cheaper for me to upgrade. Apple’s design decisions with the M1 chip take that option away from me, and I find that position difficult to swallow in something that claims to be a professional tool.

Re: I saw the reveal presentation, and, while I'm no fanboy, I was amazed

You’ll hit that RAM barrier pretty quickly, though, and then you’ll have nowhere to go except sell and replace. If you’re a professional, your time is your income, and the downtime of buying and setting up a new system compared with unscrewing a panel and adding DIMMs is significant.

That’s my big problem with these: you’re basically given a choice of grossly overpaying for the memory you’ll need over the unit’s lifetime, or ending up at a dead-end. Also, at 128 Gbyte, that maximum memory purchase isn’t even that high.

That inability to cost-effectively expand means that this isn’t a professional system; and the specifications are more than any regular user could ever find a use for - the only mainstream high-performance computing application is gaming, and there’s almost no Mac gaming market. Even if there were, games require GPU rather than CPU muscle, and the M1 Ultra is nowhere near as competitive as a GPU.

I think that’s why the response to the M1 Ultra has been so muted. It’s great, in theory, but who would actually buy one? At the other end of the range, I also feel that there’s too much of a gap between the Mac mini and the entry-model Studio: the entry Studio model is nearly double the price of the top mini.

Those industries are supposed to buy the Mac Pro, which can accommodate 1.5 Tbyte of RAM.

I say “supposed to” because pricing on Mac Pro lives in its own private fantasy-land - anyone paying €6k+ for a quad-core Xeon 3223 and 32 Gbytes of RAM would need their head, and/or budgetary approval privileges, examined.

Re: My favorite irony…

These huge LED-matrix displays are normally driven by Windows, because the makers of the display controller hardware only supply drivers for Windows systems; even getting Linux drivers for these things is hard: the OS licence saving is a pittance compared to the complete cost of the rig, and Linux requires a lot of tuning before it will work acceptably with this kind of real-time processing.

But even if it was a macOS system, it would not be Apple hardware (you need a full, multi-slot PCI chassis, which Apple no longer makes), but Apple themselves would still have to take responsibility for keeping the hardware drivers up to date. That’s a lot of effort for one single installation.

But if you’re looking for more examples you can go further down the chain: All of the high-tech automated assembly of Apple’s products is controlled by Windows PCs, because that’s the OS that all the the equipment used in PCB and computer-controlled manufacturing runs.

(Why is this? Well, apart from cost, there’s long-term support. I once had a client who came to me for advice for his business which sold a very expensive piece of specialist machinery built around a MacOS-based controller. When Apple killed support for CarbonLib, in which all of the control software had been written - for performance reasons - it became impossible for him to source new controllers, as the new macs would only run versions of OSX that did not support Carbon. Remember, you cannot legally run OSX on generic Intel boards. My advice was to hire someone to rewrite everything on Linux, by the way. “Rewrite everything” was exactly not what he wanted to hear, but it was the only way out of the trap.)

But none of it matters. For a long time, most of Intel and Microsoft’s advertising and promotional material was produced on Macs. I was an Apple fan in those days (partly because the systems were good, but also because, as an employee, I was able to buy that quite good hardware without paying the full, extortionate, prices), and this fact used to raise a smile, but really it did nothing to convince people using Windows systems that Macs were better. The same goes now, in reverse.

Re: Apple dumbed down and threw pros under a bus

No, he means video and audio. Avid Composer launched on Macintosh and was Mac-only through most of the 1990s; basically the time it took to become the preeminent non-linear editing system for video production. Even today, people in film and TV production will use the term “Avid suite” as a generic term, even if the actually software is a competitor system such as DaVinci Resolve or Adobe Premiere Pro.

Part of the reason for this early advantage was that all Apple systems (until the Macintosh 4400 and later, the iMac) supported SCSI hard-drives. That higher throughput and ability to attach up to 6 external drives was essential if you were trying to do video editing in the 1990s.

I used to work at Apple in the late 1990s, and audio-video production, pre-press and education were the only markets where Apple desktops still had any traction, and it was a big worry when first Adobe, and then Avid started to produce Windows versions of their flagship products.

Apple did purchase Final Cut to keep a foot in the game, and while it had initial success at the higher end of the market, Apple’s lack of competitive workstation products throughout the 2010s meant that it has now slipped into a kind of “prosumer” space, with most large productions moving to Windows-based systems, which offer much greater flexibility (and value for money) in terms of the hardware you can run them on.

Re: Seduced and abandoned by yet another attempt at a non-x86 Windows?

They was indeed a PowerPC build of Windows NT4 Workstation (for devices conforming to the PowerPC Reference Platform, so it won’t work on Apple hardware). I worked for Motorola at the time, and NT was one of the options available with its “PowerStack” PPC workstations..

Re: Notably missing in action...

That’s the problem everyone has on Linux. There is no native UI, just a half-dozen pretenders to the title of “Linux UI”.

I have faced it in my own work over the years: you start a project, and you first have to pick a UI library - a task that itself robs you of time, as you try to pick the facts out of various fanboy postings on the web. I’ve often regretted decisions that I made, or had forced on me, at project outset (e.g., the arse-pain of having to wrap existing datatypes in gObject boilerplate just to be able to have custom list-item views* in GTK+, or every single aspect of using Enlightenment).

In the end, I settled on Qt for Linux GUI work, but it took a lot of dead-ends to get there (and did I mention the living hell of having to write a UI in Enlightenment?).

Ironically, Windows suffers the same problem right now, with multiple competing UI kits leaving developers completely at a loss about what they should use for a new project (UWP, MFC/WPF, Win32??? Dammit, just tell me I have to use one, and I’ll use that, but you’re making me learn multiple platforms just to discard all but one of them). At least .Net 6 is fixing that issue.

__

* yes, this GTK+ example is probably over a decade out of date, but I have not forgotten how unpleasant, error-prone and time-consuming a task it was to do something so basic, and as a result, I resolved to never use GTK+ for a new project again. That’s another example of why this problem is such a problem on Linux: because there are so many other options, I bailed out on GTK+, rather than pushing the developers to fix the ball-ache, or writing a utility library to do it for me. As a result, the development of the toolkit slows down, and everyone ultimately loses out. And it’s the same for every library.