Bought a used copy of an insanely hard video
game. Each screen amounts to a puzzle in the Rubik’s Cube sense,
and once you figure it out you need mad arcade reflexes to implement
the solution.
(This post was originally found at http://log.ometer.com/2004–06.html#16)
Eugenia was recently reminding me about the “dependency hell” problem
when trying to install random Linux software found on the Internet.
Joel’s
latest article points out once again that the cause of dependency
hell is dependencies. Mike Hearn points this out too
(though I’m still not convinced a new package format helps).
Here’s how you get rid of dependencies: you have one or a small number
of big monolithic chunks — the LSB defines a core one — and apps can
depend on that, and nothing else. Everything else has to be shipped
with the app itself, or be optional and detected at runtime. An app
can require “Linux,” not a huge list of files and libraries.
An implication: packaging of distribution components (things that go
with the distribution itself) and packaging of third-party apps is
fundamentally different.
A corollary is that it’s kind of nice to have as much as possible in
the distribution itself, or packaged specifically with one
distribution release in mind.
I don’t think people are facing up to the fact that there’s an
unavoidable tradeoff here. Extra copies of the same code
means bloat, difficulty of doing security and bugfix updates, lack of
consistency, and so forth. Dependencies mean dependency hell. For
each package, pick which one you want; there’s no magic technical
solution.
Some open source projects design themselves to be part of
distributions and some design themselves as third-party ISV
products. GNOME for example is clearly designed to be part of the OS,
not installed by random end users, and I consider this correct for a
desktop platform. Discussions of how to move forward in GNOME 2.8 show
this trend continuing — to make the desktop work right we have to get
increasingly entangled in distribution details such as HAL and CUPS
and so forth. The big previously-proprietary apps such as
OpenOffice.org and Mozilla have a very different attitude and tend to
assume end users will install the app themselves. Which is both true
and untrue on Linux; some will try the app themselves, and some will
get it with their distribution.
If you buy what
Joel is saying, then adding new stuff to the big monolithic core
(call it LSB, or just “Linux”) and getting third parties to use it
takes ages. This rings true for me. Very few ISVs use libraries
beyond the C library and the occasional GTK+ or Qt. I’m pretty sure
most Red Hat customers are still using Red Hat Enterprise Linux 2.1 -
which was released over two years ago, with GNOME 1.x, based on Red
Hat Linux 7.x‑era technology. (This may have changed since we’ve been
selling a lot of subscriptions lately.)
Things are tough for third-party apps; they have a lot of dynamic
adaptation to the current environment, and tend to dlopen() things
rather than include a hard dependency. This can mean implementing the
same functionality multiple times over for different Linux versions.
Apps that are part of the OS on the other hand can use new OS features
and have dependencies left and right, as soon as those dependencies
are available. These apps have a real technical advantage, but have
the disadvantage that people only get new versions when they upgrade
the OS.
You might expect from this that OS components advance more
quickly but become widespread more slowly than third-party
apps. I wonder if that’s empirically true.
(This post was originally found at http://log.ometer.com/2004–06.html#16.2)
Jono Bacon advances
one theory on why
people might switch to Linux.
(This post was originally found at http://log.ometer.com/2004–06.html#16.3)
Reminder to sign up for the first
annual Desktop Developer’s Conference, July 19–20 before OLS. A
fair number of developers will be there. We hope to have attendance
from Mozilla, OpenOffice.org, GNOME, KDE, freedesktop.org, X.org, and
every other desktop-related project you can think of. Distributions
trying to address desktop user needs are definitely
included. Bystanders with an interest in the open source desktop are
welcome as well.
From the Red Hat desktop team we’ll have myself, Owen Taylor, Chris
Aillon, Chris Blizzard, Mike Harris, Kevin Martin, and Daniel
Veillard. Wanted to have even more but GUADEC ate our budget. 😉
(This post was originally found at http://log.ometer.com/2004–06.html#15)
Colin
posted about the printing hacking he and Matthias have been
doing. These
guys are badasses.
(This post was originally found at http://log.ometer.com/2004–06.html#13)
If you compare Linux to Windows, what are the similarities and
differences? I mean this broadly, for example:
I’ll use “Windows” to mean the whole universe of our primary
competition: Windows, Active Directory, Exchange, .NET, and Microsoft
itself.
This comparison matters because we need to give people a reason to
switch to Linux. If someone asks how Linux is different, we should
have some good answers. If someone asks how Linux is the same, we
should have some good answers also.
Different means risk: the potential to be better (or worse). Different
may also create interoperability, training, and marketing
issues. Similar means safety: you ask people to decide between Linux
and Windows on other grounds.
Each project and company in the Linux world has its own answers,
implicit or explicit.
In the area of user interface for example, GNOME attempts to be
different. It does try to stay familiar in many ways (and tends to be
configurable in a more-like-Windows direction, something many vendors
take advantage of). But I think it’s clear the project has “do the
right thing on its own terms” as a goal, and feels there’s genuine
value to having the capability to understand what the right
thing is and get it implemented, something one only learns through
experience.
Companies such as Lindows, on the other hand, have Windows interface
cloning as a core premise (note the name “Lindows”). Add technologies
such as WINE and the basic retail-box-with-proprietary-license
business model, and the cloning goes well beyond interface.
Since I work at Red Hat, I can tell you the “why is Linux different
from Windows on the desktop?” answer we’ve articulated so far:
Which isn’t to say we won’t have more to say later. But this is what
we’ve said so far.
There are a lot of possible answers, some of them include:
Price: “Linux is just like Windows, but has lower licensing
costs.”
Not Microsoft: “Linux is just like Windows, but isn’t sold by
Microsoft.” If Linux is essentially the same as Windows, but offered
by another vendor, customers have more leverage.
Revolutionary Technology: “Linux has exciting innovations
not found in Windows.”
Open Standards: “Open source projects better adhere to open
standards.”
Most likely this list is as long as the list of open source desktop
projects and companies. My talk at
linux.conf.au went through some more ideas.
I obviously have some opinions about the right answer to these
questions. I don’t think we need to be better than Windows in all
respects. We need to be better than Windows in the respects that
matter.
One interesting thing about Linux is that it supports multiple
projects and companies pursuing multiple approaches, and thus as a
whole community we can try a lot of different answers to this question
and see which one sticks. While at the same time, individual groups
can tightly focus on a single approach and give it a wholehearted
effort.
A reason this is useful: the comparison between Linux and Windows
probably has to change over time. For example, while many advocate
cloning Windows today (on the level of architecture, protocols,
interface, and more), this argument is generally based on migration
path — and thus if we’re successful, the rationale for cloning
may go away. (Unless of course you subscribe to “not Microsoft” or
“having two vendor alternatives” as the fundamental differentiation
from Microsoft — in which case keeping Windows and Linux fully
substitutable may make sense indefinitely.)
Plainly a very complex issue, and I doubt anyone will be 100%
successful in predicting whether, how, and why Linux will succeed in
gaining desktop marketshare from Windows. But perhaps we could benefit
from thinking about it more explicitly from time to time.
(This post was originally found at http://log.ometer.com/2004–06.html#12)
And I forgot Chris Lee who started
in the QA group and is already breaking everything. 😉
(This post was originally found at http://log.ometer.com/2004–06.html#11)
I forgot to mention on Wednesday, Bryan Clark and Ray Strode have arrived in the
office. Fortunately, they don’t seem to have run away yet.
(This post was originally found at http://log.ometer.com/2004–06.html#11.2)
Someone wrote another TweakUI type
thing instead of whining about gconf-editor. Let’s see how hard this
was:
[hp@localhost src]$ grep ';' *.[hc] | wc -l 395
Shorter than your average flame mail. Kudos to the author of gTweakUI
for doing the work. Also check out Configurator for GNOME.
While googling for historical discussions of TweakUI I found this
nostalgia, I haven’t bothered to get involved in this argument for
a while.
On a related note, Seth’s
proposed list of user preferences, an attempt to top-down design
user prefs (there’s been a lot of organic change since the last
conscious redesign). This tries to factor in things that traditionally
require root, something we haven’t done in the past. The next step is
to map out how the list of prefs maps to user interface elements (some
may be in Nautilus for example, some in control center, or whatever).
(This post was originally found at http://log.ometer.com/2004–06.html#11.3)
Gotta love waking up to find some clueless
pundit trashing you personally. I was reading that article
thinking “well, the guy is kind of naive on what the issues and
solutions are but sure I agree with the goal” but ended up kind of
bitter when I got to the end. 😉 Especially the part where he blames
me for gnome-terminal code I didn’t even write.
A hint on Metacity performance:
[hp@localhost hp]$ metacity-theme-viewer Bluecurve Loaded theme "Bluecurve" in 0.03 seconds Drew 100 frames in 0.55 client-side seconds (5.5 milliseconds per frame) and 1.78428 seconds wall clock time including X server resources (17.8428 milliseconds per frame) [hp@localhost hp]$ metacity-theme-viewer Simple Loaded theme "Simple" in 0.01 seconds Drew 100 frames in 0.15 client-side seconds (1.5 milliseconds per frame) and 0.831834 seconds wall clock time including X server resources (8.31834 milliseconds per frame) [hp@localhost hp]$ metacity-theme-viewer Atlanta Loaded theme "Atlanta" in 0.01 seconds Drew 100 frames in 0.1 client-side seconds (1 milliseconds per frame) and 0.338352 seconds wall clock time including X server resources (3.38352 milliseconds per frame)
I added this profiling feature to metacity-theme-viewer long ago,
specifically so theme authors could get an idea how bad/good their
theme was on this dimension.
Ironically, just
yesterday I was posting about some performance issues. Volunteers
wanted. I’m sure we’ll get a patch from this OS News guy who knows
exactly where the bottlenecks are and how to provide equivalent
features in 1/10 the memory, due to his extensive profiling of GNOME,
detailed architecture review, and overall coding skills.
(This post was originally found at http://log.ometer.com/2004–06.html#10)