thepicard

A modern OS is definitely a virtual machine, where each process perceives that it is running on a single CPU with its own single contiguous bank of memory. Threads are a bit of a leaky abstraction but whatever.

What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact same functionality, with a different interface. Rather than read/write as syscalls, you have to send SATA commands to disk, or commands to a network card, or whatever. Instead of an exit system call as an interface you work with a hardware interface that powers down the physical machine.

Containerization is actually a logical next step from this. Why virtualize a REAL hardware interface only to virtualize a fake one on top of it? The only reason to do that is if you want multiple fake interfaces, eg Linux and Windows. When virtualizing a bunch of Linux machines, mostly you really just want isolation of your processes. Virtualizing real hardware is a hack because Linux was not capable of isolating processes on its own, so you had to run multiple copies of Linux! Now with cgroups and other resource namespacing in the kernel, it can isolate resources by itself.

If you have 16GB, which is normal for high-end laptops these days, then you already can.

>If the profession ever wants to produce anything reliable in C++

This has already been done, so you are obviously wrong.

Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.

Because that server was not that important?

The different examples are all pretty much just different ways of writing the same thing. And then another different way of writing the same thing is presented, with "db:" prepended. Huh.

The only thing that is substantially different between any of these is the engine/protocol/adapter/whatever section. Perhaps that field should always refer to the protocol type and not the driver, but I consider that problem pretty negligible.

Because it's more than that. It wasn't originally to speed up run time, but compile time. That history is wildly fascinating to me. We tend to take compile time for granted, unless we are bitching about Scala, or compiling C++ at Google.

The author also addresses the importance of history. Voodoo knowledge _does_ pervade modern computer science, and I for one am happy to see something different.

But your contact book and location?

Definitely. I was going to say, was this not obvious when the app requests every permission related to your personal info?

If you ask the average 1st world human being "What are Macs good at?" They usually say something about ease of use and multimedia stuff. It's just what people think.

Now, on my Mac, I do exactly zero multimedia related things. So I agree that the multimedia thing isn't necessarily true, but that's what I hear about Macs from not-technicals.

Okay that's seriously metal.

I agree on some level, but you also can't say that this is a great thing. All these extreme opinions...

Can't we all just agree that Google is pretty great, but going through an annoying phase right now? Google _is_ taking advantage of the fact that most users won't leave, and I don't appreciate that. But at the same time, we are all slowly losing our patience, and in the long run this behaviour could hurt Google. I hope for everyone's sakes that this all settles down.

I also have this question. There are technical reasons that PostgreSQL is better than MySQL, especially when it comes to features, but none are mentioned here.

> From the development perspective Postgres was a necessity. Not a slam dunk but objectively a better tool for our use case.

In what way?

> And if we have countless reasons, all good, but they’re nuanced and technical and tricky to impart to a non-technical audience, where does that leave us?

HN would be interested in those reasons, I know I am.

> The vast majority of the company probably still doesn’t get why we went through this painful contortion at the expense of doing, well, a lot of other things.

Neither do I, since none are given.

Though I also understand that the point of the post was about trust. It's great that there is that trust within SparkFun, I would love such an environment.

Speaking of digitalocean, are you guys affiliated at all? Because I get a digitalocean vibe from your pricing/terminology/etc. for some reason.