MyDogHasFleas

Ivan, I bought your book "Bulletproof SSL and TLS". It's excellent, and I recommend it to those who are charged with building, deploying, or managing a real world deployment that includes TLS.

It's more than just showing an ID. [See here](http://www.fda.gov/Drugs/DrugSafety/InformationbyDrugClass/u...) item 17.

AFAIK, SABRE is/was an airlines reservation system, not a GDS. SABRE evolved into TPF which is not related to z/OS except inasmuch as they are both operating systems that run on IBM z-series mainframes.

See http://www-03.ibm.com/systems/z/os/ for a list of IBM z-series operating systems.

This is a little mixed up. First trivial point you meant "virtualization" not "visualization". Second, the only thing the 360/67 had (and that was carried forward to the 370 "Advanced Function" line) was a mode bit in the PSW for virtual mode, and the fact that supervisor-state instructions would cleanly trap to the kernel if executed in user mode. There was no "hypervisor hardware", it was all software, specifically the Control Program or CP portion of CP/CMS.

The thing that the System/360 architecture got right was a clean exception mechanism when an attempt was made to execute a "privileged instruction" when in user mode. Privileged instructions were all those that operating systems used to manage and run applications. By having a clean exception/trap mechanism, the hypervisor was made feasible, because it could run the virtual machine in user mode, let the S/360 hardware do all the normal user-mode instructions natively, and trap out to the hypervisor when a privileged instruction was run.

Kudos to Andris Padegs and his original System/360 architecture team for having the foresight in the early 60s to implement the instruction set in this way.

If you looked at the source code of VM/370 CP, which all came from CP/67, you would see code which intercepts exceptions caused by user mode applications attempting to execute supervisor instructions such as SIO (Start I/O) or LPSW (Load PSW), and emulates them like the real S/370 hardware would do. Therefore, a user-mode application could actually be an operating system that thought it was running on real hardware.

SIO is the fundamental way that an OS communicates with I/O devices, all of which were virtualized by CP. LPSW is how an OS dispatches one of its tasks, so CP virtualizes the hardware state and switches the virtual CPU from virtual supervisor to virtual user mode. Of course it's all much more complex than that.

In particular, CP could virtualize an operating system that itself did virtual memory and acted as a hypervisor. If the virtual OS was itself a hypervisor, it would run its second level virtual OSes in (virtual) user mode. The first-level CP would get a privileged instruction exception, and would look a the virtual machine's virtual state and see that it was in virtual user mode. Thus, it would simulate a privileged-instruction execution exception in the virtual machine, which in turn would emulate that privileged instruction for the second-level virtual OS.

The most difficult and compute intensive work was in simulating the virtual memory hardware of a virtual machine that was itself using virtual memory for its user tasks, or in the case of a second level hypervisor, its virtual machines. We had to have code in CP that simulates the translate lookaside buffer for the virtual machine, and also does direct lookups within the virtual page and segment tables maintained by the virtual OS.

But it all worked, and we could happily run virtual OSes like OS/VS1, OS/VS2 (later called MVS), and CP itself, underneath CP as virtual machines.

However, as you could imaging, performance was not great for many workloads. So, the hardware engineers in Endicott and Poughkeepsie came up with "Virtual Machine Assist" microcode, which would step in and run the high-use hypervision directly in microcode on the hardware, which was an order of magnitude faster than doing it in S/70 instructions. A good example is Load Real Address (LRA), which could be run very quickly in microcode.

I spent thousands of hours working on the CP source code, first as a user, then as a developer and design manager at IBM in the early days of VM/370 and VM/SP. I was too young to have been involved in the Cambridge Scientific Center's early work on the 360/44 and later the 360/67, but did get to meet and talk with some of the original people.

The X in Xedit was for Xavier Delamberterie, who wrote it while on assignment from IBM France to IBM Endicott, where I also worked.

No expert here, but I would guess the important bit is the "root": value, which in the example points to rootfs. rootfs, I suppose, would be the directory on the host system containing the entire root filesystem that is to be mounted at /. This could be created using overlayfs, or a COW filesystem like btrfs, which would be how you'd achieve layers.

In this way, the notion of layers is external to the container spec.

Again I'm no expert, so corrections welcome.

I'm old enough that I've lived through these stages:

1) There were no answering machines and no cordless phones, much less mobile. If you called someone at home, and they didn't answer, you just tried later. If you called someone at a business, everyone had a secretary who could pick up if they didn't answer. She (and it was always "she") would write your message on a message slip (they were generally pink) and put it on the person's desk. Or, for smaller businesses, you called the main number, and the operator would connect you, and take a message if no answer.

