> By eating Linux's lunch I meant how good, reliable and capable the zones and lx-branded zones technology is.
Could you then use idioms in their proper meaning, please? Because I only
protested against claim that zones have taken a market share of Linux
containers, which is very untrue, and at the same time not the claim you have
made.
> As for those people, they had to learn Linux too; they can go back to the roots and learn a real UNIX the correct way now, and be glad that they have the opportunity to do so.
So, zones provide better platform because people can go back and learn
Solaris? Or what?
Zones need to provide something tangible over containers for people to invest
in learning different platform. Having just another tool, which merely does
what one already can do with containers, only slightly slicker, but severly
limited in applicability because parent platform is not familiar to all the
colleagues, doesn't look like a good trade.
And note that we were only talking about familiarity. There are still other
reasons, like little developers working on a given Solaris derivative, which
doesn't give much confidence that any bugs that occur would be fixed, or
a concern that the supported hardware list will be long enough.
...It can refer to market share like you argue, but in a broader sense, this is at least how I understood the term eating someone's lunch.
> So, zones provide better platform because people can go back and learn Solaris? Or what?
No, Solaris (well, illumos, since nobody cares about Solaris any more) provides a better platform for learning and understanding UNIX. And with that comes the insight of writing better code in general, especially on Linux. For example, one is able to write completely portable shell code and deliver cleanly packaged software on Linux if one understands UNIX (in /opt, /etc/opt/, and /var/opt instead of /usr[/local] -- and that is just one trivial example).
zones are a fully working solution because they provide full security isolation, while running as regular processes with their own init(1M), instead of being forced to run Docker inside of KVM or XEN virtual machines to achieve that. And because processes inside of zones are just regular processes in the global zone, they only use as much resources as they need, and no more. With zones, one does not have to hard partition and preallocate memory and CPU to achieve full isolation, as is very often the case with running Docker inside of a virtual machine.
And because zones' storage is backed by ZFS, the data is guaranteed end-to-end integrity, and self-healing if the zpool is redundant (RAID1+0, RAIDZ, RAIDZ2).
For its part, illumos is the reference system as it is fully POSIX, XPG4, and SUS / UNIX03 compliant, so learning it means learning and mastering the standards.
And, once spoiled by all the nice features in illumos / SmartOS, going back to Linux feels like going back to skins and stone knives.
> Sl. to best someone; to defeat, outwit, or win against someone.
> ...It can refer to market share like you argue, but in a broader sense, this is at least how I understood the term eating someone's lunch.
It's still a far stretch to claim that zones win against containers. They
could if we limited the field to just technical level, and then again, I would
need to see some arguments why they actually are better.
>> So, zones provide better platform because people can go back and learn Solaris? Or what?
> No, Solaris [...] provides a better platform for learning and understanding UNIX.
You're confusing here learning unix with using it.
If one was at the stage of learning, Solaris could be fine, except there's
much less material about it for newbies (especially about rough corners and
stupid troubles, like "I ran `chmod -R 777 /'" or "I deleted my kernel"), and
much, much less knowledgable people accessible to those newbies to learn from.
Now look at professional Linux sysadmins and programmers. They already have
some knowledge about their OS and they're not likely to do a hard turn for
different OS just for the sake of "understanding UNIX", as it would require
quite large effort to just get to the point where they are already with Linux.
Solaris would need to provide a really compelling function or feature to
justify this effort, and all you said is "portability" (which most probably
won't be necessary in most cases) and vague notion of "understanding UNIX".
EDIT: It was a little dishonest on my side to suggest that main selling points
of Solaris derivatives were "understanding UNIX" and "writing portabile code".
Solaris introduced ZFS and DTrace. But while it is said that ZFS with zones
work well together, it still needs explaining why is it a significantly
better combination than what Linux provides, and DTrace seems like a very
distant benefit, less compelling each time a tool like Sysdig shows up.
> They already have some knowledge about their OS and they're not likely to do a hard turn for different OS just for the sake of "understanding UNIX", as it would require quite large effort to just get to the point where they are already with Linux.
How about no priority 1 incidents at 02:03 in the morning, resulting in sleepless nights until 07:30 - 08:30 every day during one's on call, wasted on stupid problems like ext3 filesystem corruption caused by lost writes (again: http://danluu.com/file-consistency/)? Is that a compelling enough reason?
No incidents at dead hours of the night.
A programming environment fully supporting standards.
Same software which runs on Linux.
Guaranteed application binary interface backward compatibility: compile on oldest SunOS 5.# you can find, run on all the versions newer than that one.
Change schedulers on the fly, as you need them.
Realtime subsystem.
kdb and mdb: the best post mortem analysis tools in the industry (what are those system administrators going to do when the kernel crashes so bad that it locks up and doesn't dump a stack trace?)
Full security isolation and bare metal performance with zones.
Exhaustive documentation ("he who can read is clearly at an advantage"), much of it applicable to illumos / SmartOS:
> How about no priority 1 incidents at 02:03 in the morning, resulting in sleepless nights until 07:30 - 08:30 every day during one's on call, wasted on stupid problems like ext3 filesystem corruption caused by lost writes (again: http://danluu.com/file-consistency/)? Is that a compelling enough reason?
I won't have calls about corrupted ext3, because I use XFS, so not much of
a point.
"No priority 1 incidents" is not a function of an operating system, so it
can't be a compelling reason to switch. You would still need to elaborate why
exactly Linux doesn't work, especially when it works well enough in most
admins' perception.
> A programming environment fully supporting standards.
Becasue Linux doesn't support a very important standard of... Could you help
me here? Nothing comes to my mind.
> Same software which runs on Linux.
Sweet. I should learn Solaris, so I can run the same software as I currently
can on Linux.
Do you hear how ridiculous this point is?
> Guaranteed application binary interface backward compatibility: compile on oldest SunOS 5. you can find, run on all the versions newer than that one.
Only ABI of kernel and (probably) OS-supplied libraries, which is not that
much when it comes to what most of the companies run.
> Change schedulers on the fly, as you need them. Realtime subsystem.
Of course, because Linux doesn't allow to change schedulers and has no
realtime subsystem.
> kdb and mdb: the best post mortem analysis tools in the industry (what are those system administrators going to do when the kernel crashes so bad that it locks up and doesn't dump a stack trace?)
This is a very distant benefit. One needs to be accustomed with kernel-level
code in the first place to make any use of these.
> Full security isolation and bare metal performance with zones.
You get bare metal performance with Linux containers as well, so not a strong
point. Only the "full security isolation" could be a sensible reason, but
then, it should be proven by close scrutiny. I haven't heard too much about
people analyzing Solaris zones, so I'm not likely to be convinced out of thin
air that this argument applies.
> Exhaustive documentation ("he who can read is clearly at an advantage"), much of it applicable to illumos / SmartOS:
This is barely enough for a trained sysadmin to learn how booting works and
where to nudge when things go awry or how to do less standard tasks (e.g. I'm
not sure how much time would it take me if I needed to build a custom live CD
image; probably quite a lot, judging from boot(1M) man page).
Even if it's exhaustive, it suffers from not having much between
step-by-step-and-don't-think instructions and deep documentation that requires
prior understanding of the system.
> Should I go on?
You haven't provided many arguments that would be sensible reasons (let alone
being strong reasons) to invest in migrating to Solaris.
I think we should disengage from this discussion. If I was in (what I believe
is) your state of mind, I couldn't muster any good argument that would
convince my interlocutor.
Could you then use idioms in their proper meaning, please? Because I only protested against claim that zones have taken a market share of Linux containers, which is very untrue, and at the same time not the claim you have made.
> As for those people, they had to learn Linux too; they can go back to the roots and learn a real UNIX the correct way now, and be glad that they have the opportunity to do so.
So, zones provide better platform because people can go back and learn Solaris? Or what?
Zones need to provide something tangible over containers for people to invest in learning different platform. Having just another tool, which merely does what one already can do with containers, only slightly slicker, but severly limited in applicability because parent platform is not familiar to all the colleagues, doesn't look like a good trade.
And note that we were only talking about familiarity. There are still other reasons, like little developers working on a given Solaris derivative, which doesn't give much confidence that any bugs that occur would be fixed, or a concern that the supported hardware list will be long enough.