Choice is good …
Choice is good …
Visiting Portland, Oregon, for LinuxCon, you certainly don’t
want to miss Henry’s Tavern, well known for its 100 beers on tap.
Wait – 100 beers on tap!? That’s too much for the one evening,
you’re there, whatever your capacity is, …
You can preselect from a travel guide, but you finally end up
asking the friendly staff for advice which beer is something
special, famous, and fits best to the food you just ordered.
… too much a challenge!
And you are reminded of your daily job as a product manager.
Among the approximately 12000 packages in the openSUSE
Buildservice and and Novell’s internal build system, there are a
lot of tools and applications which do the same, or nearly the
same, thing. And it is your task as a product manager, together
with your team mates in engineering and marketing, to provide
customers with the “right” choice according to three questions:
- Business and/or Technical need
- Quality of the solution (including security analysis
- Sustainability, Supportability and Maintainability
You often take historical aspects and competitive analysis into
account as well.
Don’t get me wrong:: I do not want to talk here about the “usual
suspects” — applications or environments which have been subject
of religious war. Let’s keep vi and emacs – Gnome and KDE – perl,
python, ruby, and even REXX: they are more an expression of
lifestyle than they should be subject of choice.
Choice is necessary!
But let’s start with a topic where choice is necessary, and
where I think all people involved should open their eyes (and
ears!) even more for the view and arguments of the other side.
In SUSE Linux Enterprise 10 Novell had included AppArmor in
favor of SELinux, because we thought that AppArmor’s ease of use
would be enough, and it would quickly bring additional security to
people’s servers and desktops, in a way that was easy to manage and
While the argument was correct and remains correct, we did
ignore though, that there are security needs which go beyond the
capabilities of AppArmor, and need labeling support instead. In
return the groups (non-labeled security mechanism here, labeled
security there) started to solely look at the negative sides of
each other’s solution, the deficiencies here and the lack of
To increase the security capabilities of Linux as a general
purpose operating system, targeting everything from an embedded
box, a mobile device, a standard desktop or server, up to hosts in
the world’s largest banks and industry, we need both.
In SUSE Linux Enterprise 11, selectable at boot time, we
reintroduced SELinux as “basic enablement”: all infrastructure is
patched and compiled to work with SELinux; we do not deliver a
policy though, nor do we support it beyond special agreements with
partners and customers.
Feel free to ask.
A la carte
Enough on security. Let’s talk about more common questions, where
we will have to choose in the near or far future when it comes to
the Enterprise Linux products:
- Is CUPS enough – or is there still a need for LPRng,
specifically for those who come to enterprise Linux from classical
UNIX(R) operating systems?
- What about sendmail? Isn’t Postfix much easier to configure,
more secure, while providing the same powerful capabilities? Do
people coming from any other UNIX expect sendmail to be there? Or
is sendmail part of a lifestyle and thus sacrosanct?
- Local Filesystems: we are proud to have certified all supported
filesystems in SUSE Linux Enterprise 11 (ext3, xfs, reiserfs) with
major storage systems, and provide the best scaling choice for
storage from desktop to datacenter
(http://www.novell.com/products/server/techspecs.html?tab=3). Is it
– despite the fact SUSE Linux Enterprise has been the first
enterprise Linux shipping a journaling filesystem (reiserfs) –
acceptable or even necessary to reduce investment in reiserfs in
favour of btrfs, the new “star” on Linux’ filesystem heaven?
And there are more choices, aren’t there?
I had Portland’s local “Hair of the Dog Blue Dot Imperial IPA”,
and it goes very well with the salmon.
Part of the problem with choice, especially in commercial Linux distros, is that the choices can be mediocre products that make the rest of the distro look bad. Take SLES/SLED for example. There are so many choices that the distribution companies can’t deliver what I consider a finished product.
I have to support SLES/SLED at my clients’ sites but I am continually frustrated by the half-baked applications that still seem to be in the Beta or Alpha stage of development. I suppose I am spoiled by Mac or Windows mainstream apps that show some polish but too many Linux apps are good in concept but poor in execution.
While Novell has done an acceptable job of porting NetWare components to Linux, it just seems as though the products are just not finished. I wait for the next revision and lo and behold they still are not finished. They might have moved along slightly but I am selfish. I want:
If you cannot do a complete job with limited resources, then you need to scale back your goals so you can deliver the best product available. I may be bashing Novell here but, in reality, all of the distros have this featuritis disease. You may call it choice but choice is no good when none of your choices satisfy.
I have been a command line guy for years but I frankly don’t have the time anymore to look up and decipher poorly written man pages with no examples for everyday tasks. The applications need a standardized GUI that works, a feature set that works, they need to make my life easier, and they need to add real value to the customer.
I have gone though your article and the article is very very excellent. Thanks for sharing your opinions and useful information.
Thank you for the articles that are eye catching.