a-priori

The goal of MISRA C mostly isn't to prevent problems in your code. It's to make the code more amenable to static analysis, which _can_ detect problems.

That’s great, thanks for the letting me know!

Yes. I don’t know about Windows but I know that for OSX you need to implement the NSAccessibility protocol in AppKit. This gives you a way to describe the hierarchy of the UI and to notify the system of important changes.

Before you start picking up a library like this, keep in mind that no immediate-mode GUI library I'm aware of (including this one from what I can see in the source code) has support for assistive technologies such as screen readers.

To them the whole UI is one big black box, so your program is completely useless to anyone with a wide range of disabilities.

First off I don't recommend implementing the specification from scratch. It is big, and there are implementations already in various languages: for C you can use GNU-UEFI, for example, Rust has uefi-rs, and Zig has support in its standard library. These take care of the fiddly details of interacting with the UEFI firmware's services.

There's tutorial type articles for these around: for C there's https://wiki.osdev.org/UEFI_App_Bare_Bones, for Rust there's this template https://github.com/rust-osdev/uefi-rs/tree/main/template and the crate's documentation.

I don't think the role of firmware requires it to be minimal. It's to provide a consistent boot environment on different hardware, and to provide useful services to the program. Even BIOS-based machines have significant amounts of code that run before they jump to the boot sector, so while UEFI is definitely more sophisticated I don't really see this as a drawback to it.

Yes of course. If your goals are retro computing, yes by all means go ahead and use retro technology.

That's my point though: today, BIOS is retro technology.

I suppose it depends what you're going for, but in general I don't think being able to fully support some very old PCI devices should be the determining factor.

Nowadays, I would recommend not using BIOS booting. Modern machines with UEFI firmware only emulate BIOS anyway, for backwards compatibility with old bootloaders.

UEFI gives you a much nicer initial environment — it's already in 64-bit long mode, for example, unlike BIOS which drops you into 8-bit real mode, with a maximum of one sector in which to perform all the gymnastics you need to do to load the rest of your program and switch to _at least_ 32-bit protected mode (notice how this PDF doesn't even go to 64-bit long mode).

UEFI also gives you better, easier to use boot facilities than BIOS: you can access a memory map, read from the boot file system, switch video modes, and even access network drivers. And you can access all this from long mode, unlike BIOS which only works in real mode. Then once you've booted you can take over the system by exiting the boot services, and have full control over the system just like you want for making an operating system.

What this could be saying is that it’s very inefficient to buy the parts in units. If you were to buy a thousand of these parts, as a manufacturer might, I doubt they’d each cost £100.

They're not 'our version of martial law' because the term 'martial law' has a specific meaning, about suspending civil rights and putting the military in charge of civil security. The Emergencies Act does neither, and indeed no law in Canada allows the government to suspend the Charter.

You're right that we may disagree on some details, but I think where we'll agree is that this should not have been a situation that required a federal emergency. I fully believe this could have been handled just fine at the municipal level and, failing that, provincial level, and should not have required a federal response.

The way I see it the real emergency was that the Ottawa Police and then the Ontario government were spectacular failures, and this created a scenario where, I believe, the federal government was entirely justified in enacting the Emergencies Act and the mandates they did.

But regardless of whether it should have been invoked, what happened was not 'martial law' nor would I call it 'shockingly totalitarian', and that's why I said DHH's hot takes were bullshit.

Let me just say that, as someone who lives in Ottawa, that his takes on the convoy occupation are complete bullshit.

The fact that he describes it as "just three weeks of honking, blocked streets and bridges, bouncy castles and flag waving", then refers to the response being "shockingly authoritarian" and "martial law" is a sign that he doesn't know what he's talking about.

I have a cousin with Down’s syndrome, and he thrived in a Montessori school. So there’s my anecdote.

I don't know enough about what a "balloon mortgage" is to comment on that, other than to say that the 2008 mortgage crisis was not as severe in Canada as it was in the United States.

So, to the extent that mortgage terms were a factor in the crisis, and I don't know whether it was, I wouldn't say that this kind of mortgage was disproportionately worse.

I don't know about Australia, but in Canada mortgages are amortized over (usually) 30 years at first issuance, but they are on (usually) 5 year terms.

This means you'll renew your mortgage roughly five times before it is repaid, at the prevailing rates at that time. There's no such thing here as a mortgage with fixed interest rate over 30 years like, as I understand it, there is in the US.

The factors I came up with, 1200x and 3500x, leave plenty of margin for including more actors if that's the comparison you want to make, while still ending up with more or less the same result.

You don't have to imagine, because VISA is a public company.

According to their 2021 financial report (year end Sept 30, 2020), VISA logged $8.3B in operating expenses. The majority of this is "personnel" at $4.2B (covering the salaries, benefits, etc. for their staff), $0.7B is "network and processing" (covering the expenses to operating their payments network), and the remainder is stuff like general administrative, marketing, professional fees and legal fees. But for comparison I'll use the $8.3B in total operating expenses.

Over the same period VISA processed 164.7B transactions, so if you divide you get that on average it costs VISA $0.05 in total expenses to process a transaction, of which $0.004 is for actually operating the payments network.

