Actually it was funded by throwing taxes and other punitive charges on ICE vehicles that EVs were exempt from and then using the money to build out EV adoption. And yeah Norway has some oil wealth that contributes to the balance sheet but it's not ringfenced and NOBODY is denying it contributes to climate change. The reality is Norway is a sparsely populated country with some cold and extreme weather and lots of road and yet somehow manages to adopt EVs. And the simple reason is they planned to do it and followed through with the plan.

The problem is not the means it is the will. Norway made it expensive to own an ICE vehicle and incentivized EV adoption. So now nearly all new vehicles sold are pure electric (with a few % PHEV) and there are chargers everywhere including communal ones. Likewise virtually every EV country and the UK has incentives and schemes to push EV adoption and the buildout to support it. It's not perfect and some countries are behind the curve but its happening.

But that requires joined up thinking. The US does not do joined up thinking.

This is a chicken and egg situation which is easily resolved with legislation. The government mandates that apartments, supermarkets and other car parks gain charging spots. They mandate new builds have chargers as part of construction sign off. They offer grants and retrofit assistance for existing properties and private dwellings to install chargers. They mandate that there be superchargers every X number of miles along designated motorways and major roads. Basically they use law and taxes to progress things in the direction they wish things to go.

This is what any sane country should do. But the US is not sane. Some states might do some of the above but then there is the federal (lack of) initiative made worse by having a senile asshole in power who hates renewables and electrification because of a windfarm dispute at one of his golf courses.

Actually it's not the "most likely thing". The most likely thing is these cars will function perfectly normally and unremarkably and the brand will establish itself in the market alongside other brands. And since BYD offers an 8 year warranty on their batteries, it would prove very costly for them if it was anyway different.

I've tried it and I don't think it's any quicker than launching VS Code or IntelliJ which properly graphical editors rather than a text console with a toolbar and menu on top. The GUI is incredibly janky too and bogged down by Emacs' arcane terminology. A window in EMACS is actually a panel in the existing window. A frame in EMACS is actually a whole window.

I think because it hasn't embraced the move to proper graphical editing it has become a relic. Anyone in a GUI will use a graphical editor. Somebody in a console *may* use it but more likely they're hopping into a console to do a quick edit and would choose a faster tool like nano.

Yes but people do and companies selling agentic AI are encouraging that they do.

But I'm not a customer of Bank of America or any American bank so I don't quite understand the description that goes with this story. I thought every bank uses MFA - pin readers, authenticators, biometrics, email / SMS verification etc. in addition to username / password. I assume Bank of America does too, in which case even stupid customers should be protected. But maybe it doesn't.

Perhaps banks should also figure a way to allow customers to use AI if they want, e.g. issuing some kind of limited purpose token that an agent can use according to some max spend / txn limits, that the bank might even randomly challenge and seek authorisation for.

I used it (Gnu Emacs) 30+ years ago when the alternative was vi and there weren't really IDEs to speak of. But these days 95% of the stuff I edit is in an IDE or graphical text editor. If I need to edit something quickly I'll just use nano or vi because they're easier to get in and out of.

Even back when I did use emacs, I preferred microemacs because it had most of the normal commands but loaded faster. Emacs was s..l...o..w. It was also infamously bad for accepting patches, practically moribund in fact. Forks like xemacs demonstrated it was capable of being a lot more, e.g. offering proper GUI support when running in X11, but emacs never bothered with that. Even when I open emacs today it feels arcane, like it just gave up. It does have some GUI support but it's a joke. Frankly it's no wonder most users gave up on it too.

At least in regions like the EU where they are taking EV adoption seriously. Provide additional tax relief or a grant for any car that supports V2H with battery tech that supports the charge / discharge cycle. It means if you have a power cut you can plug the car in to supply the power or even use the car to power the house and lessen the cost (& strain on the grid) during peak periods.

The way I see it is that many websites would be better off with a self signed cert than no cert at all. At least the site traffic is encrypted and a plugin like SSL lighthouse could alert the user if the cert changes.

And a site wants to add trust to their cert then they'd be better off to have their partners, customers, competitors sign their cert than some random CA that nobody has ever heard of. And it wouldn't stop CAs from signing the cert too and perhaps to gain maximum trust in a browser that might still be necessary.

Browsers could show some kind of score / checklist of what the cert says about the site based on who signed it or not. It would still be a better system than the shakedown racket that exists today.

Erm, yes it is and yes it does. At least if you use systemd. And you say "perfectly possible" and yet sysvinit and other systems don't do it.

Your sentence is gibberish. Assuming you mean to say "systemd does not preclude somebody adding security by other means", then no it does not.

But does any sysvinit based dist do it? Devuan, the white knight of the dump-systemd "movement" certainly doesn't. Service sandboxing? Nope. Cgroup process tracking? Nope. Credential handling? Nope. Log tamper proofing with FSS? Nope - rsyslog has some tamper evident features but the capabilities are way easier to set up in systemd. Disk encryption via TPM? Nope. Least privilege? Nope - its all LSB spaghetti code running as a user and no control beyond that.

Devuan admits how terrible it is by offering OpenRC during installation. OpenRC supports cgroups, capability dropping and supervision. But then it runs OpenRC over the same LSB scripts in compatibility mode, so none of that is used. And even if it was used it would still be limited compared to systemd. And it tacitly admit that sysvinit sucks when that was its whole schtick in the first place.

And I don't think people raging about systemd were ever motivated by security, or common sense for that matter. You demonstrated that with your Poettering remark. There are reasonable points of debate / concern about systemd, about overreach, modularity, packaging and suchlike but you're not interested in any of them. Just some kind of irrational fear of change even when it is progressive and beneficial. Almost as though you see a change to a subsystem in an operating system as a threat to your world view. It's very weird IMO.

Fuck all to do with security except all the ways that I stated and that are easy to verify.

Systemd improves security in a number of tangible ways - small commands which do specific & least privilege operations, tamper resistant / journal logging, cgroup process limits, per service sandboxing, disk encryption, credential storage, security auditing tools and more. The sandboxing is probably as close as you would get to OpenBSD's pledge/unveil functionality in a Linux.

Where systemd may not be considered secure is it's certainly not minimalist. It has a lot of commands in that one package. But many of those commands exist to avoid dragging in even larger packages for the sake of using small bits of them (e.g. to set the time without ntpclient), but there have been flaws found over the years.

Linux was NEVER like this. From the early days it was kitchensink mentality - dists would install stuff whether you needed it or not. Dists were especially bad for installing Telnet, FTP, SSH, NTP etc.

It was only when security was taken more seriously that dists started being more selective about what they installed. Most modern dists still have a couple of ports open, mostly locahost only but won't even run SSH unless somebody explicitly chose to install it. There are cut down Linux dists like Alpine which run with almost nothing additional at all and would be suitable for being firewalls, routers and net filters etc.

I think if I were ultraparanoid about security I might still consider OpenBSD, but it has its own limitations in terms of supported hardware & drivers, networking throughput, package support that may prevent it from being viable regardless of how secure it may be.

All that really matters is the content you're trying to play, the DAC and the output impedance. Anything else is basically snakeoil. If Sony is trying to sell this thing based on "oxygen-free copper", or any other weasel marketing terms then it's snake oil. I'm sure that it does have a decent DAC and audio specs, but so do most mid/high tier phones. Anyone paying $2000+ for this is a fool.