September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



System Evolution

  Download PDF version of this article PDF

Error 526 Ray ID: 47b9831dacee0ec7 • 2018-11-18 09:46:49 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 14, no. 1
see this item in the ACM Digital Library


Tweet


Related:

Rishiyur S. Nikhil - Abstraction in Hardware System Design
Applying lessons from software languages to hardware languages using Bluespec SystemVerilog


John R. Mashey - The Long Road to 64 Bits
"Double, double, toil and trouble"... Shakespeare's words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate "tomorrow's legacy today," we should study "tomorrow's legacy yesterday." Much of tomorrow's software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.



Comments

(newest first)

potato tomato | Mon, 25 Jun 2018 02:19:49 UTC

PID and UID are not really the same


Name | Sat, 11 Feb 2017 14:50:39 UTC

Nice article! I had been thinking Kubernetes is to Borg as Bazel is to blaze.


Stu | Fri, 04 Mar 2016 20:39:09 UTC

Nice article. In general, the description of the open, hard problem of configuration was well-thought. Except for the end comment: "Interestingly, this same separation of computation and data can be seen in the disparate field of front-end development with frameworks such as Angular that maintain a crisp separation between the worlds of markup (data) and JavaScript (computation)" Have you maintained many apps in Angular? I've developed, and also maintained not many, but I still quickly saw any dream of a "crisp" separate evaporate. Sure, it looks nicely separated when you superficially scan the source code database, but no. The most relevant data to the user is almost never in the markup. It's in some service somewhere. And the actual markup they see in the end is a combined end product of the original markup, the data, and some code all mashed together. Not so crips.


precurse | Fri, 04 Mar 2016 16:56:33 UTC

FreeBSD jails brought separate UID namespaces.. Where 0 inside the jail means user nobody to the host.

Also, the limitations of container security only applies to the Linux implementation of it. FreeBSD Jails and Solaris/Illumos Zones focused on security since they were conceived. LXC 1.0 (2014) was the first release to get unprivileged container support! And as most people should know, adding "security" as an afterthought doesn't work well.

It should be noted too that having to run a container in an additional virtual machine just kills any performance gains you get from running on the bare metal with containers. You also forgo your ability to peek into your container from the host.. i.e. Seeing global process usage, debugging (dtrace is extremely valuable to have on the global zone), etc.

Other than those notes, it's a really well written article. Thanks!


vriesk | Thu, 03 Mar 2016 18:19:45 UTC

Actually, separate PID namespaces is one of the feature requests for FreeBSD jails and has never been implemented.


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.