2) Home answering machines happened. They used cassette tapes, and you could rewind and replay your messages. The outgoing greeting was on a second tape. When you got home, or if you were screening your calls, you'd see a blinking light indicating "new message", then hit buttons to rewind and play your messages. When the tape got full you could put in a new tape or write over the old messages. For businesses, phone systems became smarter and could take voicemail, but this was expensive, many businesses still used the old people-intensive way for messages, and many businesses preferred this because customers liked talking to a real person to leave a message.

3) Mobile phones with SMS became available to consumers. (We are into the 90s now). I don't recall this being especially popular at first, most people still left voicemails, even on mobile phones. But SMS became more and more used over the next decade plus (before smartphones when they exploded in popularity).

4) Fast forward to today. People born after 1980 or so, I find, really don't do voicemail at all, text messaging is the thing. If you leave them a voicemail, it doesn't get listened to. The best you can expect is a callback or a text message because they saw you called, but the usual response is nothing. For businesses, some form of instant messaging (IM) is prevalent inside the company. The IM might say "Hey do you have a minute to talk OTP?" but no one just calls someone else cold, much less leaves a voicemail and expects a response.

IMO stage (1) actually worked fine, and now that we are at stage (4) that works fine too (as long as you don't pretend voicemail is a thing and use other means of communication). The intermediate stages were awkward at best.

I think Coca-Cola's action makes a ton of sense for any company. Maybe it was fear of legal discovery that prompted it, maybe it was what they said (streamlining operations), but it is a good thing, IMO.

With SOFTWARE. It's the latest thing.

Are we talking about the same thing?: https://github.com/docker/docker/pull/8859 ???

It had no etcd in it and the POC was implemented as part of the Docker API/CLI, as best I recall. There were significant questions in the discussion about etcd not being there.

Yes and Pivotal (CloudFoundry) has posted a fairly supportive blog entry on Rocket. So it's not just CoreOS "making a play".

https://news.ycombinator.com/item?id=8683540

I attended Docker Global Hack Day #2 on Oct 30 from Austin. A talk was given on an active Docker project for host clustering and container management, which was non-pluggable, and made no reference to and used none of the code from CoreOS's etcd/fleet/flannel projects.

This was where I first started worrying about CoreOS and Docker divergence.

The use case for our startup is: we have lots of compute and graphics intensive services being created and tested on Macs by developers, targeted for Linux Docker instances in the cloud. It would be nice to be able to run these same containers natively on OS X rather than requiring developers to bring up a local hypervisor (e.g. VirtualBox) and a local virtual Linux instance). This would help with both dev and test. Additionally, sometimes our engineers would like to be able to run compute jobs locally and merge the results back into the cloud based system.

This is the only on-point comment so far.

At some level both these apps are big time enablers of copyright infringement. Maybe you don't think that's a bad thing and all copyright laws should be gutted, or maybe you want to play lawyer or (worse) make analogies. That is totally not the point here.

The point is, what some view as copyright infringement, others view as unsatisfied demand. Music has already crossed the chasm, but that's probably more because there is so much more of it in such smaller economic units. Big budget movies have more mass and will find it harder to leap that chasm to streaming services.

I think that if anyone manages it, it will be Apple. And it will start with TV, not movies.

I will take issue with cheald's "marginal manufacturing cost" argument, a big budget movie has to make back its gigantic capital investment, and each unit of consumption has to pay its share.

Do this thought experiment. What if Torvalds (or the equivalent) had never created the Linux kernel and put it under GPL? Where would GNU be today? And would you be thinking RMS is The Man?

I would say the pedantry is on the other foot. :)

Your drunk driving analogy is strained to say the least. Net neutrality has not been in effect though all of ISP history, except for a brief period before the courts shot it down. To compare that to a hypothetical drunk driving law scenario is way off the mark. It's much closer to reality, as opposed to pedantry, to say that the new regulations don't disallow the ISPs from charging fees, because for almost all of history, there was no regulation about this.

Regarding fast/slow lane, you are making two logic errors. One, implicitly assuming it's a zero-sum game, when it's not. The FCC's intent is to incent ISPs to increase capacity so they can allocate that capacity for new (paid) services. Not to slow down existing clients. Two, assuming we are just talking about bandwidth. Quality of service in all its aspects could be on the table for paid services. Bandwidth alone is not sufficient for good streaming.

Let's parse the premise.

"If net neutrality fails"

-- "net neutrality" -- you probably mean the currently popular version of this, which is "don't let ISPs create fast and slow lanes, and charge for the fast lanes." Or, even less precisely, "Don't let ISPs slow down the Internet."

