Montreal and Toronto do get around 26% more sunlight than London, in terms of hours per year, but London doesn't really have winter either. They don't get 85 inches of snow per year like Montreal.

Canada's power already comes from renewables as a strict majority: 57.4% from hydro, 9.1% from other renewables. For the clean-but-non-renewables, you've got nuclear at 13.5%. The vast majority of the rest is natural gas. But hydro can be difficult and expensive to expand (even if it's cheap in the long-run), and many renewables other than hydro struggle to serve base-load applications.

At least in my neck of the woods, we have ZERO spare water. We're in a 'negative water' situation. Using any water is a problem. That makes the narrative that data-centers are 'water hungry' very effective at causing unrest.

And many places where they put them up, they don't have enough power infrastructure either. So power bills go up as well.

Well, not just one young arrogant engineer, also most of the maintainers of the major Linux distros in the world.

If it's really a bad idea, the blame doesn't really fall on Poettering. Many young, arrogant engineers have built things that were stupid, and their things got ignored by the world. Some smaller number of young, arrogant engineers have built things that were stupid but were able to convince their PHBs that they weren't stupid and they got deployed. I don't think that's how I'd characterize the leadership at Red Hat (I never worked there, but I have good friends who did), but let's suppose that they were clueless and that's why they deployed Poettering's stupid idea.

But then how do you explain why so many others looked at it, experimented with it for a few years, and then decided to adopt it, and even extend it?

The systemd opponents are loud and forceful on social media. The people who actually build the systems, however, disagree. And It's not just one or two groups who are somehow beholden to Poettering, nor is it people who don't know anything or have no technical stake in the decision.

You might want to consider whether you're living up to your nick here.

I don't personally care that much. I find it mildly annoying that the old scripts my finger muscle memory still wants to type by default don't always work... but honestly I rarely need them any more, because my systems Just Work. And I have to consider the possibility that systemd is part of the reason Linux requires so much less maintenance than it used to. There are multiple contributors here. A lot of it is that drivers have gotten a lot better and other aspects of the system have matured (like the audio subsystem :^)).

But given its broad adoption by nearly all open source and commercial Linux distros, Occam's razor says that it's probably better than sysvinit. Or BSD init. Or Upstart. Or OpenRC, or... <insert favorite system manager here>.

There's nothing in Linux that demands you use SystemD. You can choose to use SysVInit if you really want to. Indeed the only kernel requirement is something called "init" is either in /, /bin, or /usr/bin

But the init scripts are really just faking what init was doing - watching processes and restarting them as necessary. The SysVInit scripts are a crude re-implementation of inittab.

Appropriateness of the response to the emergency is part of the legal considerations. Congress granted the power for a reason. Taking that and assuming it means arbitrary power is not operating within the law, not for Trump, not for Biden.

In what way? Please correct me.

Bah. If a human driver increased their safety and reliability by avoiding certain situations, would you call them a worse driver for it?

They provide full access to the regulators, and they've allowed academic researchers full access. Putting it all online would be more transparent, but they're a business and they have up and coming competitors.

C doesn't have strings, but sometimes people like to have some bytes with a 0 on the end. Some of the memxxx() functions are useful with C's fake strings. For example, memchr() is good for when you have a null-terminated string but it also some upper bounds. And stuff like strncpy() doesn't appear to have anything at all to do with null terminated strings, and is grossly misnamed.

strncpy() copies a string to another location stopping when it reaches a NUL or the end of the buffer.

The problem is the second case doesn't NUL terminate the string so you either have to make the buffer one smaller and terminate always or terminate always. Or try to handle it. The other problem is 'n' is unintuitive - it's the size of the buffer in characters. Easy peasy with 8-bit chars, not so much for Unicode strings. (UTF-16...)

