MrRadar

My Chevrolet Bolt actually shows me the real-time kW draw from the high voltage battery and, while it's highly dependent on driving conditions, it seems to require around 12-15 kW to maintain 60 MPH on a flat dry road using cruise control and with the climate control turned off. It's not the most efficient model on the market, but it's also far from the least; as you noted your F-150 would need significantly more energy under the same conditions.

As someone who uses Debian for their own home server I was interested in reading this person's experience, but they seem to have filtered it through an LLM which added a lot of words and not a lot of insight making it significantly less readable in the process.

Ultra-low-sulfur diesel became mandated in 2006 as the only type that was legal to sell for road use. That requires extra refining to remove the naturally-occuring sulfur from the fuel which is why the cost went up.

The answer is pretty obviously AV1 if you care about delivering content to actual end-users, unless you expect them to be severely bandwidth constrained such that the ~30% improved efficiency makes a noticeable difference. AV2 is still not mature from an implementation perspective; I wouldn't consider it ready until at least the dav2d software decoder has had time to mature, which the project page implies is still in a fairly early stage of development (they still list "complete C implementation of the decoder" as "on-going": https://www-test.videolan.org/projects/dav2d/) and I am not sure if any encoder exists besides the AOM reference implementation (which was notoriously slow for AV1, so I assume the same for AV2). Furthermore it will be years before hardware AV2 decoders and encoders make their way into consumer products (this will likely be further delayed with the current shortages of memory and storage chips causing hardware lifecycles to be extended even more than they already had been over the past decade).

Why shouldn't they get 6 MHz? My PBS station broadcasts 4 subchannels: the main PBS channel, PBS Kids, a channel with programming about our local region (which airs live coverage of our state legislature when it's in session), and a loop of weather information with audio from the local NOAA Weather Radio broadcast. Those are all useful public services. PBS Kids in particular I think has a very good reason to exist, considering the absolute wasteland that is young children's media on streaming.

IIRC for sugar it's because of cheaper cane sugar substitutes (corn syrup and sugar beets) out-competing the cane sugar grown in Hawaii.

Or they're selling their product to a market where the purchaser doesn't understand how much they would need to pay if they were paying by the gigabyte (or even how to check how much they would need). Telling those people they don't need to worry about that "detail" is a key selling point. Backblaze has a product for people who understand the limitations of their consumer product and don't find them acceptable: B2, which is priced by the gigabyte.

Only the asymmetric portion of the cryptography (which is only used in the handshake) will need to use PQC algorithms. Symmetric crypto algorithms (AES/ChaCha20/SHA-*), which are used after the handshake, are not as badly affected by quantum computing so they're not being replaced in the immediate term. I'm pretty sure that general purpose CPUs do not have hardware acceleration for the asymmetric crypto anyways.

