evol262

We make our money on support.

A nontrivial amount of bugs fixed upstream are found and reported against in-support versions of RHEL. But in a broader sense, there's no "immediate return on investment" pressure here.

We work with upstream communities. So there are upstream planning meetings which set feature development, which anyone is free to participate in, or we directly participate in apache/openssl/gnome/openstack/whatever meetings. New features are set and developed by the upstream product, where we (as developers) spend a lot of our time. We're not doing it in-house and pushing it back.

We try to make sure they're tested and stable through CI and QE testing (foo-1.2.3.noarch gets marked as the version in which bug #1234 is fixed in -- QE tests and verifies this before release).

There's some emphasis there because Satellite, Openstack, RHEV, and other "server" product entitlements and support are our revenue stream, but there's a significant desktop team, and kernel team, etc. We as a company are much less focused on what makes money and more interested in "what's the best tool for this job" and "how can we push Linux forward".

To that end, there's a heavy lean towards GTK/GNOME solutions over QT, but that's more culture than corporate direction. And there's a "disproportionate" amount of effort towards server products because that's what people use Linux for and that's what we work on, but the community drives our priorities, not the other way around. We're a relatively small company (for our revenue), and people work in one area. If I'm working on Openstack (upstream and downstream), pretty much all my effort is going there and none is going towards Firefox (or whatever). But being on a product team/niche isn't any different at Red Hat than anywhere else.

Our policy at Red Hat is upstream first. Work is being done upstream and benefiting Arch and everyone else. It's not on Fedora. Fedora just benefits from an extremely good QE cycle compared to other distros, and a well-integrated set of packages, which is something rolling-release distros don't offer, not that there's anything wrong with that.

RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas.

Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.

It's maintainable, modern code, which screen is not. Screen is not dead yet, but it eventually will be.