The problem with this is, the FCC is actually not proposing to let ISPs create "slow lanes". It is proposing to allow ISPs to charge fees for better quality of service, not to degrade the service that's already provided. In fact the proposals quite specifically forbid this.

-- "if ... fails"

The problem with this is, net neutrality is not in effect now. And has not been at all in history, except for a brief period before the courts shot it down (because the FCC was overstepping its authority). And, nothing like the "fast/slow lanes" version of the predicted net-neutrality-copalypse has happened.

So to say "what if net neutrality fails" has it exactly backwards. We already know what the no-net-neutrality world looks like, we are in it now. The real question is, what if it succeeds? What will happen then?

There's no difference between "allow" and "not disallow"? There's a huge difference.

"Allow" means to affirmatively allow ISPs to charge fees when they couldn't before, while "not disallow" means to not put new regulations in place stopping ISPs from charging fees.

"You can hardly fault them for their language choice" -- to me it's much more than a language choice, it's saying something correctly or incorrectly, realistically or framed in some other reality.

And if saying it correctly "implies avoiding unwanted government interference", does that justify saying it incorrectly? Do the ends justify the means? Is propaganda OK if it's for a cause we believe in?

An analogous discussion for "slow down/make inaccessible" vs. "not speed up". There's no difference between these things? I think there's a huge difference. If I'm a company that doesn't pay the fee, will I get the same service I did before, or will I be slowed down/cut off?

As I read the proposed FCC regs, it's pay-for-speedup rather than don't-pay-and-get-slowed-down. But this "Internet slowdown day" campaign is explicitly saying that sites will get slowed down. How do I reconcile these two things?

re Internet Slowdown: I'm stuck on a dissonance between the status as presented vs. the reality as I understand it. I may well be wrong/uninformed and I'm happy to be educated if so.

Here's the status as presented:

"Battleforthenet.com (a project of Demand Progress, Engine Advocacy, Fight for the Future, and Free Press) has organized a day of protest against the United States Federal Communications Commission (FCC) proposal that will allow Internet providers to charge companies additional fees to provide access to those companies’ content online. Those additional fees will allow Internet service providers to essentially choose which parts of the Internet you will get to access normally, and which parts may be slow or inaccessible."

Here's my 2 points of dissonance:

1. "...FCC proposal that will allow Internet providers to charge companies additional fees to provide access to those companies’ content online."

a) the FCC proposal is about allowing Internet providers to optionally provide higher speed/quality access for a fee, not about "charging" fees "to provide access".

b) There's nothing stopping Internet providers from doing this right now, since the original FCC net neutrality regs were shot down by the courts. So saying the FCC proposal would "allow" them to do it is not accurate, as they are "allowed" to do it right now.

So, as far as I know, the correct statement would be:

"... FCC proposal that would not disallow Internet providers from providing an optional fee-based service to companies for higher quality/speed access to the companies' content online."

2. "Those additional fees will allow Internet service providers to essentially choose which parts of the Internet you will get to access normally, and which parts may be slow or inaccessible."

From reading the FCC proposal, I think that an ISP would not be allowed to slow down or make "inaccessible" content from companies that have not paid a fee. Rather, the fee would be to improve speed/quality of access to a company's content.

Pavlicek's article takes the form of "Docker is a lightweight VM. It is not as secure as hypervisor-based VMs. Hypervisor ecosystems can and are getting more lightweight, and so maybe they'll win the battle."

Framing the discussion this way is of course a false dichotomy as jpgvm ably points out.

However, I would not start out by pointing out the technical issues with the article. I would start by viewing this article is as technical competitive marketing material, rather than as an attempt to have a serious technical discussion about VMs and containers. Russell Pavlicek is the lead Xen technical evangelist.

My alternative: 1. Toss receipts into a file folder per month. Time: <5 seconds per receipt. 2. At tax time, go through receipts and pull out tax related ones. Time: 30-45 minutes. Total time spent: an order of magnitude less than imaging/uploading receipts over the year. Security: never leaves your house. Cost: 12 file folders. Additional benefit: easy to find receipts by month for returns or disputes. Don't have to reprint receipts.

The real question is, what is the interface you are virtualizing, and how do the characteristics of that interface influence the design of the OS you are building?

Hypervisors virtualize the hardware interface: the user-mode and privileged-mode instruction sets, the I/O ports and channels, the memory model. This is good because that interface is stable and well-understood, allows for a high degree of isolation between processes, and has a large number of applications (operating systems) already written to the interface ready to run on the hypervisor. This is bad because the interface is more low-level than one would like as an API for programmers, requiring another layer (the OS or at least kernel) to make it usable.