This page lists some figures for ML-KEM-768 (which is the PQ key exchange algorithm that's most widely deployed today): https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519 This one is actually faster than X25519 (a highly optimized ECC algorithm) by about double but requires 1,184 bytes of data to be exchanged per keyshare vs 32 for X25519. In practice everyone today is using a hybrid algorithm (where you do both ECC and PQ in case the PQ algorithm has an undiscovered weakness) so an ECC+PQ key exchange will be strictly slower than an ECC-only key exchange.

This page lists some numbers for different PQ signature algorithms: https://blog.cloudflare.com/another-look-at-pq-signatures/#t... Right now the NIST has selected three different ones (ML-DSA, SLH-DSA, and Falcon a.k.a. FN-DSA) which each have different trade-offs.

SLH-DSA is slow and requires a large amount of data for signatures, however it's considered the most secure of the algorithms (since it's based on the well-understood security properties of symmetric hash algorithms) so it was selected primarily as a "backup" in case the other two algorithms are both broken (which may be possible as they're both based on the same mathematical structure).

ML-DSA and Falcon are both fairly fast (within an order of magnitude of Ed25519, the X25519 curve signature algorithm), but both require significantly larger keys (41x/28x) and signatures (38x/10x) compared to Ed25519. Falcon has the additional constraint that achieving the listed performance in that table requires a hardware FPU that implements IEEE-754 with constant-time double-precision math. CPUs that do not have such an FPU will need to fall back to software emulation of the required floating point math (most phone, desktop, and server CPUs have such an FPU but many embedded CPUs and microcontrollers do not).

The net result is that TLS handshakes with PQ signatures and key exchange may balloon to high single- or double-digit kilobytes in size, which will be especially impactful for users on marginal connections (and may break some "middle boxes" https://blog.cloudflare.com/nist-post-quantum-surprise/#dili...).

Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.

Along similar lines, Mozilla recently updated their recommended server-side TLS configuration to enable the X25519MLKEM768 post-quantum key exchange now that it's making it into actually-deployed software versions: https://wiki.mozilla.org/Security/Server_Side_TLS At the same time they removed their "old client" compatibility profile as newer TLS libraries do not implement the necessary algorithms (or at least do not enable them by default) and slightly tweaked the "intermediate" compatibility profile to remove a fallback necessary for IE 11 on Windows 7 (now Windows 10 is the minimum compatible version for that profile).

Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).

> This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.

Those first three are "enterprise" or B2B applications, where the person buying the software is almost never one of the people actually using the software. This disconnect means that the person making the buying decision cannot meaningfully judge the quality of any given piece of software they are evaluating beyond a surface level (where slick demos can paper over huge quality issues) since they do not know how it is actually used or what problems the actual users regularly encounter.

Every generation of the production Nissan Leaf has used lithium batteries. AFAIK no modern (~post-2000) mass-produced (>10k units sold) EV has ever used NiMH or lead-acid batteries.

Edit: Checking Wikipedia to verify my information, I found out that Nissan actually sold a lithium-battery EV in 1997 to comply with the same 90s CARB zero-emissions vehicle mandate that gave us the GM EV-1: https://en.wikipedia.org/wiki/Nissan_R%27nessa#Nissan_Altra

> Are you saying that if I'm using D-without-GC, I can use any D library, including ones written with the assumption that there is a GC? If not, how does it not fracture the community?

"Are you saying that if I'm using Rust in the Linux kernel, I can use any Rust library, including ones written with the assumption they will be running in userspace? If not, how does that not fracture the community?"

"Are you saying that if I'm using C++ in an embedded environment without runtime type information and exceptions, I can use any C++ library, including ones written with the assumption they can use RTTI/exceptions? If not, how does that not fracture the community?"

You can make this argument about a lot of languages and particular subsets/restrictions on them that are needed in specific circumstances. If you need to write GC-free code in D you can do it. Yes, it restricts what parts of the library ecosystem you can use, but that's not different from any other langauge that has wide adoption in a wide variety of applications. It turns out that in reality most applications don't need to be GC-free (the massive preponderance of GC languages is indicative of this) and GC makes them much easier and safer to write.

I think most people in the D community are tired of people (especially outsiders) constantly rehashing discussions about GC. It was a much more salient topic before the core language supported no-GC mode, but now that it does it's up to individuals to decide what the cost/benefit analysis is for writing GC vs no-GC code (including the availability of third-party libraries in each mode).

Yeah, AV1 is primarily based on what Google was working on for their own successor to VP9, what would have been VP10, with technology contributions from Mozilla/Xiph's Daala and Cisco's Thor codecs.

Seriously. Also less and less software is supporting 7. Importantly, Firefox ESR 115 is the last modern browser to support Windows 7 and it's entering EOL after this month[1]; Chrome dropped Windows 7 support in 2023[2].

[1] https://support.mozilla.org/en-US/kb/firefox-users-windows-7... [2] https://support.google.com/chrome/a/answer/7100626

There is a port of Mbed TLS to Classic MacOS[1] which has TLS 1.2 enabled but per the README.md probably not the right cihper suites (it only has AES-CBC ciphers enabled by default) to connect to servers configured per the widely-used Mozilla "intermediate" recommendations[2] (which require AES-GCM or ChaCha20 ciphers).

[1] https://github.com/bbenchoff/MacSSL [2] https://wiki.mozilla.org/Security/Server_Side_TLS

The Technology Connections video series on RCA's Selectavision CED home video system touches on this quite a lot (it was a horribly mismanaged project which took more than a decade to commercialize, by which time it had already been superceded by VHS/Betamax and Laserdisc)[1]. His main source for the information on the development of the CED system was the book "The Business of Research: RCA and the VideoDisc" by Margaret B. W. Graham.

[1] https://www.youtube.com/watch?v=PnpX8d8zRIA&list=PLv0jwu7G_D...

It doesn't even take destruction of the property to keep media locked up forever, sometimes even just IP rights. For example original Brave Little Toaster film has never seen an official release in HD because it was produced as a joint venture and nobody has (apparently) been willing or able to hammer out a deal between the various rights holders for a new home video or streaming release.

In 2023 a 4K scan of a theatrical print was uploaded to Youtube and despite the slightly rough state of the print it remains the best quality you can view the film today. There's even a pinned comment under the video from the original director thanking the person who uploaded it to Youtube for preserving their film!

A while ago I found a few episodes of a 1950s crime drama/noir series called M Squad (the M is for "murder") on Youtube. I don't recall exactly how but probably because someone mentioned it was a direct inspiration for short-lived Police Squad series and later the Naked Gun films.

Anyways, I went to see if there was an official DVD release of it, and there was but several of the episodes were sourced from off-air TV recordings from reruns in the 1980s because those were the only copies the distributor could find! They were originally planning to release the set without them but asked fans if they could source copies which is how they ended up with those recordings. I didn't end up purchasing it because even the episodes where they had a better quality source weren't mastered particularly well to the point where several reviews said they were borderline unwatchable due to the image getting crushed into murky darkness thanks to the noir lighting and DVD MPEG-2 compression.

COBOL is being actively developed as a language, the latest standard was published in 2023.

The D language basically does that. You can write D programs that evaluate D code at compile time to generate strings of new D code which you can then basically compile-time eval into your code as needed. Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages and it's easier to read than Rust macros or C++ template metaprogramming.

That's C++11 syntax. Before then you'd have to manually initialize them in every constructor, with a hand-written default constructor as a minimum:

    struct test {
        int my_int;
        int *my_ptr;
        
        test() : my_int(0), my_ptr(NULL) {}
    };

Thanks for the explanation!

The article mentions S/PDIF (which TOSLINK is an optical version of) uses Manchester code[1] which eliminates the DC component by ensuring every bit has at least one transistion of the signal between high and low.

[1] https://en.wikipedia.org/wiki/Manchester_code

It's fixed in Debian 12[1]. Debian 11 and earlier's SSH version was not vulnerable.

[1] https://security-tracker.debian.org/tracker/source-package/o...

For how they know where to point, that's something that's calibrated individually for each set. Typically the initial calibration is done at the factory (or, if you've done a major service on a set, by the technician who did the service) and then tweaked by the end-user to their own preferences. That's why all CRT displays have adjustments at least for hoizontal and vertical size and position (offset). Fancier displays have even more adjustments for other geometric corrections like pincushion and keystone.

Here's a video demonstrating how to do a full setup (calibration) on a vintage color CRT (timestamp 16:02 for the start of the procedure): https://youtu.be/Oeylkj1vap8?t=962

In theory the electromagnets controlling the vertical and horizontal sweep of the electron beam should react instantly to the incoming sync signals but in practice it's much more complicated (because the magnetic fields store energy which you need to deal with somehow). Bob Anderson has an entry in his series on the general process of restoring vintage televisions which goes in depth on the topic: https://www.youtube.com/watch?v=HdEfo8jS3FI&list=PL4aHiwoXvL...

Yeah, take this XKCD for instance: https://xkcd.com/1425/ That was published 10 years ago but now the second item is (nearly) as trivial to accomplish as the first.