throwawayish

It doesn't, really.

Applications can use much more domain knowledge to do the dedup, possibly with less resource usage or better speed (memory, eg. because an index to dedup with already exists, or CPU, eg. it can use existing constraints on data and doesn't need to hash all data). FS-level deduplication is... well. For classic FSes it does exist [1], but it's a pretty ugly kludge, and is pretty much inherently an off-line process that can't happen during writing the data the first time. For CoW FSes it's less of a problem, and eg. ZFS and btrfs can do it, but it's often not a exactly a great fit. (Although one could see their snapshotting features also as deduplication)

[1] through extent sharing, ext4 does this, iirc experimental in XFS. duperemove uses this.

Transactions are "hard and slow". Distributed transactions are hard-er and slow-er. Random 32 bit integer additions are likely "good enough" and are fast and simple.

Also, assuming that their storage is directly some FS, you don't have access to the transaction. You can't do a distributed transaction against something that, as a black box, does not appear to do any transactions.

In this case, doing a distributed transaction would mean to use an entirely different storage solution. A transactional one supporting TPC or similar. Magic counters sound good enough yet? ;)

If you have access you can probably disrupt or modify things when the need arises (making this kind of system even more pointless for their declared purpose than they already are).

I think the most prominent examples would be: Nazis (obviously), Stasi / DDR / GDR, Chile (Pinochet) and the dictatorship in Argentina; but in the last century there were many more examples, be it in South America, Africa or eastern Europe.

Wikipedia has a list of historical secret police: https://en.wikipedia.org/wiki/List_of_historical_secret_poli...

--

Current examples that are still alive and well could be the various GCC states, but especially Saudi Arabia there; the UK and the US to some degree each (both are obviously full-blown surveillance states at the very least; and it can be reasonably argued that (divisions of) the FBI and some other agencies qualify as a secret police) in the western hemisphere; Russia.

Literally no one does that. rsync-over-SSH is often used for this, sometimes plain rsync, sometimes custom stuff running atop SFTP (which is a completely different thing from FTP(S)).

Remind me, who exactly voted the narcissistic nationalist into the executive office controlling the worlds largest surveillance and secret service/police apparatus?

Small Government is a nice, and good, idea, but history shows us that neither surveillance apparatus (pl.) nor secret police (pl.) relinquish power, ever, within existing in the same continuum of legitimation (ie. state). There has been no previous instance where either were reduced; they only grow until chopped off entirely.

It's an infestation of the state. There is only one - proven - cure. (And I think it's naïve to assume that those who built and grow these structures are not aware of this)

I suspect this might be something people outside Germany or Europe are unaware of but

> Do you know why we still hunt down Nazi's 80 years later?

is actually a thing. There are still warrants out; Nazis (without the "Neo" part) are still arrested and convicted from time to time. Although I suspect this will come to an end soon, since people tend to die of old age now. Iirc some of the more recent trials ended with a conviction to incarceration, but no actual incarceration due to old age / medical issues.

Twelve citations in a HN comment has to be some kind of record.

Oh. That makes a lot more sense. Thanks

Today in: Broadly missing a point.

It's good and nice that there is one linter for a particular language that catches 100 % of these issues in an example, but that doesn't do much to change the fact that most linters for most languages are unable to do this, and that there are quite some instances of these decisions where it is doubtful that any linter would be able to lint it.

If there are multiple releases/branches then I also recommend to very carefully review merges between branches, even files/regions where git (or whatever SCM is used) merged automatically with no conflicts. I've personally seen multiple incidents now were through review bugs and security issues where found in merges that ranged from subtle to catastrophic. I even saw one catastrophic security issue introduced into a file git merged with no conflicts.