Microkernels, or kernels in general, provide a system-call interface that is made up by the OS designer. This is good and bad in a mirror image sort of way vs. the hypervisor. It is good because the interface is more suited to programmers, providing OS level services rather than presenting as bare metal. It is bad because the interface is less stable (evolving in software time rather than hardware time), less provably or practically isolating between processes, and has a smaller ecosystem of applications already written to that interface (perhaps zero if it's brand new).

It is useful to view kernels, microkernels, and hypervisors as points on a spectrum of virtualized interfaces. One can see hypervisors moving towards kernels with virtual additions to the hardware interface, such as paravirtualized I/O devices, special trap instructions to communicate with the hypervisor, and optimizations such as page sharing, snapshotting, and live motion.

Microkernels can also be viewed as moving to a smaller, cleaner system call interface on the spectrum, with greater stability and isolation between processes than a "big" kernel. But the issue of lack of applications written to the interface remains.

The ascent of Linux containers hits a sweet spot on this spectrum IMO. Linux containers virtualize the Linux system call interface, which has become relatively stable, certainly has a large body of applications written to it, and provides a "good enough" degree of isolation among its containers (which keeps improving).

IMO the ascent of Linux containers is on a hockey stick curve right now (due to Docker having simplified and standardized its interface and container format/management) and will overrun any debate like this between hypervisors and microkernels, for those of us not doing academic OS research. Virtual machines will not go away, but will be used more for their original purpose, to allow running completely different OSes on the same hardware, and to provide completely isolated OS instances, rather than as general purpose compute capabilities a la IaaS.

Aw come on, all you have to do is let your users choose an icon of their favorite animal or sport, save that as an account preference, and show it to them while they enter their password. We don't need better certificate verification!

Good points, but I would argue that HTTPS provides little protection against this kind of access tracking.

Even if the site is HTTPS protected, a surveillance actor on the net would still be able to read the entire site, maybe to determine if the site has content worthy of tracking those who access it.

And, surveillance would still reveal that your IP address is accessing the site, and thus triggering something.

What HTTPS would protect is the specific URL path you are going after on the site, because that's in the HTTP GET which is part of the encrypted data traffic.

I guess you could say that maybe the site has some pages that are more sensitive than others, and revealing the exact URL paths you are accessing might set off a surveillance trigger that would otherwise not be noticed. But, the site in question is probably not like that.

I don't know why you're bothering with SSL at all. Your use case is that your site is informational, it's intended to be open to anyone, there is no personal/customer information on it, and there's no authentication (everyone is anonymous).

All adding HTTPS support will do is make it marginally harder for someone to spoof your site.

And why is NSA surveillance a concern? Your site is wide open for anyone to see, with or without HTTPS.

Washington Post: http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/08...

You may not include the Drudge Report http://drudgereport.com in your definition of MSM, but they have huge readership. They linked the WaPo story this morning.

Yep, you're right. I wasn't thinking about their specific business model and customer set. Thanks for setting me straight.

I wonder what the Lavabit TOS and privacy terms actually said? Usually they say something like "we will not disclose ... Except to comply with legally served requests..." I'm curious whether Lavabit had something different here.

Perhaps this suggests a new business model, a sort of turbo canary, where the service explicitly commits to shut down rather than comply with a secret order which it would otherwise be compelled to obey.

Where's the "I wish you hadn't done that, lavabit, I'm a customer and I feel very screwed over by this action" comments?

Or is this appropriate for any SaaS vendor? You're OK with this? Should all customers, even those who really don't care if the NSA could be watching, be put out because some feel that this cause trumps actually doing business and having customer-vendor relationships?

I could see someone suing an SaaS vendor for an action like this, actually. "You cost me $XX in actual costs and $YYY in lost business. Your TOS says nothing about your shutting down because the government asked you to do something you didn't agree with."

After reading the whole VF article I come to two conclusions.

1. If you work for a company which (as I'm sure GS does) has a policy forbidding you from uploading company data to the public cloud, don't violate that policy. Especially if it's source code you wrote while working there. (The open source argument is a red herring. It doesn't matter.). And super especially if you're about to leave for a competitor.

2. If you work in an industry and for a company that is being scrutinized by the Feds and is heavily regulated, really REALLY don't violate policies like this arbitrarily and on your own, because you might go to jail.

Is it "fair" what happened to him? No. But lots of unfair things happen. He paved the way with his thoughtless actions.

It'll be interesting to see what happens with this. You may be right. Depends on how enterprising Contra is, and how willing the studio is to engage in more than just selling some rights and walking away. It's not really that much potential revenue, the studio may not want to do any more.