They sold AI giants enterprise downloads in order for them not to hammer Wikimedia's infrastructure by downloading bulk data the usual way available to everyone else. You really have to twist the truth to turn it into something bad for any of the sides.
There are a massive amount of new EVs in Quebec, which isn't exactly tropical. Part of it is subsidies, $2K for new EV, and $600 for charging. The other thing is the crazy scale of hydroelectric production in that province, some of which gets exported as far as Baltimore. So electricity is very available and reasonably cheap in QC.
We'll see how BYD's handle the bone chilling Montreal winters... Unless they're an absolute flop, I can see some fairly solid future prospects.
(I live in Ontario, but I've been to Le Belle Province quite a bit ;) )
As an EV driver from Ontario it's amazing crossing over, or even getting close to the border, the EV situation is just so much better.
That said, while hate Tesla the company ... I'll take their chargers over the patchwork of various apps & cards I have to install in order to make use of things there. There's a notable absence of Tesla stations there, but a lot of variety of other things and I had bad luck installing half the apps and it was not fun trying to set that all up while standing in the -20C cold in a gas station parking lot while just trying to get to the ski hill.
The vast majority of Canadians live near the US border. The weather is not tropical but it is quite normal compared to a lot of US states and northern Europeans.
EVs and cold climates are a bit of a mixed bag. On the one hand, if you want to road trip with snowy 30 mph headwinds, the charging times will be meaningfully worse. Not impossible, but definitely noticeable.
On the other hand, the traction control is fantastic and they tend to have the best preconditioning features so that you never have to get into a cold car for your commute.
For a lot of people, that second paragraph is far more important than that first for at least one of the cars in their household inventory.
I (Canadian) drive a Polestar 2. Chinese manufactured car by Chinese company Geely (tho with Volvo DNA).
It's the best winter driving car I've ever owned. A set of Michelin X-Ices on it's amazing. I've been driving for 35 years and I've never driven something with better winter handling, including Subaru I used to own, etc.
One of the more popular locations for the Ford Lightning is Toronto. They seem to do fine. Canadian politics echoes American politics a bit, but they are not quite so ideological about EVs as we are.
I considered it outdated back in 1993, when all major GUI based systems (Apple, IBM, Microsoft) were going with C++ for userspace applications.
Then came the rise of FOSS adoption, with the GNU manifest asserting to use only C as compiled language.
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."
For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.
I'm confused. What is a matter of skill? You linked 6 hour livestream where person is working on translating AVR assembly to 6502. What was your point, that translating assembly or executables to another architecture takes a lot of skill? Yes, it does!
Because I could not, by scrubbing that video, find anything where immense skill is used to deal with the enormous overhead that standard C++ forces on every program that uses it.
It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable.
By the way, the famous Arduino and ESP32 hasve no problem dealing with C++.
As we also didn't, back in MS-DOS, with 640 KB, Turbo Vision and Borland Collection Library (BIDS).
> standard library isn't a requirement for each executable.
So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries.
It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions and most of standard library. If you need to implement your own STL subset to satisfy the library, then modify the library to work with your STL, the resulting API is not much of an API, is it?
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding.
It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.
C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library!
You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!
These are great, thanks!
That GBA "butano" compiles with -fno-rtti -fno-exceptions, so it is not a C++ engine/library according to C++ standard! It is, however, an impressive piece of work.
The ESP32 SDK (I lol'd at your "even", those Xtensa/RISCV chips can even run linux kernel!) is extremely impressive - they support enabling/disabling rtti and exceptions (obviously disabled by default, but the fact they implemented support for that is amazing). So "real C++" is possible on ESP32, which is good to know.
For comparision, here are the minimum SQLite dependencies from the submitted article: memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()
Of course you could run javascript and erlang on MCU too, but is that API better than C? Your claim of "skill issue" sounds like RedBull challenge. Please let us unskilled people simply call library functions.
Helium is based on ungoogled-chromium. It enables manifest v2 by simply reverting some code changes made by google. So, if google decides to remove manifest v2 wholly, helium will also lost its ublock original support.
Removing all manifest v2 support is also a code change that can be reverted. Of course, the larger the change, the more work it's likely to require to maintain it in the future.
reply