(However, more issues are typically introduced by manual conflict resolution, since we humans are also easily confused when doing it. Both are a problem relatively independent of language, although some specific instances might be caught by a compiler or tests. If the latter don't catch it, it may be a sign that some tests are missing.)

Be careful.

I remember an article saying that esp. in smaller spiders (so probably not tarantulas) the "brain" doesn't really have a simple shape, extending even into the limbs.

> The green plasma... is a neurobinder! It allows instantaneous melding of connected minds over any distance.

We're using Kotlin extensively at work and a very happy with it. Spending a couple weeks on converting most of our codebases to mostly-Kotlin-little-Java has given a nice boost to developer morale from my PoV.

While it's "neat" to encode a lot of stuff into types, it also makes code comparatively very difficult to understand for almost everyone. A big part of this is that documenting type systems is even harder and the tooling is even worse than documenting regular code, at least in mainstream languages (like C++; some called me a template guru years back), and of course that many developers are simply not very experienced with complex type systems. For that reason most developers stay well within the bounds of their languages' type system; it arguably gives you code that may be more "plain" and less "smart", but also code that far more developers will be able to reason about efficiently.

shred /array0/important && rm -rf /array0 && zfs list -t snapshot -o name | xargs -n 1 zfs destroy -r

(Or something along those lines)

If I guess right in what you mean here, then I'd say that in these instances backups are better value than RAID.

(I'm biased here)

> I also zfs send said snapshots to an off-site remote server, and if I didn't have that capability I'd rsync to an external hard disk or whatnot.

I wouldn't consider a backup system any more that isn't able to establish full integrity of backups. It's also a kinda good idea to diversify the software; ZFS has a really good track record, but if I where using btrfs, for example, I'd make sure my backup software is not the same as my FS.

USB controllers have to support 3.3 V anyway (on the D+/D- pair, not on the SS pairs), for supporting USB 1.x modes.

Let's not forget that there are still huge COBOL applications out there, still updated and maintained by rather well paid engineers.

Speed and size are somewhat independent. Speed is set by the bus frequency and how many chips you use - every chip has a fixed data bus width, typically 32 bits, while overall size is then how many chips you have times how big each chip is.

Unlike typical computer memory architectures, where the memory bus connects multiple chips or modules to one controller, GDDR doesn't do that; every slice of the memory controller only speaks with a single chip, strictly point-to-point. (Reducing bus load and layout issues and thus allowing higher clock rates).

That's why, with GPUs, it's usually sufficient to say how wide the bus is (often 64 - 128 - 256 - 384 - 512 bits) to get a rough idea of it's performance, since memory clock frequencies occupy a rather narrow range. (However, narrow-bus, lower-end GPUs often don't use the same technology as higher-end GPUs, eg. DDR3 instead of GDDR5)

Inaccurate; the very point of columnar stores is that if I'm only interested in a column I only expend the memory bandwidth required for that very column and nothing else. Hence typical queries to a columnar store would never stream the whole 500 GB for processing.

~4.4 GB in 150 ms are just about 30 GB/s.

As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (which is all the rage). I believe one can disable it on a per-VM basis though, so there's that.

Although the specific cause -- (mode_t)-1 -- is something that you can't really do in many languages. So you'd likely have to write 0777 or equivalent explicitly down, making it so much more obvious what a bad idea that is.

I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.

Glacier is meant as an archive - put stuff in, read just very little bits back. Reading everything/significant parts back costs extra.

But if you're using it as an archive, and not so much as a backup (which for me implies restore), then it might make sense for you. There is a simplified calculator here: http://liangzan.net/aws-glacier-calculator/

You probably don't want to use Glacier for personal backups if there is a decent chance you need a significant restore, or want it quicker than hours.

An important point to note is that esp. with S3 infrequent access or Glacier there are additional costs associated with restoring, which can be quite high. With S3/Glacier one needs to spend a bit of time to even figure out how much a restore would cost.

Some people mentioned that b2 is "get what you pay for" with heavy usage throttling bandwidths and stuff like that.

(I cannot verify these claims since I have never used b2, I'm just noting what people told me).