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.