That may be true.

It's not applicable in this case, because this is OEM-installed adware. Everything it does can be implemented just fine on a Linux system. The solution is really the same for this sort of thing regardless of whether you're talking Windows or Linux -- don't use the OEM-provided pile of crapware that comes with the machine; install a brand-new copy of just the OS.

That's a clever turn of phrase. Kaspersky pointedly calls them out as NSA, but doesn't explicitly say "this is a group at NSA".

They certainly are not. Some database implementations require a filesystem, but plenty do not -- they work with raw block devices.

Further, you can build a filesystem using a different filesystem. Take, for example, glusterfs, unionfs, EncFS, or Samba's "NTFS features on top of a non-NTFS filesystem" implementation.

I suggest taking to heart the words of Fred Brooks -- or of numerous other computer scientists who have said similarly:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."

Good data structures, particularly for a data-structure-oriented system (like a filesystem), imply the algorithms to be used with no further comment.

I can, for example, tell you the structure of the Volume Header and of the Catalog B-Tree file in HFS+ and you could use only that information to implement reading data from HFS+ (for files with fewer than 8 fragments). Little more is required for writing (and little more is required for fragmented files). Data structures is all Tech Note 1150 gives you, really, and it's enough to implement HFS+.

So the items in a database are in theory smaller and there are more of them. That's a practical and minor difference, not a fundamental difference. After all, plenty of filesystems have far more items than most databases. Lots of files are much smaller than many database elements.

Note that you can implement a filesystem using a database and vice versa.

I appreciate your distinction between "how it works" and "what components it consists of", but I think that unless you're being excessively pedantic, there is not a significant difference when it comes to software and especially when it comes to things like filesystems that are collections of data structures. Organized data structures generally imply exactly how they're used with little additional explanation.

Says you, sans evidence.

You must've missed "high level summary". They explicitly ignore the details in order to discuss the overall architecture. Which is important. You can't reasonably start with the details and expect to understand it -- though lots of people do, and end up understanding the details without understanding the overall structure (resulting in saying ridiculous things like "filesystems are not databases").

Filesystems are not OS-specific and they don't need drivers. They're bits on disk (or any other storage mechanism). Or blocks on disk, if you prefer.

Maybe so, but that doesn't have a damn thing to do with how a filesystem works.

I'll bite -- what feature or lack thereof makes a filesystem not a database?

Bear in mind that "database" is a quite general term and that I didn't say it was any particular type of database (e.g., transactional, relational, key-value, etc.).

"Describe a filesystem" is different from "how does a filesystem work".

Everything after the first sentence (which is an introduction) is, in fact, how it works.

No, you can explain how it works in five minutes, given some background in data structures. (You cannot cover the details of how a particular filesystem, particularly a fancy one, works.)

It's a database that manages the allocation of fixed-size blocks on disk to files and stores metadata about those files. It generally has a header at a fixed position on disk that identifies the filesystem, stores filesystem-wide metadata, and contains a pointer (rather, offset and length) to the index of files. The index of files is a data structure (varies per filesystem; example: B-Tree) that stores a record per file on the filesystem. The record contains metadata for the file. Metadata varies per file system, but the key metadata stored is the collection of blocks on disk (and their order) owned by (allocated to) that file. Generally, every file gets a unique identifier and directories are implemented as lists of the unique IDs of files contained in the directory (plus, potentially, other metadata), though some filesystems implement directories differently.

Knowing too much about filesystem should not prevent you from being able to describe how they work at a high level. If it does, the problem is not knowing too much, but focusing too often on details in a context where the details are not warranted.

How file systems work at a high level takes about five minutes and a small whiteboard.

At a slightly more detailed level, a chapter out of any standard undergrad-level operating systems textbook.

The details of how one particular filesystem works, at a level such that you could reimplement it, takes about one book.

This is true.

I mean, the "cybercrime" investigators that work for the FBI are not stupid and they're not incompetent. If you're running a large, well-known drug-selling site, they probably will put resources into finding you. On top of that, the deck is really stacked against you -- as a criminal, you need to avoid making any mistakes, while the investigator only need to wait for you to make a mistake. They're patient. (And "investigator" is not just people working for the police -- it's also anyone who might both have reason to dislike you and also motivation to reveal your identity to the police.) So, it may well be possible to hide indefinitely from prosecution, but it's not easy.

Here, you don't have to search for a clinic that provides free vaccines, either. It's a local government department.

All local services change if you move states. You certainly don't see the same GP after you move, no?

Everywhere I've lived in the US, vaccinations are provided gratis by the local health department.

People with insurance usually go to a doctor and get their vaccinations through them, but the health department will also do it for free. (That's the same health department that will run free STD tests.) Often, the real battle is communicating to people that these resources are available, fighting the stigma associated with getting free services from the government, and the practical issues of getting a working person over to a busy government office.

As many childhood vaccinations are practically mandatory in the US, as they're required for attending elementary school (which is also mandatory), it makes sense that they're freely available.

As a result, I think, of Obamacare, all childhood vaccines and most adult vaccines (including flu) are free to anyone with insurance.

It depends. You can get anyone to read a script on a recorded television show, but that's usually not the point. You can't really do an interesting interview with someone who is a good communicator but isn't familiar with the subject matter.

It depends. All of those are supported by theory. They're only "speculative" in that they are permitted by theory but have not been observed and, as a result, it's an interesting question as to whether or not they exist. (If they don't or can't exist, can that information be used to improve our theory?) So, depending on the context and what you say about them, they are potentially interesting lines of discussion, because they offer insight into what (some) physicists are still looking in to.

Demonstrating that people should be using wireless keyboard protocols that don't suck.

Well, a droud utilizes a wire that actually goes into the brain. The tasp, on the other hand, works externally and remotely. So this is somewhere in between the two.