teacup50

Drawing the line at the kernel syscall ABI is arbitrary; no other major operating system other than Linux does so.

Consider how difficult it is to ship 3rd-party applications for Linux and all its myriad of distributions; the only thing you can truly rely on is the anemic syscall ABI provided by the kernel (vs. userland).

No. It's not.

If nginx releases an update, do you also need to update your OS? No, because the user dependency graph isn't shared with the base OS.

If you update your OS, do you also need to update nginx? No, because there's backwards ABI compatibility.

The split is not artificial.

Most people just have to incorporate their C++ dependencies directly instead, as there is no supported ABI.

It's an option ... but not a very good one.

It tends to create an unstable environment that requires a centralized organization just to keep it working, precluding a healthy diverse software ecosystem.

This is a major reason why it's very difficult to distribute binary packages when operating externally to the distribution packagers, and why commercial software distribution on Linux is a massive pain in the ass.

Play your purchased iTunes movies locked with Fairplay DRM?

Read your purchased iBooks?

Read your personal documents, passwords, and data locked into iCloud?

Synchronize with your other Apple iCloud-only devices?

At some point, product tying results in lock-in far more costly to escape than, say, a video game console with platform-only titles.

The geographic model is based on the obvious notion that it's unreasonable to expect people to simply pack up and move to a different city to get access to a different vendor.

Given the amount of lock-in inherent in these platforms, it seems pretty clear that people can't simply drop their current platform and switch to another one just to access to a different vendor.

For example, there are a myriad of products based on BSD; everything from pfSense at the low-end, the Juniper routers at the high-end.

If the goal is to make money by licensing the code for non-GPLv2 use, then the GPL might make sense, if you're unconcerned about limiting market adoption by precluding integration by non-GPL products.

Granted, but this should generally be behind a shared secret HMAC, according to best practices, limiting the scope to those with the key in hand.

> The whole point of WireGuard is to shake off that complex baggage.

That's great, but also has nothing to do with running in-kernel. I'm not ready to give either product a clear pass on their risk profiles.

The end goal ought to be getting more things out-of-ring 0, not adding more things to it -- I'm never going to say that "I'm not concerned" or that "It's a non-issue" (although I will say that I'm a lot more worried about the massive amounts of crap code in WiFi drivers than I am about a VPN implementation, generally speaking).

In the OpenVPN case, numerous vulnerabilities have been limited to only DoS exploits due to the zealous use of assert(); in the kernel case, that brings down your machine, and quite often, assertions are compiled out of the release kernel due to their overhead in critical paths (whether they should be is another question).

We do have ways to tackle the kernel->userspace performance divide when it comes to packet processing, e.g: https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4

  netmap is a framework for extremely fast and efficient packet I/O for
  both userspace and kernel clients. It runs on FreeBSD and Linux, and
  includes VALE, a very fast and modular in-kernel software switch/data-
  plane, and netmap pipes, a shared memory packet transport channel. All
  these are accessed interchangeably with the same API.

  netmap, VALE and netmap pipes are at least one order of magnitude faster
  than standard OS mechanisms (sockets, bpf, tun/tap interfaces, native
  switches, pipes), reaching 14.88 million packets per second (Mpps) with
  much less than one core on a 10 Gbit NIC, about 20 Mpps per core for VALE
  ports, and over 100 Mpps for netmap pipes.

  Userspace clients can dynamically switch NICs into netmap mode and send
  and receive raw packets through memory mapped buffers.  Similarly, VALE
  switch instances and ports, and netmap pipes can be created dynamically,
  providing high speed packet I/O between processes, virtual machines, NICs
  and the host stack.

As a "kernel professional", I'm laughing incredulously at this. A lot.

I'm not impressed with NoSQL; they have no answer to the limitations of relational theory beyond simply abandoning formalism entirely.

If I can model your type/language model as a higher-kinded dependently typed lambda calculus (e.g. using Boehm-Berarducci encoding for non-turing complete recursive ADT definitions), then it's not OO -- it's functional programming, rediscovered.

The library in question is modeling relational theory at the language/type level. That's not remotely like an ORM.

Only if you assume that Object Relational Mapping is the only way to express type checked database access at the application layer.

ORMs are broken by design; there's no lossless bridge between relational theory and OO -- only inconsistent, error-prone, complex approximations.

Instead of bringing relational theory to the programming language, ORMs try to emulate OO behavior/method dispatch/etc in a world of transactions, deadlocks requiring retry of previous operations, on-disk serialization of data, etc.

In 2016, it's ORMs that are outdated.

What's to stop us from implementing a broken SGX via trap-and-emulate?

Our job is to be correct. If we avoid offense in the process, great.

Programmers are not the personal army of any social cause.

I work hard to accurately model engineering problems, and apply consistent ethics in doing so. If that aligns with your definition of "combating prejudice", great for you, but I need the latitude to critically analyze technical problems without the threat of bullying and shaming for wrong-think.

If I need to understand how surnames work across cultures, understand how time works across calendar systems, or understand what "marriage" means to the people getting married, then that's what I'll do.

If I need to support non-binary 'gender' selections because that's what users want, that's what I'll do. On the other hand, if I need to support binary gender for the purposes of simplified data analysis under the assumption of two biological genders with a low probability of intersex individuals, that's what I'll do, too -- politely, and without rancor, and with all the respect for others I can muster.

I call bullshit. Up, down, right, left and center. So much bullshit.

The undermining of private property rights comes to mind.

e.g. live libclang-based code completion for Emacs: https://github.com/Sarcasm/irony-mode

It's literally:

    struct list_node {
        struct list_node *next;
        ...
    };