I really like the almost-no-ports Macbook Air. I also really see the utility of what you describe, since I'd like exactly such a thing as well. (We have something close.) The portable ton-of-ports-in-a-box laptop as a tech tool is very useful. But really, those are two very different products. It's completely true that Apple just doesn't make the latter product.
It doesn't seem like they say who the activist is?
That's why nearly ensuring detection is so attractive. If we don't detect a gravitational wave--which has been the case so far--it's a lot more meaningful with a very sensitive detector.
Oh, no. You do not want your defense to rest on technical details. Rather, a common tactic (admittedly, among people who are guilty) is for the defense to claim that it was an accident or malware and demand that the prosecution show intent. The defense can then hammer on the prosecution's expert witness (forensic investigator) and back them in to a corner where they're having to explain technical details. This makes the jury unhappy with the prosecution.
Displaying the images you found in court works pretty well for the prosecution, and is probably a significant contributor to their very high rate of plea bargains.
There's more to the Internet than the Web. There is certainly CP that can be accessed accidentally. It's true that it doesn't really happen all that often. (It mostly happens with people on P2P file-sharing systems who execute vague searches for porn and then mass-download everything.) But it doesn't matter -- the defense can and does make a legitimate case that it *could* be accidental unless you demonstrate intent to a reasonable degree.
In my limited experience seeing these cases go by, no.
It's usually hard to convict these child porn cases unless you can demonstrate that the perpetrator action's were knowing and willful. Yes, some of the laws aren't like that and are strict liability, which sucks. Yes, some unwise prosecutors indict on absolutely ridiculous cases, and that sucks. But in general, if you're going to actually get a conviction in court, you really need to be able to demonstrate that the guy did it knowingly and willfully.
Even then, if your evidence of intent is too deeply technical, you conviction is at risk, because a jury absolutely hates any deep technical discussions (they are not, in general, technically-minded people). So Web browser data, for example, sucks. If you find CP images in a browser cache, then you've got to demonstrate that they got there by willful action and not by mistake. (After all, both the forensic investigator and the defense know full well that you can get porn in your browser cache with one accidental misclick.) So you've got to connect Web browser history (which used to be shorter-lived than cache entries) to the CP, which is somewhat technically complicated, and as mentioned, technical explanations are looked down on. It's worse if you find CP in unallocated space on a hard drive -- now you've really got your work cut out for you. But, I digress.
Fortunately for the prosecutor, the gross majority of people they catch make it easy. They take zero of the half-assed paranoid steps that any armchair expert on Slashdot will tell you to follow. No encryption, no "download and secure erase" policy, etc. No, they download, organize, and label hundreds of gigabytes of child porn.
Anyway, in practice, mens rea really is necessary to get a conviction. Which means one of two things here: either the prosecutor in this case is looking to make headlines and is making a bad decision (namely, they'll get their headlines but not a conviction); or, more likely, the host has knowingly harbored CP -- perhaps even specifically sought out this business, has chosen to do nothing about it, and there is substantial evidence to demonstrate this. (I think the latter is more likely not because of my faith in prosecutors, but rather because businesses providing "secure storage" but explicitly and knowingly catering to this kind of business abound.)
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.
The headline that they are "tied to NSA"... but TFA says that "researchers stopped short of saying Equation Group was the handiwork of the NSA."
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+.
a database has a way to address individual "items" that exist on a far lower level than a "file" with the ability to read and update or delete them
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.
You don't know how file systems work,
Says you, sans evidence.
ignores both the OS-specific driver stuff and all the messy details. That's the thing about storage - the job is 95% about the messy details.
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.
I find too few candidates can even describe to me why doing file access in 2 threads helps.
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' would span one book, minimum.
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.
It is easier to write an incorrect program than understand a correct one.