Isolation. uid 0 is treated specially, and root breakouts inside containers (especially containers which aren't constrained by the audit subsystem in some way, like grsec or selinux or apparmor) or kernel exploits can bust your whole system open, among other security risks with containers.

hypervisor breakouts exist, but they're much rarer.

>The entire point o using something like CoreOS or Red Hat atomic with Docker is to stop paying VMware thousands of dollars for each server.

No, it isn't.

Containers (and app containers) are not competitors to, replacements for, or equivalent to traditional virt. While there's some overlap in cases where there's deployment from golden templates or glance images or AMIs or whatever just to get isolated apps, traditional virtualization and containers are complementary technologies.

Technical details aren't out yet. They may not have implemented it, but given their comments about performance and scaling, it would be a very good reason not to support NFSv3.

It's almost certainly NFSv4 only so they can utilize pNFS

Watch people would much rather wear a cheaper mechanical than a gimmicky smartwatch.

"I have no idea how modern systems boot, because I haven't kept up on the changes happening in the last 10 years. BIOS 4evah!" -> UEFI is somehow bad. k

You're affirming the consequent. We don't have receptors for plants found in the wild (cannibis, nicotine, etc). Rather, compounds formed by those plants match up with receptors we already have.

There's an entire endocannabinoid system, and it's not because pot is natural. Nicotine broadly matches up with acetylcholine and nicotonic acetylcholine receptors.

It's far more likely that plants evolved and selected for compounds which have beneficial/detrimental effects on possible consumers, like nicotine as a pesticide, than it is that we have receptors for plants found in the wild on the off chance that we may have consumed them or that they would have been so prevalent in the past that receptors for them would have been selected for.

That's also what any sane configuration management system does for you.

Don't get me wrong, I think docker is great, but this whole "I get simple idempotent machines" is a solved problem. Docker excels at bundling applications with all their dependencies as an modern analogue to statically linking, or a Linux equivalent to OSX's .app

Yeah, because Verifone's extant NFC readers definitely aren't standardized at all and haven't worked for years, with wide enough adoption that Whole Foods, Circle K, and fast food chains have them already. Everyone's just waiting for Apple to come along with the "standard of quality".

Are you seriously linking a study from the 40s from a blog post hawking a book? Please go read the last 80 years of nutritional research.

No, we aren't arguing semantics. You're arguing semantics now that you have a lot of qualifiers on the statement you made earlier.

Your initial assertion was that high insulin levels cause fat storage (really, insulin causes blood glucose to drop, either through glycogen uptake in muscle tissue or lipogenesis and glucagon causes it to rise via the opposite mechanisms) in response to the prompt:

> Would you lose more weight drinking two liters of coca-cola a day or eating the equivalent total calories in a high-fat protein rich food?

I'm sorry that my made-up scenario isn't the same as your made-up scenario, which now has a ton of conditions and it suddenly "real life".

Yes, in real life, someone who consumes 2000 liquid calories is going to be hungry. As is someone who consumes 2000 calories of bread. Or donuts. Or anything else which is digested rapidly (and this is exactly why I brought up satiation).

But this isn't a "hormone imbalance." This is, in fact, absolutely typical and ideal action from hormones doing their job, unless your made-up-real-world scenario now also involves people with insulin resistance. Because 2000 calories is 2000 calories, and while studies show that the normal metabolic range is +/- 200kcal from calculated bmr, "hormones" are not some wild card. Men eat more (higher bmr, testosterone promotes liposysis and better nutrient partitioning), but a man or a woman doesn't go through massive hormonal changes on a regular basis, and consumption of an equivalent number of calories from different macronutrient groups can be expected to have about the same effects on composition (unless it's all protein, in which case you get to worry about dying).

If you want to discuss hypothetical scenarios (2000 calories of sugar vs equivalent total calories in a high-fat protein rich food), discuss them. But don't change your stance when someone questions you.

This isn't how homeostasis works at all.

Insulin levels cause fat storage in order to lower blood sugar levels. If all you did was chug two 2-liter bottles of Coke, you'd temporarily go through lipogenesis, then go back through lipolysis to pull the stored calories back out for use later in the day.

Insulin doesn't magically make you fatter if you're consuming the same number of calories. A high protein/fat diet is more satiating and you consume less calories, but insulin is not evil.

UNIX never meant anything. z/OS is UNIX. Even the Single UNIX Spec never clarified anything other than "UNIX includes these things". People who rail about how systemd "isn't UNIX" never had to maintain a heterogenous environment of IRIX, Tru64, HP-UX, AIX, and Solaris. They're all UNIX. OSX is also UNIX. Guess how similar they are and how many design philosophies they share.

Coreutils has a lot of binaries that do different things. Is is monolithic? The GNU ecosystem and autotools barely function without other GNU tools which aren't part of the same project. Are those monolithic? Monolithic is a canard.

You're damning journald for things syslogd doesn't do either.

Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted).

Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing.

Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger

Conflating the aims of everything underneath the systemd umbrella is misleading regardless of whether you think monolithic and modular aren't mutually exclusive (and hey! systemd isn't monolithic or modular -- the additional bits run separately, they don't plug into systemd), akin to lumping everything in coreutils under the same "coreutils is trying to take over Linux!" argument.

Except systemd isn't monolithic at all. It's 70 bits under one umbrella project, and you only need three of them to replace init. But because it can do something doesn't mean it does that thing out of the box or even in the default configuration. Even on Fedora (or CoreOS), where systemd has the most uptake.

Why is it that every systemd critic doesn't know what systemd is or does?

Because they already defaulted in 2001 and got into a spat with the IMF and various investors from western nations who tried to capitalize on their misfortune.

In Krugman's mind, Argentina is disparaged because they don't really want to be part of the western "system" of investment in the national resources of South American nations by developed powers.

I know conservatives don't like Krugman, but the man didn't win a Nobel for nothing, and linking a two year old article is simply misleading.

> I still believe you are wrong and I did not claim Docker was a general container solution

>I'm sure Docker is appropriate for some specific situations, but it is not currently an appropriate general container solution if you care about security.

>Docker doesn't provide the full security isolation that Solaris Zones does; I'm sure it's the right style of solution for specific cases, but it is not an appropriate general solution for isolation or containerisation.

Tell yourself whatever you need to.

>You don't know how Solaris Zones work, because if you did, you'd understand that cgroups are insufficient to provide the same level of security.

Which is why I also mentioned (and even linked you to the documentation for) docker_selinux, which is actually security instead of mere process isolation through namespaces and resource control (which are what cgroups do). Incidentally, this is the same way non-labeled zones work, but I guess I don't know anything about those.

Think whatever you want.

>I am not repeatedly missing what Docker does

>I'm sure Docker is appropriate for some specific situations, but it is not currently an appropriate general container solution if you care about security.

Yes, you are. Docker is not currently and is not trying to be a "general container solution". Again, that's LXC.

But "X is currently insufficient as 'true isolation'" is inane. libcontainer is built on top of kernel cgroups. Docker can be wholly isolated with selinux:

http://www.mankier.com/8/docker_selinux

You don't know what Docker does, you don't know what it's built on, you don't know how cgroups work, and you're entirely ignoring selinux.

Please stop.

You're missing the point --

It's not unreasonable to compare the functionality of zones in 2014 with the functionality of vserver in 2014. But you compared the functionality of zones in 2014 with the functionality of vserver in 2005 (which hasn't changed much).

