Either that call would have to do the same (i.e., walking the files and counting), or you'd need some additional metadata in the directory entry to store how many files there are, requiring additional storage accesses for adding and removing files. Adding to that that both FAT32 and NTFS are quite old and had to run on older hardware. Cycles and disk accesses are not free.
On top of that, how often is it necessary to efficiently know the number of files in a directory while at the same time not caring about the files enough to list or display them? This algorithm is a special case where you could use the count of using a bit simpler code that ultimately would have the same file system API calls (since you cannot tell the FS to give you file #37 from that directory, so you'd have to use FindNextFile 37 times anyway, just like the sampling algorithm).
Not that it counters any point you're making, but ZFS displays the number of contained entries of a directory in the directory's size field; mind that . and .. are included, so you usually need to subtract 2 to get the count you actually want. I do find it useful sometimes to know the count without getting the listing; the former is a very inexpensive operation (since ZFS is keeping track of metadata like you suggested), the latter is expensive, potentially extremely with hundreds of thousands or more of entries.
This is more-or-less unique to ZFS. Other file systems even on Linux and FreeBSD generally don't provide this behavior.
> or you'd need some additional metadata in the directory entry to store how many files there are, requiring additional storage accesses for adding and removing files.
Most unix filesystems use inodes. inodes have the same format whether they represent a file or directory. So directory have a (usually unused) size member. NTFS doesn't use inodes, but the records in the MFT work the same way.
When adding or removing a file from a directory, you have to update the modification time of the folder, so you have to rewrite the entire inode anyway. Updating the size/file count at the same time would be free.
In my opinion the likely reason why file count isn't tracked is a lot more pedestrian: It wasn't tracked initially and we can never add it to existing file systems because the metadata would get out of sync if the FS was mounted on a kernel with no count support.
I base this assumption on the fact that many modern file systems do indeed keep track of the count.
Are there options that don't limit the output power? Typically the light power is limited, so dynamos only provide around 5 W or so, which already makes them not so attractive even for charging your phone on a bike.
I'm not totally sure about the specifics since despite being an engineer, I cannot distinguish electricity from witchcraft. That said, I do know that if you want to charge your phone from your dynohub you need to ideally have some sort of powerbank in the middle.
I think the problem with having a higher wattage is that you can't have a substantial amount without introducing what would generally be an undesirable amount of drag. It would certainly be useful to be able to engage / disengage a dynamo hub at a higher wattage though.
They do exist here in Germany as well, mostly in tourist destinations. The map does not show any outside the US, though. OpenStreetMap has 662 of them here.
Also known as banner blindness (https://en.wikipedia.org/wiki/Banner_blindness). I'm genuinely surprised that a UX person doing usability testing (for a website!) has never heard of this. But I guess there's people missing basic knowledge in every field.
Let's also note that they did say "25 years ago". UX research then and now was, at the very least, different, and there was less experience with web-specific behaviour. I'd also note that it was mostly graphic designers doing web design back then, or maybe that's just me.
To be fair it was quite a long time ago, and as I recall the person guiding and asking questions was from the market research company. The web designers and whatnot was not in the room, but viewed the session remotely and could tell the person with me what to ask and such.
You can bring the water to a boil and dial back the heat when you add the pasta. Will still cook, but no boiling over. Saves a bit of electricity as well.
Yeah, StreetComplete helps both with adding the data in the first place and then keeping is current, since it will also ask those questions again after a while (which also gives an opportunity to check whether a feature still exists). What's less visible there is whether a cafe exists at all – it's not as good to add missing objects as it is for filling in details of existing objects, at least for the casual user.
> Where is Windows' equivalent of APFS / BTRFS (or even EXT4)..? NTFS is more than 20 years old by now.
There's ReFS, but a lot of NTFS features are basically baked into the filesystem API, so replacing it is hard.
That being said, NTFS works extremely well and reliable. I don't really see a compelling need to replace it (which is always a messy transition unless you're completely backwards-compatible -- but in that case, NTFS has evolved a lot already).
APFS and BTRFS are objectively better than NTFS. Hell, even HFS+ and EXT4 already were.
And then there is already the next generation knocking on the door. BcacheFS is really cool and yet another step forward in performance and reliability.
Nothing stopping you from enjoying Slackware 11 on EXT2 though :)
On top of that, how often is it necessary to efficiently know the number of files in a directory while at the same time not caring about the files enough to list or display them? This algorithm is a special case where you could use the count of using a bit simpler code that ultimately would have the same file system API calls (since you cannot tell the FS to give you file #37 from that directory, so you'd have to use FindNextFile 37 times anyway, just like the sampling algorithm).
reply