I don't think of base 10 being meaningful in binary computers. Indexing 1k needs 10 bits regardless if you wanted 1000 or 1024, and the base 10 leaves some awkward holes.
In my mind base 10 only became relevant when disk drive manufacturers came up with disks with "weird" disk sizes (maybe they needed to reserve some space for internals, or it's just that the disk platters didn't like powers of two) and realised that a base 10 system gave them better looking marketing numbers. Who wants a 2.9TB drive when you can get a 3TB* drive for the same price?
Three binary terabytes i.e. 3 * 2^40 is 3298534883328, or 298534883328 more bytes than 3 decimal terabytes. The latter is 298.5 decimal gigabytes, or 278 binary gigabytes.
Indeed, early hard drives had slightly more than even the binary size --- the famous 10MB IBM disk, for example, had 10653696 bytes, which was 167936 bytes more than 10MB --- more than an entire 160KB floppy's worth of data.
Buy an SSD, and you can get both at the same time!
That is to say, all the (high-end/“gamer”) consumer SSDs that I’ve checked use 10% overprovisioning and achieve that by exposing a given number of binary TB of physical flash (e.g. a “2TB” SSD will have 2×1024⁴ bytes’ worth of flash chips) as the same number of decimal TB of logical addresses (e.g. that same SSD will appear to the OS as 2×1000⁴ bytes of storage space). And this makes sense: you want a round number on your sticker to make the marketing people happy, you aren’t going to make non-binary-sized chips, and 10% overprovisioning is OK-ish (in reality, probably too low, but consumers don’t shop based on the endurance metrics even if they should).
"consumers don’t shop based on the endurance metrics even if they should"
Its been well over a decade now and neither I nor anyone I know has ever had an SSD endurance issue. So it seems like the type of problem where you should just go enterprise if you have it.
TLC flash actually has a total number of bits that's a multiple of 3, but it and QLC are so unreliable that there's a significant amount of extra bits used for error correction and such.
SSDs haven't been real binary sizes since the early days of SLC flash which didn't need more than basic ECC. (I have an old 16MB USB drive, which actually has a user-accessible capacity of 16,777,216 bytes. The NAND flash itself actually stores 17,301,504 bytes.)
> I don't think of base 10 being meaningful in binary computers.
They communicate via the network, right? And telephony has always been in base 10 bits as opposed to base two eight bit bytes IIUC. So these two schemes have always been in tension.
So at some point the Ki, Mi, etc prefixes were introduced along with b vs B suffixes and that solved the issue 3+ decades ago so why is this on the HN front page?!
A better question might be, why do we privilege the 8 bit byte? Shouldn't KiB officially have a subscript 8 on the end?
To be fair, the octet as the byte has been dominant for decades. POSIX even has the definition “A byte is composed of a contiguous sequence of 8 bits.” I would wager many software engineers don't even know that a non-octet bytes were a thing, given that college CS curricula typically just teach a byte is 8 bits.
I found some search results about Texas Instruments' digital signal processors using 16-bit bytes, and came across this blogpost from 2017 talking about implementing 16-bit bytes in LLVM: https://embecosm.com/2017/04/18/non-8-bit-char-support-in-cl.... Not sure if they actually implemented it, but that was surprising to me that non octet bytes still exist, albeit in a very limited manner.
Do you know of any other uses for bytes that are not 8 bits?
> Do you know of any other uses for bytes that are not 8 bits?
For "bytes" as the term-of-art itself? Probably not. For "codes" or "words"? 5 bits are the standard in Baudot transmission (in teletype though). 6- and 7-bit words were the standards of the day for very old computers (ASCII is in itself a 7-bit code), especially on DEC-produced ones (https://rabbit.eng.miami.edu/info/decchars.html).
Back in the days of Octal notation, there were computers with a 12 bit word size that used sixbit characters (early DEC PDP-8, PDP-5, early CDC machines). 'Byte' was sometimes used for 6- and 9-bit halfword values.
I wanted to reply with a bunch of DSP examples but on further investigation the ones I checked just now seem to very deliberately use the term "data word". That said, the C char type in these cases is one "data word" as opposed to 8 bits; I feel like that ought to count as a non-8-bit byte regardless of the terminology in the docs.
NXP makes a number of audio DSPs with a native 24 bit width.
Microchip still ships chips in the PIC family with instructions of various widths including 12 and 14 bit however I believe the data memory on those chips is either 8 or 16 bit. I have no idea how to classify a machine where the instruction and data memory widths don't match.
Unlike POSIX, C merely requires that char be at least 8 bits wide. Although I assume lots of real world code would break if challenged on that particular detail.
> I don't think of base 10 being meaningful in binary computers.
First, you implicitly assumed a decimal number base in your comment.
Second: Of course its meaningful. It's also relevant since humans use binary computers and numeric input and output in text is almost always in decimal.
> merely pulling in Nixpkgs is an effort, due to the repository being massive.
I've embraced daily shallow clone/fetches and the burden is now mostly just the 2GB of disk space.
It's a bit annoying though that git doesn't make it easier. No one would shallow clone later screw up and download every commit anyway, I feel shallow clone repos should be set up with a different configuration that fully-embraces shallow history (not that the configuration options even exist today AFAIK).
Interesting, I have taken a stab at maintaining a repo on the nixpkgs and using a --sparse approach, i.e. `git clone --filter=blob:none --sparse --branch nixos-25.11 https://github.com/NixOS/nixpkgs.git nixpkgs-dorion
cd nixpkgs-dorion`
Oh, maybe I had a full clone on my laptop before I started doing shallow fetches, but since fetching takes quite a while I've been using a shallow clone on my workstation.
I've only been doing this for a few weeks, so too early to tell if it's a good setup, but I added a GitHub Action that rebases my personal fork atop nixpkgs-weekly. I'm hoping that will help keep me from having a stale-by-default personal nixpkgs. (I use a personal nixpkgs to stage PRs waiting to be merged upstream.)
I remember thinking about doing that, but found value in having my fork tell me when was the last time I synced with upstream which was something useful to assess if I wanted to rebase my patch once again. Eventually my change got upstream and I stopped tracking my own fork though.
I started doing it this way (auto-rebase) when I started sharing one home-manager config across different devices.
This lets me do `nix flake update` on my home-manager config to have all my in-flight patches + the canonical nixpkgs from any device, and trust that they can all see the shared GitHub to sync. Hopefully will make updating less of a chore.
Only time it's bit me so far was when godot3 was broken in nixpkgs-weekly but worked in 25.11. Forced me to go write a PR for that and get it upstream to get my build working again, but that was more of a nixpkgs-weekly problem than a personal fork one.
One of the wrinkles of getting home-manager going on a bunch of different devices is that it liked to copy my local git checkout of nixpkgs to /nix/store a lot. That's why I'm preferring to have flake.lock point at my github.com branch, and then I can test uncommitted changes as-needed by passing --local to my home-manager switch incantation:
Are you building your systems on that auto-rebase? I've found that slight differences made my own fork not build for all my systems and gave up on having a personal canonical version (after I got things upstreamed). I let my machines update on their own schedule and keep track of the lockfiles through backups, in case I want to sync with a system that was built more recently (and hopefully will also build)
I have been. Hoping it cuts out some of the manual work and prevents me from accidentally writing a PR against an obsolete nixpkgs. The only changes I've made are ones I'd want to be upstreamed. So from the point of view of my individual devices, it's basically the same as just putting nixpkgs-weekly in my flake. I can nix flake update to pull changes into nix, and hard reset to update my local repo (which is now just an easier way to fast forward + rebase/cherry-pick).
We'll see how it goes. So far, it was broken upstream once when gcc was upgraded out of sync with godot3, and it looks like sublime-text might break next week do to an openssl change. But those are both artifacts of depending on weekly. If it stays this hairy, maybe I'll end up using the biannual release channels.
Is there footage available? A fully attentive human could've read cues from the environment and maybe avoid the accident or at least increased the error margin for that emergency stop.
If that wasn't an option I guess a fast reacting driver would have done a bit worse and an unattentive driver might have even ran ever the kid.
I find it ridiculous that airports in the US close. I've landed earlier than expected and you need to stare at the ceiling until 5am while other aeroplanes arrive and prepare for a race through customs.
I sometimes fly out of a small, local airport that only has one commercial route, from that airport to Philadelphia. That airport closes down overnight and it's perfectly reasonable. (And they open up at 5 AM to start serving passengers boarding the 7 AM flight; again, perfectly reasonable since there are 50 seats on that plane and you get through security in 5 minutes). But a major international airport that has incoming flights all night long? I agree, they should have at least ONE customs location staffed somewhere in the airport, any time an international flight is scheduled to arrive.
P.S. It's not just America. I flew through the Middle East once on my way to eastern Asia. The flight landed at something like 3:30 AM local time, and the security checkpoint didn't open until 4 AM or 5 AM or something like that. There were so many people waiting in line for that checkpoint, it was getting dangerously overcrowded in that hallway, with more and more people arriving down the escalator all the time. Thankfully nobody fainted or fell, but it could have been a bad situation there.
Not only US. A friend’s flight was late and about to land in Munich after the airport closes. So they had to land at a different airport and then take the train to Munich.
Long Beach does something similar; I did a training flight there and we left right as it was closing, when my wheels left the runway all the lights went off.
Not really - EV regen is really good. Even on my 4000 pound Fusion Hybrid, I don’t brake as often as I would in a gasoline powered vehicle because I’m able to coast down on the motor braking itself.
This is a software, not a hardware problem. Suitably intelligent software could gently apply the brakes every now and then in addition to regenerative braking even when it doesn't need to, just to keep the brakes in good condition.
The better you get at this, the more you'll drive around without getting the break pads checked.
This also increases the risk of running out of braking power when the car needs it the most, you'll be fine on an easy drive and then rear end the car in front of you or worse.
In my mind base 10 only became relevant when disk drive manufacturers came up with disks with "weird" disk sizes (maybe they needed to reserve some space for internals, or it's just that the disk platters didn't like powers of two) and realised that a base 10 system gave them better looking marketing numbers. Who wants a 2.9TB drive when you can get a 3TB* drive for the same price?
reply