LXC is the preferred container solution and has been for years. I only referenced vserver because of your "Linux finally catching up to zones" comment, when Linux has been doing containerization as long as Solaris.

I'm also not going to "provide any data" about vserver. You can look at the release dates for vserver, openvz, and lxc yourself, as well as when lxc made mainline and how many VPS providers use openvz, versus how many distros even package vserver in 2014.

LXC made mainline for a reason. OpenVZ is pretty comparable in features. You're making a sideways argument now based on Linux not having ZFS, but that isn't the discussion. It's also true that Linux doesn't have Crossbow. It's not true that LXC and OpenVZ can't take advantage of openvswitch, which is pretty comparable. But none of that has anything to do with Docker. This is not "LXC vs Zones vs Jails".

Containers can also be backed by btrfs or lvm cnapshots, which aren't as feature-filled as ZFS, but you're reaching. Similarly, zones aren't as featureful as full-fledged VMs. But that's also not what we're talking about.

You're repeatedly missing what Docker actually does. Ok?

Zones -> LXC. LXC also has "weight" in that it starts init and basic services, and has to be managed.

Docker -> containerized chroot. Docker is not an analogue or competitor to zones.

However, Docker (through libcontainer) are already built on top of cgroups and can be managed through selinux. Security is not a valid complaint.

Docker is application containerization.

While Docker is built on top of libcontainer and cgroups (used to be LXC), traditional containers, including LXC and zones, start init and enough services to look like a "normal" system. You can still use rc.local to manage applications if you want to, I guess.

Docker is a build system for containers which run /bin/foo as PID1, with no services, no ssh, and no init (which presents other problems reaping children, handling sigterm, etc). It's containerization for application virtualization.

It's unreasonable to compare the functionality of zones in 2014 with their functionality in 2005, when vserver was contemporary and the principal containerization solution.

In 2014, you'll find that LXC or OpenVZ (or Xen paravirt in some environments) are the preferred virtualization solutions and have been for years, which have every advantage zones have.

By "weight" of zones, I mean that they're still effectively Solaris containers running init and basic services. Linux containers do this. Docker doesn't. It's app virtualization.

It's not a paradigm which even remotely threatens VMware's use case, though.

It's analogous to App-V or an Application LPAR, if such a thing existed, but these are both good examples.

My complaint to the previous poster is mostly that it differs in the same way that an Application WPAR differs from a WPAR. Yes, they're the same base. No, they're not the same thing.

Not really. Even in an absolute sense, linux-vserver is/was contemporary with zones.

Yes, in the sense that partitioning technology isn't new. zones and jails are comparable to vserver/openvz/lxc. vpars, lpars, and ldoms have analogues on mainframes. Various hypervisor technologies (xen, kvm, vmkernel) are also not unique to solaris, and were done on Linux.

What Docker offers that none of these do not is that it's containerization for applications without the "weight" of even zones. It's not virtualizing systems. It's starting one application in its own container. That's it.

I don't know who's spreading this "Docker is just like zones" FUD, but it's wrong. Linux has had container-level virtualization for a decade, and LXC has had mainline support for a while. Docker builds on that, but it's different.

At the same time, EMC is not shitting themselves over docker. Application containers will not replace traditional or container virtualization for all workloads. But they will for some.

You're missing the point, which isn't that "badly-maintained software" and "technical debt" are the problems. It's that I, as a developer who writes Python which runs on Fedora, EL[6|7], Gentoo, Debian, Ubuntu, and Arch have to go through an inordinate amount of testing and hoop-jumping in order to make sure that my application runs on EL6 and Fedora, to say nothing of systems which aren't guaranteed to have the same package names, library locations, or major versions of Python, much less having it at all (especially a problem on EL6 and Gentoo).

It makes sense for me, as a developer, not to go through repackaging and retesting for 7 distros with 4 different packaging paradigms and 3 init systems when I could simply tell you to run a container. None.

Disk space and memory are now cheap. Statically linked binaries are coming back. Containers as the new /opt strike a middle ground between distro portability and developer effort. It must be nice for you to live in an ivory tower.