throwawayish

> ... or a filesystem as a backing store first.

File systems are far harder to use correctly compared to pretty much any database; suggestion: only use them for storing large blobs, and use collision-free names (eg. random UUIDv4). Many applications don't need that though.

> I'm somewhat aware but it seems like the idea of a computational graph is the most generic computational idea I can think of and I'm surprised it's not more explored.

ASTs?!

Earlier in my life I did a lot of Windows system-level programming, including some minor driver development, and now I'm practically exclusively on the #nix bunch, sometimes doing similar stuff.

I can't say that there is a disparity. If anything, the parts that are documented are usually better documented in the Windows world, and there are very good books about most components. (To be fair I never read a book on anything unix apart from Lion's). There is a large amount of stuff online for either, but I often have the feeling that correct examples are less frequently found for, esp., Linux.

If you're on a budget it makes little sense if any to buy things like a motherboard, CPU or memory new.

A Pentium II can play a DVD back at 24 fps back no problems.

Uh, no. That article is a bit of a long winded way to say that 2PC with timeouts is 2PC with timeouts.

Unix has process groups.

Unix has access control (ie. memory protection, FS access protection, FS root aka chroot).

Containers are process groups with access control.

The actual entity has a different name pretty much everywhere, eg. Solaris Zone, Linux namespace and Linux cgroups. Usually the OS throws in a wider bunch of stuff that is only loosely related to access control in the classic sense, eg. CPU and memory limiting, I/O rate limiting and such (so rusage access control, in a sense).

The numerous performance and stability issues (not just in the containers, but also affecting the main cgroup / "host" rather badly) I had with Docker, but never with LXC, which, according to you would be pretty much the same thing - "just namespacing your process". But it isn't.

Docker is ok when it works, hell when it doesn't, has lots of bugs and regularly regresses. I don't understand why you'd run production infrastructure on that and not on any of the alternatives.

WinDirStat does a map-like view where blocks are grouped by folders.

KFilelight only does sunburst I think, but I also have to say I like that, because it's easy to navigate (large click-able surface area).

KDE: Filelight, https://docs.kde.org/trunk5/en/kdeutils/filelight/introducti...

Windows: WinDirStat

There are some sections of Autobahn built with concrete slabs and they are terrible, even if it were for the noise alone [1]. But they are also problematic when it gets hot -- warped slabs and slabs being lifted into the air by pressure (since the slabs expand) happen regularly. And they are also problematic when it's wet. In other words, they're always problematic.

Concrete Autobahn is mostly replaced with proper asphalt Autobahn when a section is renewed.

[1] Since it's Autobahn many people don't drive a cosy 140 km/h (85 mph) but rather 160-250 km/h (100-160 mph) [and when the road is free 300 km/h, 190 mph, are observed regularly] so I assume the noise is worse on the Autobahn than on concrete highway.

This is legacy built on legacy built to work with minimal CPU cycles on existing hardware designed to be compatible with hardware from the 40s.

Yes, concerns aren't separated ;)

A much more recent and far superior design can be found in Windows NT, where things like coloring are done entirely through an ioctl-equivalent (whereas Unix has amounts of in-band signaling, while some later extension use tty_ioctl).

http://zodb.org/ is literally what you are describing :)

It's the basis of most Zope apps, including Plone, but also many other applications; there's not much talk about it, because it just works. Like in the comment I made below; if it's a good fit ze ZODB is quite literally worth every LoC in gold.

The database itself doesn't do that much (apart from giving you transparent object/application persistence, transactions and MVCC :), as one would expect.

The Zope people made an excellent job of modularising it (or, in other words: this is by principle extremely modular), so there are a bunch of packages commonly used around it (eg. BTrees, zodburi, often either ZEO or RelStorage and stuff like eg. zope.container).

(Historically it's also very interesting - development started in 1997! The revision history is an interesting read, too, many familiar names pop up, including GvR)

> There is no application that has a 30 years lifespan.

You literally made me "chuckle out loud".

The format itself is not complex, but recovering the transaction is (very much). So better make sure to leave it clean.

I loathe this kind of headline, claiming to have the authority to tell me what to do or what is good or bad for me. How presumptuous.

In most European countries it's much easier to get citizenship if a) stayed a while and b) gave birth to a child. Similarly it's easier for the other parent to get citizenship or permanent residence under these conditions. But yeah, I didn't describe it very accurately. From what people told me the US is/was one of the prime targets, will be interesting to see if that changes with Trump. Perhaps more come to Europe instead.

I disagree with both of you.

SQL and ORM are a superb fit for a great many applications, incidentally a large share of real world applications. The four-letter abbrev. CRUD comes to mind, as well as reporting.

Most kinds of NoSQL remove some benefits of the relational model while not really giving you the benefits of object persistence. I never felt a great need to use it; since quite some of these databases also had all sorts of issues that not exactly endeared trust for serious applications -- I'm not working on software where that's an OK thing to have (though for others it might be an acceptable tradeoff).

The real deal persistent object databases are a completely different beast from both NoSQL and relational models (only some NoSQL concepts like explicit / application-level indexing carry over). Two important things to note about these: 1.) There are not many of them 2.) Properly using them already requires proper OO technique. Failing 2.) will make it an unmaintainable mess. Certain kinds of applications benefit greatly from these, and there they also tend to perform better in both developer experience and efficiency as well as application performance than forcing a huge impedance mismatch down the throat of an ORM -- which pretty much always means that the underlying relational DB is used in very anti-patternish ways, resulting in poor performance regardless how good the DB actually is.

SSH != remote shell -- pretty much one of the main points of this article.

No, this is often about having a working exit strategy. Similar things happen in many countries right now, usually by getting a/the pregnant wife into the country, getting citizenship for the child and thus at least residency rights for both parents. Also moving assets continouosly out of China to safer countries. Obviously this is all very expensive, since they need to do it without the state noticing, ie. lots of bribing.

Wholly irrelevant, just like the Python "benchmark" that was on the front page yesterday.

Prior approaches to mixing architectures in one system (and actually moving applications at runtime dynamically, as in big.LITTLE,) were ...

Also, you don't have to route traffic over tor in Qubes.

Konsole?

Both Pentium and Celeron are used for standard mainstream dual-core chips and for Atom chips (eg. J4205, Celeron G3900, Pentium G4400)... so in a way they are Intel's trash-can brand.

I expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either.

(1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only exist in separation: eg. IBM TIMI allows to move applications across physical processor ISAs, while various clustered virtualization implementations can move live VMs across distinct hosts.

The CPUs run different OSes and there is no ability to move tasks between them; this is rather unlike a hybrid or "big.LITTLE" approach.

Not really, the ARM in the SB is much more like a ILOM system; not much different from the various processors scattered around hardware these days, be it ARM or some other more niche architecture, or even special-purpose archs.

> That's a huge loss of face for java IMHO

Because the JVM JIT, like every other compiler, sucks at developing vectorized algorithms ad-hoc; a task usually carried out by human experts in that?

While I certainly don't want to give this sort of "benchmarking" any credibility at all:

allocating significantly different compute resources for different samples would be at least as laughable (eg. giving Go a dozen cores [per it's defaults] but constraining Python to one worker [per it's defaults]).