I've personally be more of a fan of the BSD "l" versions - strlcpy and strlcat - both take the size of the target buffer in bytes - so a sizeof() is the proper way to use it, and both properly NUL terminate the string. strlcat has the added benefit that it computes the size it needs to copy based on the existing length of the string, so you can use strlcat() to concatenate a bunch of strings without computing the remaining buffer sizes (as you would in strncat). Luckily the BSD versions are in libbsd because they aren't in Glibc. Much nicer and much easier to use functions.

On the other hand, any city resident who has ridden a city bus and been robbed or assaulted would probably vote for it in an instant. For that matter, any KC official who had been similarly victimized would probably do the same.

It is very easy to take the moral high ground in situations where you will not be affected by those policies. It is a different matter when you are one of rank and file who ride the bus every day.

And how often does that actually happen? Because it's a super common myth perpetuated by those who want a car-first lifestyle that public transportation is unsafe to promote their vehicles.

And yes, it does happen. But you know what? We have surveillance cameras already on buses and other public transit. Taxis have dashcams that face both ways.

And this has been true for decades.

The only difference now is facial recognition, which we already know is already problematic and full of false identification. And if necessary, people do run facial recognition on the surveillance video all the time - be it from a bus, workplace, public street, business, etc.

The car equivalent would be to put up more license plate readers everywhere snapping photos of everywhere you go. But we already know how that's going, and really, this should go the same way as well if you dislike license plate readers.

The difference is you were buying a license. The software maker couldn't really revoke your license to use it.

With PlayStation, Steam, etc., you aren't buying a license. You're renting one. That is, you get a license to use the software, but PlayStation, Valve, Microsoft, etc may at anytime decide to revoke that license from you for whatever reason. So at best, it's a long term rental without a clear return date.

And all the other stuff relating to owning the license versus renting the license - like being able to transfer the license to someone else. If you owned it you could sell it to someone else (e.g., "used games"). Something PlayStation pummelled Microsoft heavily on, even though Sony never really intended to follow through since they pushed digital sales harder.

It would be quite useful to have a database to search and find out what devices I own have been shown as guilty.

The problem is that it varies a lot. And basically it comes down to names - things that require internet access especially.

Things like streaming boxes - if you buy one of those questionable boxes at the mall that claim "never pay for cable again" and such, whilst offering full access to paid content, those may or may not come with a side helping of a VPN endpoint. But it's hard to say because the manufacturers of those boxes make them and put in clean firmware, and other companies buy them up and modify the firmware with their pirate apps and then add other stuff in as well. So you can buy the same box from 10 different vendors, have 10 different firmware on them, and 7 of them have the remote access service on them.

Likewise, that IoT camera you buy may come clean, or may have passed through a dozen hands which may have altered the firmware to add the remote endpoint into it. But again, the same problem remains - the camera is sold with a dozen different firmware from a dozen different companies.

And yes, isolating them is the first step because the remote endpoint software is just a VPN endpoint software - it allows some user to use your device and internet because it's endpoint software.

I grew up in a country that adopted PAL rather than NTSC, so never saw the hue and saturation settings until my family relocated to Canada. I was baffled by how backwards NTSC was.

NTSC is only backwards if you consider it had to work with TV standards that were around since the 1920s or so. It was nicknamed "Compatible Color" because its signal format worked with existing black and white TVs just as well as color TVs. The only change was a slight slowing from 60 fields per second to 59.94 (1000/1001) to accommodate a few cycles of the color carrier.

PAL came afterwards as a full color standard from the get-go - there were other TV standards but all incompatible. TVs that could not display color dropped the color information but it was there and didn't have to be worked around.

PAL worked through delay lines on the color carrier which meant the color sync would be locked on because the color carrier would be present. NTSC didn't have this luxury and the only color sync available was the color burst signal which meant you synced a clock to it, and that clock was used to figure out the color carrier. As the clock drifts through the field (because all clocks will drift) the color will drift as well because the color information is based on the phase difference between that reference clock and the signal. But since the clock drifts, the phase does to. The tint control adjusts the phasing of the signal.