By comparison, it currently costs the Bitcoin network $176.39 to process a transaction (transaction fees plus block rewards per day / total transactions per day), over 3500x the expenses of VISA.

Maybe you'll say that's still not the same thing, because "total transaction fees" represents _revenue_ to miners, not expenses. Fine. VISA's revenue over the same period was $24.1B, which works out to revenue-per-transaction of $0.14. That's still over 1200x as much as VISA.

https://s29.q4cdn.com/385744025/files/doc_downloads/Visa-Inc... https://ycharts.com/indicators/bitcoin_average_cost_per_tran...

My wild guess is that the “fly across the room” comes from a spasm in the leg muscles, so it’s more that you involuntarily jump across the room.

I say this as a web developer: there's far more to programming than the web.

I have a family, local connections, etc. In the past year I've changed jobs twice, for a 45% raise in the last 12 months. But because all three jobs over this period have been remote, I haven't had to disrupt my family at all.

Since the last two companies have been headquartered in different cities, this wouldn't have been possible before COVID.

The silver lining on this damned pandemic has been a lot more options for people, like software developers, in the privileged position of being in demand with work that can be done remotely.

On the contrary, this could scale much better.

If the GraphQL server is a separate component, then a GraphQL query needs to do its own query planning, then the resolvers turn that into SQL queries to the database, then the database does its own query planning and execution for each query.

Since one GraphQL query will often turn into multiple SQL queries, there's likely to be duplicated work on the database side across those queries since they relate to the same data.

By integrating the GraphQL server into the DBMS, it can do query planning once for the whole GraphQL query, which means that it can reuse parts of the plan and prevent duplicated work and N+1 queries.

Either way it's going to have to query the database to get all the data, so the essential work is the same. But this way you have opportunities to reduce wasted work to process the whole GraphQL query.

The problem is that the search space grows (exponentially?) as you increase the fuzzer’s limit. So there’s a cost, and likely diminishing returns, to raising that limit.

First step: Do nothing. You've got two working, independent products, and that's okay. You can keep running like this indefinitely so there's no need to rush.

Second step: Figure out what the future combined product/company is going to look like. There's no sense doing any integration work until you know where you're going.

Third step: Form a combined team and come up with a plan to build the new product, reusing and rewriting the existing technology as appropriate. The details here entirely depend on the existing products and the end goal.

Keep in mind this situation can easily become political and toxic -- in fact, I would say that's the default outcome -- and will require strong leadership to navigate well.

The assembly you’ve listed there assumes it runs in real mode and ring 0. You’d need to use virtualization of some kind to execute that.

Ah, here we see the car maker’s version of fizz buzz and whiteboard coding.

They’re just not assuming that all their workers are fluent in English nor French, which 1.8% of Canadian residents are not (according to the 2016 census).

Yes, I recently planned out how to transition a company to a continuous delivery release model, and this was part of the plan.

One thing I insisted on was on building and running playbooks, rather than jumping to full automation from merge to production. This phase was temporary: it might only take a few weeks or months before people will get bored with this and find it tedious. When _boredom_ is the biggest problem you have with a process, then it's time to automate.

But in the meantime, going through these motions manually has educational value, and lets you refine your processes easily.

Automating a process tends to ossify it, and concentrate knowledge about it in whoever creates and maintains the automation. Playbooks distribute knowledge to whoever executes them, and make systems amenable to change.

For my own perspective, I am Canadian and that article is absolutely correct that the term is considered "racially charged" here.

It's also correct that "Inuit" doesn't encompass all Indigenous peoples of the Arctic... but it doesn't have to? I don't see why you need such a term. If you want to talk about the Yupik people, use that term. If you want an all-encompassing term, use "Indigenous peoples".

Even if, for whatever reason, you need a term that includes these ethnic groups, but excludes other indigenous peoples, then why does it have to be "Eskimo"?

As a white person, I'm an outsider to the situation so I'm going to take my guidance from Inuit groups themselves, and they object to the term. There's nothing complex about saying that it's a bad idea to call a people by a term that they themselves consider offensive.

I know the term is in that Pullum essay, but please stop using the term "Eskimo". I know Americans still use it, but it's a racist epithet that really needs to go away.

The people are the Inuit, an individual Inuit person is an Inuk. Those are the terms that should be used.

And likely far more by now, had it become the PC instruction set architecture. The x86 instruction set was also simpler back in the late 70s, in the 8086 era when the Motorola 68000 was first released, than it is now.

Back then it only had the one register width (16-bit, e.g. "ax"), whereas now it has the 32-bit series (e.g. "eax") series and the 64-bit series (e.g. "rax"). It also now has SIMD, SSE/AVX, virtualization support, and other technologies. Back then it just had one operating mode (real mode), whereas now it has protected mode, long mode, system management mode, and a few other intermediate modes (e.g. "unreal mode").

So a lot of the complexity that x86 has now was introduced after that decision was made. It's definitely conceivable that the 68000 line would have developed similarly had it been chosen instead of x86 for the PC.

It’s not much of an “outing” to reveal that I believe the Canada they want is antithetical to my belief system, and that I find the party thoroughly disgusting and worthy of mockery.