Filesystems are fine. The author needs to bone-up. I have several filesystems with in excess of 50 million inodes on them right now. We have a grok tree with over 100 million inodes in it. I'd post the DF outputs but slashdot's lameness filter won't let me.

To be fair, an old filesystem like UFS is creaky when it comes to directories, but modern filesystems have no problems with directories. And no filesystem has had issues with large files for ages (even UFS did a fairly decent job back in the day). BTRFS, EXT4, ZFS, HAMMER2 (my personal favorite since I wrote it), XFS (which is actually a very old filesystem that we used on SGI Challenge systems many years ago). It is just not a problem.

Generally these filesystems are using hashes, radix trees, or B-tree / B+tree style lookups for directories and inodes. H2, for example, uses a variable block-size radix tree, which means that a directory with only a few entries in it will be very shallow (even just all in one level if its small), despite the 64-bit filename hashes being evenly spread throughout the entire numerical space. But as the directories grow in size, the tables are collapsed into radix ranges and slowly become deeper. Indirect radix blocks are 64KB, so it doesn't take very many levels to cover a huge directory.

The only way one could do better (and only slightly better, to be perfectly frank), is to use some of the object-store features built directly into later NVMe chipset standards. Basically the idea there is that any SSD has an indirect block table anyway, why not just make it directly into a (key,data) object store at the SSD firmware level and then have filesystems use the keys directly instead of linear block numbers? Its totally doable, and not even very difficult given that most modern filesystems already use keys for directory, inode, and block indexing.

In anycase, the author needs to do some serious research and catch up to modern times.

-Matt

A few simple rules will make life easier.

#1 - Have two credit cards accounts. Put trusted services that would be annoying to re-enter on one (e.g. trusted online accounts such as Amazon, Apple), and make untrusted / ad-hoc, and over-the-counter purchases with the other.

#2 - Use Apple Pay or Google Pay instead of a physical card whenever possible. And in particular at gas stations. You can associate your 'secure' card account with your phone. Always use the phone-based nfc payment whenever possible.

#3 - Never make purchases with your debit card. Use the debit card for ATMs only, preferably inside locations or at banks.

#4 - If your bank's online account has the feature, have it text you the location and amount whenever your card is used.

That's it pretty much. Either my wife's or my card (usually my wife's) would get lifted maybe once year, but it was never an inconvenience because it was always the untrusted card, and almost always due to use at a gas station that did not have wireless payment at the gas pump.

These days of course we have chip cards, and even cards which don't print the credit card number on the front any more (but still print it on the back). Doesn't matter though because modern day thieves often don't lift cards via the magnet strip any more, they install cameras that take pictures of both sides of the card instead.

It is also possible to copy a chip card (actually not even all that hard because the extra information on the chip that isn't on the face of the card is often not actually checked by the CC company, so blank cards can be programmed fairly easily). And it is also possible to fake or break a chip reader at a merchant, causing the merchant to back-off to a slider or direct entry.

And regardless of that, if your CC number is stolen at all thieves will use it at locations which don't require chip cards. And even though your bank will back the charges out for you, you still have to go through the hassle of changing cards. Which is why you have two accounts... it removes that hassle. So chip cards, even secure ones, don't actually remove the hassle. Thus, take the steps above to minimize it instead.

-Matt

There isn't really any proof that Waymo vehicles are driverless, only that the driver isn't in the vehicle. If you compare a dozen dubiously driverless vehicles to a million collecting data every moment and already doing a pretty good job at autonomy, which do you think will succeed?

The fact that the driver is not in the vehicle does not mean that there is no driver.

So... it's compiled... like literally every other program every made?

What exactly makes compiled code special? EXEs are compiled code. The term "run-only" is stupid. You have to be able to read the thing to run it, and the computer can read bytes just fine, so... where's the problem?

I believe that this was figured out in the amateur observer community before NASA confirmed it. I saw it go by in my twitter feed. Not sure I can find it now...

Linear Energy Transfer

It's not radioactive. When high-energy particles strike it, they break apart into lower-energy particles that are more harmful. So, you need enough shielding to catch the particles that break apart in the top layer of your shielding.

While radiation mostly results in transient errors, it can also cause latch-ups that blow a gate off of the die. For rad-hard equipment in space this is mitigated by silicon-on-insulator fabrication, so that you can't have a latch-up between the substrate and a silicon feature.

We could have REAL ZOMBIES! YEAH!

:-)

I hear you. Going to be an interesting future, if we live.

Someone who broke their neck and was suffering from paralysis. You can control a chair or exoskeleton. People who can not hear today have cochlear implants, this is not all that different and might (eventually) work better. Or speak, or see. Other people who are disabled in various ways.

Oops. To continue: I'm just not seeing that it is so hard to access. But then, I use a Linux desktop, which has always come with a proper PDF renderer, there has never been a need to download "Acrobat".

Web pages use SVG to render vector graphics. It uses the exact same imaging model as PDF and is implemented in all modern browsers. The web in general has taken a lot of lessons from Adobe because Warnock and Geshke, in the PostScript Red Book, got so much right about how to build an image model that many GUI developers are still learning today. If you start with a PDF, it should be possible to machine-translate it to SVG and present it as a web page.

PDF exists because it is trivial to generate it from the document renderer meant for printing. Although I have once in a while run into an improperly scaled PDF meant to be printed 8-up, I'm just not

Lithium battery fires are in the news because they are new. There are many more gasoline fires every day.

Pistons? We don't need no stinking pistons! Next thing, they'll be adding a bridle and a bit!