Since PAL had an AM carrier it could be synced. NTSC had the carrier suppressed.

It should be noted that other than timing and the phase alternation, the TV signal formats are basically identical - an NTSC TV will be able to view a PAL signal, but in black and white as the color carriers between NTSC and PAL are different (3.58MHz vs. 4.43MHz) so it won't be able to actually get the color signal.

In Asia, multi-system TVs were basically standard - they could receive NTSC with 3.58MHz color carrier (North America, most everywhere using NTSC), NTSC with a 4.43MHz carrier (basically Japan, sometimes noted as NTSC-J), PAL and SECAM (both using a 4.43MHz carrier). The only real difference is the electron beam timings and how to decode the color - where the carrier is, and how to sync to the carrier - using an internal oscillator (NTSC with colorburst) or an external carrier (PAL/SECAM). Other than that, the information is identical.

And yes, you can run into this if you stick a PAL VHS tape into a NTSC VCR or vice versa. You can get a recognizable picture, though the timing might be off so your TV might be unable to sync properly. (VCRs only have a single sync source - the horizontal sync and the head reads the signal from there and each line is read at output at the appropriate rate).

With the right hype, and a high enough price tag on the machine, the coffee snobs will be all over this.

Well, cold coffee drinks are popular these days. An espresso that is made at room temperature means you can make a cold espresso drink much quicker and with less energy since you don't have to boil water only to cool it back down again.

This would be something you'll find at Starbucks, fine purveyors of sugary coffee drinks. Honestly, they aren't far removed from soft drinks nowadays given the amount of sugar in them. Especially their cold coffee drinks. Cold espresso mixed drinks? Sugar bomb

Do you honestly believe that mass debt forgiveness -- after COVID was already over! -- was a necessary emergency response to the pandemic? Suspending payments (and interest) during the pandemic made perfect sense, and that was not struck down. I don't recall that it was even challenged.

No, the debt forgiveness clearly had nothing to do with the (already-ended) emergency, it was just an attempt to skirt the law, and the courts were quite correct to strike it down as executive overreach. If Biden wanted to do that, he should have lobbied Congress to change the law. He didn't do that, of course, because he knew Congress would refuse -- even though his party held both houses.

Your comment mischaracterizes what has happened. The Supreme Court has absolutely bent over backwards to let Trump do what he wants in temporary rulings, including jumping in to to stay lower-court orders that no previous court would even have responded to. But their on-the-merits rulings, when they have to issue a full opinion, have been much less friendly to Trump. There have been some incredibly bad ones (e.g. immunity) but Trump has lost more than he has won in SCOTUS final judgements.

You're treating the current law as a standard handed down from on high, incontrovertible and guaranteed-correct, which must be applied verbatim. And, indeed, laws must be applied as written... but that doesn't mean the laws are perfect forever. Laws are written within a context, and when the context changes, the laws have to change.

In a world where all cars are driven by humans, if you want to protect highway workers one way to do it is to attach serious prison time to killing one and to publicize that fact loudly so that all of the drivers know that they should be especially cautious around highway workers, even more than they would around other sorts of pedestrians (let's put aside the moral debate about whether we actually should protect highway workers more than other pedestrians).

In a world where some cars are driven by software systems, that strategy doesn't really work -- as your question correctly points out -- but the right conclusion isn't "Therefore self-driving cars shouldn't be allowed", or "Therefore we must identify some scapegoat human at the company to put in prison". The right conclusion is "Therefore we need a different kind of regulation to keep highway workers safe from self-driving cars". What should that be? I can think of lots of possibilities, both pro-active (e.g. require self-driving vehicles to demonstrate in rigorous testing that their vehicles stay far from highway workers, with whatever minimum distance you want to specify) and reactive (severe penalties, up to heavy fines and/or immediate loss of permission to operate). The point is that the law should choose an approach that works with the new context.