Rodrigo E. De León Plicet wrote:
On Fri, Jun 25, 2010 at 9:08 PM, Erik Trimble <erik.trim...@oracle.com> wrote:
(2) Ubuntu is a desktop distribution. Don't be fooled by their "server"
version. It's not - it has too many idiosyncrasies and bad design choices to
be a stable server OS. Use something like Debian, SLES, or RHEL/CentOS.
Why would you say that?
What "idiosyncrasies and bad design choices" are you talking about?
Just curious
I asked Erik about this. Here is the consolidated discussion:
E>>>>>> (2) Ubuntu is a desktop distribution. Don't be fooled by their
E>>>>>> "server" version. It's not - it has too many idiosyncrasies and bad
E>>>>>> design choices to be a stable server OS. Use something like
Debian,
E>>>>>> SLES, or RHEL/CentOS.
H>>>>> Can you explain some of or link me to the bad design choices or
H>>>>> idiosyncrasies that make Ubuntu not stable as a server OS?
H>>>>>
H>>>>> I'm only refering to the Ubuntu Server LTS releases (5 year long
term
H>>>>> support) which to date have included 6.06, 8.04, and 10.04. The LTS
H>>>>> releases are held to a higher standard (more showcase) than their
other
H>>>>> releases (testing). Ubuntu uses non-LTS releases to encourage rapid
H>>>>> project development (e.g. adding GRUB2 in 9.10). I won't argue
about
H>>>>> the non-LTS releases.
E>>>> Specifically, even on the LTS releases, the "server" version actually
E>>>> uses the same packages as the "desktop" version, which leads to
problems
E>>>> with assumed defaults. Classic case is iptables, where many of the
E>>>> management packages that go with it use desktop-oriented defaults
rather
E>>>> than server-oriented defaults. So, when you upgrade (or, even just
E>>>> update), it tends to break things.
H>>> I've seen stuff break on upgrades as well, although updates have
been fine
H>>> for me. This breakage is why I delay upgrades on shared machines that
H>>> impact others (e.g. on HTPCs with MythTV on Ubuntu) until I know I
can do
H>>> a clean slate rebuild if the upgrade doesn't go right, and often do the
H>>> clean slate rebuild anyway. I treat an Ubuntu upgrade similar to a
H>>> Windows upgrade (e.g. WinXP to Win7).
E>>>> I've also seen issues with obsoleting/removing packages (or, more
E>>>> likely, specific items from packages) without notification. I lost the
E>>>> libstdc++5 library after 8.04 (it's not even in the 10.04 LTS), and
E>>>> there was no mention of it being deleted, not even buried in release
E>>>> notes.
H>>> Features lost to claims of 'UI design improvement and
simplification' are
H>>> right up there on the annoyance list. Removed features often end up in
H>>> big discussion threads on http://brainstorm.ubuntu.com/ . This moving
H>>> target characteristic certainly makes it harder to get programs working
H>>> that aren't already in the repositories. At least an LTS release has a
H>>> safe 3 year usage window (as all LTS packages are maintained for 3
years,
H>>> and server packages are maintained for 5 years).
E>>>> Ubuntu doesn't seem to really care about long-term stability. I'm not
E>>>> talking about the kernel ABI (which, is really out of their
hands). I'm
E>>>> talking about being very careful about not breaking userland and
E>>>> admin-land stuff without advanced notice, and significant failure to
E>>>> support a transition period. Stuff just goes away and/or breaks at a
E>>>> whim between releases.
H>>> Ubuntu's long term stability (i.e. software compatibility) appears
H>>> intended to stay within a single LTS version, which I feel is really
H>>> only 'for sure' for 3 years. That is on the short end of the range of
H>>> even popular general desktop OSes (WinXP is an outlier).
H>>>
H>>> In spite of its shortcoming, the primary advantages Ubuntu
maintains are
H>>> 1.) wider, earlier hardware support
H>>> 2.) rapid iteration: a regular release cycle that gets software into
H>>> testing and use, in preparation for the next release cycle for that
H>>> software and Ubuntu as a whole
H>>>
H>>> I think Ubuntu LTS still makes sense for machines (even servers) that
H>>> don't need long-term stability (i.e. software compatibility) and can
H>>> benefit from the earlier hardware support it offers. It's not an
OS to
H>>> install and leave alone (only patching) for extended time periods.
E>> All of which is fine if you're running a home server, or maybe designing
E>> a black-box device. None of which is acceptable for general-purpose,
E>> server-room machines.
H> It is fine for virtual servers intended to run small/ephemeral
H> websites that you don't mind migrating again in the near term. Not so
H> good for an important piece of backbone infrastructure that simply
H> needs to run without periodic tuning.
E>> Product cycles there are 8-10 years, and there
E>> has to be significant upgradability (i.e. I should be able to expect to
E>> upgrade my OS and not break anything for a span of about 20 years,
E>> covering probably 3 major releases). Solaris, AIX, and HPUX can all do
E>> this, as can RedHat and SuSE/Novell. Ubuntu's just not server-room
E>> ready, and won't be until they decide to change the development goals
E>> for the "server" product version. Which, I think, is unlikely
H> In that respect Microsoft did pretty well with Windows and backwards
H> compatibility. A fair number of Win 3.1 apps (~1992) still work fine
H> on 32bit WinXP (2001-present), although sometimes DLLs/libraries must
H> be tracked down. I find the expectation of little breakage over 20
H> years a bit much. Sure, between two adjacent significant releases can
H> be expected, but beyond that is going to require a specific commitment
H> from the OS vendor or an installed entrenched user base. Ubuntu does
H> not offer this type of commitment and does not have the user base that
H> needs it.
H>
H> Solaris: 7 years for patches, 10 years total per
H> http://www.sun.com/software/solaris/lifecycle.xml
H> AIX: 5-7 total years per
H> http://www-01.ibm.com/software/support/lifecycle/index_a_z.html
H> Novell/SUSE: 7 years for patches, 10 years total per
H> http://support.novell.com/lifecycle/
Yup, but that's *per release*. Solaris (for instance) has binary
compatibility and library compatibility all the way back to Solaris 2.0
in 1991. AIX and HPUX are similar. *very* few things ever break between
releases on professional UNIX systems. Those that do, have had a
considerable amount of pre-notice (usually at least 1 full release of
deprecation before the feature is removed). 20 years isn't much to ask.
RedHat and SLES both do over 10 years back at this point, through 3
releases each.
H>
H> May I share your clarification/our conversation with the list?
Sure.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
