Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
Miguel de Icaza has criticized plans for the next GNU Gnome cross-platform environment that risks damaging the Linux desktop ISV ecosystem by focusing on the Mac. De Icaza, leading the Mono and Moonlight cross-platform .NET projects at Novell, has warned a "new crop" of developers pushing plans for Gtk+ 3 risk "throwing away years of work" on Gtk+. They're also failing to recognize the value of having an ISV ecosystem working to put Gnome on Linux. Gtk+ is the tool set for building the Gnome graphical user interface, with version three the next planned major update."
Posted Jul 17, 2008 17:49 UTC (Thu)
by zooko (guest, #2589)
[Link] (4 responses)
Posted Jul 17, 2008 18:27 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Posted Jul 17, 2008 21:46 UTC (Thu)
by pr1268 (guest, #24648)
[Link]
Once again I got confused and thought that cook was the one giving Miguel de Icaza the appellation "Mono man". The LWN editors know better than to use names like that--My intuitive feeling is that most LWN readers know who Miguel de Icaza is and his relationship to the Mono Project. That being said, I think that the Register's use of "Mono Man" is awkward, but then they're targeting an audience for whom de Icaza is an unfamiliar name. It still reads funny!
Posted Jul 18, 2008 0:26 UTC (Fri)
by dark (guest, #8483)
[Link] (1 responses)
Posted Jul 18, 2008 7:19 UTC (Fri)
by Cato (guest, #7643)
[Link]
Posted Jul 17, 2008 18:15 UTC (Thu)
by drag (guest, #31333)
[Link] (10 responses)
Posted Jul 17, 2008 19:49 UTC (Thu)
by jordanb (guest, #45668)
[Link] (9 responses)
Posted Jul 17, 2008 21:33 UTC (Thu)
by rrdharan (subscriber, #41452)
[Link] (4 responses)
Posted Jul 17, 2008 22:07 UTC (Thu)
by khim (subscriber, #9252)
[Link] (3 responses)
Breaking ABIs is no big deal. The fact is: you can not. Microsoft breaks the ABI, Sun breaks the ABI - even if they spend billions trying to support it. ABIs are fragile. They break easily. The only 100% fool-proof way to keep the ABI unbroken is to use the same binary. That's what Windows is doing - and it pays for it dearly. The last sentence of cited article says it all: There are many famous examples in Win32-land where programs depend on bugs within the runtime, I claim that similar mistakes are strictly and significantly easier when source code is available. With FOSS such things are easy to create but equally easy to fix: if RPM refuses to work with GlibC 2.1 since it used some internal structures in GLibC 2.0 - it's trivial to recompile it. When some program does not work with new version of library in binary world - you are starting to add layers of emulation upon another layers of emulation. The end result is huge, unreliable, bloated mess. Like a Windows Vista. And there are no way to fix that. With source code there are at least hope...
Posted Jul 17, 2008 23:31 UTC (Thu)
by zooko (guest, #2589)
[Link] (2 responses)
Posted Jul 19, 2008 11:17 UTC (Sat)
by k8to (guest, #15413)
[Link]
Posted Jul 24, 2008 13:31 UTC (Thu)
by alex (subscriber, #1355)
[Link]
Posted Jul 17, 2008 22:02 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Jul 18, 2008 1:24 UTC (Fri)
by Richard_J_Neill (subscriber, #23093)
[Link] (1 responses)
Posted Jul 18, 2008 7:48 UTC (Fri)
by seyman (subscriber, #1172)
[Link]
Posted Jul 18, 2008 13:51 UTC (Fri)
by colinleroy (guest, #40525)
[Link]
Posted Jul 17, 2008 18:52 UTC (Thu)
by dmarti (subscriber, #11625)
[Link] (6 responses)
Posted Jul 17, 2008 18:57 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
Posted Jul 17, 2008 18:58 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link]
Posted Jul 17, 2008 21:05 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (2 responses)
Posted Jul 18, 2008 18:20 UTC (Fri)
by ovitters (guest, #27950)
[Link] (1 responses)
Posted Jul 19, 2008 18:43 UTC (Sat)
by salimma (subscriber, #34460)
[Link]
Posted Jul 17, 2008 20:09 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jul 17, 2008 20:06 UTC (Thu)
by bmur (guest, #52954)
[Link] (23 responses)
Posted Jul 17, 2008 20:13 UTC (Thu)
by dmarti (subscriber, #11625)
[Link] (14 responses)
Posted Jul 17, 2008 20:22 UTC (Thu)
by tjc (guest, #137)
[Link]
Posted Jul 17, 2008 20:34 UTC (Thu)
by bmur (guest, #52954)
[Link] (12 responses)
Posted Jul 17, 2008 20:46 UTC (Thu)
by Los__D (guest, #15263)
[Link] (10 responses)
Posted Jul 17, 2008 22:28 UTC (Thu)
by dvdeug (guest, #10998)
[Link] (6 responses)
Posted Jul 17, 2008 22:45 UTC (Thu)
by Los__D (guest, #15263)
[Link] (5 responses)
Posted Jul 18, 2008 11:15 UTC (Fri)
by whitemice (guest, #3748)
[Link] (4 responses)
Posted Jul 18, 2008 15:44 UTC (Fri)
by TxtEdMacs (guest, #5983)
[Link] (3 responses)
Posted Jul 18, 2008 20:38 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Posted Jul 18, 2008 20:39 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Posted Jul 19, 2008 14:18 UTC (Sat)
by TxtEdMacs (guest, #5983)
[Link]
Posted Jul 17, 2008 22:57 UTC (Thu)
by dwheeler (guest, #1216)
[Link] (2 responses)
Posted Jul 18, 2008 20:44 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Posted Jul 18, 2008 21:13 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Jul 18, 2008 14:24 UTC (Fri)
by anomeloris (guest, #51213)
[Link]
Posted Jul 17, 2008 20:36 UTC (Thu)
by i3839 (guest, #31386)
[Link] (7 responses)
Posted Jul 17, 2008 21:13 UTC (Thu)
by hingo (guest, #14792)
[Link] (2 responses)
Posted Jul 17, 2008 22:55 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jul 18, 2008 10:30 UTC (Fri)
by modernjazz (guest, #4185)
[Link]
Posted Jul 18, 2008 14:55 UTC (Fri)
by Holmes1869 (guest, #42043)
[Link] (3 responses)
Posted Jul 18, 2008 15:12 UTC (Fri)
by halla (subscriber, #14185)
[Link] (1 responses)
Posted Jul 19, 2008 16:54 UTC (Sat)
by i3839 (guest, #31386)
[Link]
Posted Jul 18, 2008 9:10 UTC (Fri)
by sylware (guest, #35259)
[Link] (12 responses)
Posted Jul 18, 2008 11:30 UTC (Fri)
by whitemice (guest, #3748)
[Link] (11 responses)
Posted Jul 18, 2008 13:39 UTC (Fri)
by tetromino (guest, #33846)
[Link] (1 responses)
Posted Jul 18, 2008 14:11 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Jul 18, 2008 16:01 UTC (Fri)
by TxtEdMacs (guest, #5983)
[Link] (5 responses)
Posted Jul 18, 2008 17:29 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Jul 19, 2008 10:56 UTC (Sat)
by TRS-80 (guest, #1804)
[Link]
Posted Jul 19, 2008 14:27 UTC (Sat)
by TxtEdMacs (guest, #5983)
[Link]
Posted Jul 18, 2008 18:23 UTC (Fri)
by ovitters (guest, #27950)
[Link] (1 responses)
Posted Jul 19, 2008 14:25 UTC (Sat)
by TxtEdMacs (guest, #5983)
[Link]
Posted Jul 18, 2008 17:26 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Jul 20, 2008 10:58 UTC (Sun)
by man_ls (guest, #15091)
[Link] (1 responses)
Posted Jul 20, 2008 19:51 UTC (Sun)
by salimma (subscriber, #34460)
[Link]
unclear formatting?
Once again I got confused and thought that cook was the one giving Miguel de Icaza the
appellation "Mono man". I thought that was kind of a weird way to name him in the headline,
inconsistent with LWN.net's normal editing standards. Later I noticed "(the Register)" at the
end of the headline and realized that this was The Register's voice, and is totally consistent
with their editing standards.
I know that I've mentioned this before, but I'm posting it again because I think other people
might be similarly confused. Perhaps LWN.net could reconsider some minor formatting change
such as putting headlines copied from other sites into italics or quotation marks.
Thanks for listening,
Zooko
Mono man
I thought it might refer to Steve Ballmer.
unclear formatting?
unclear formatting?
I've also often had double-takes like that. I think the key change would
be to put the source at the start of the title, instead of at the end.
unclear formatting?
I agree. Also, putting a quoted title in double quotes would be a clear way of indicating
it's a direct quote (hint: quote marks are useful for this...)
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
As far as I am concerned breaking API/ABI is to be avoided like the plague unless it's very
necessary.
With the Linux-kernel it's not designed to have any sort of internal dependencies or anything
like that.. it's a monolythic release each time. So a internal stable ABI/API is silly.
With Gnome were you have it trying to be a dependency for a large number of separate
products/projects, then a stable and solid API/ABI is critical...
I have very little desire to run into issues were I am unable to run or compile a Gnome-based
program because the author didn't happen to spend weeks updating the source code to match the
latest version of Gnome in the past year or so.
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
Breaking ABIs is no big deal. It's just a recompile. I agree that breaking APIs can be a
problem, but the guy's argument is to consider breaking them once every *five years*, and
doing so with a major version rev. The move from gtk+1 to gtk+2 wasn't particularly painful.
Gtk+2 came out and everyone had many years to upgrade while the distros continued to maintain
gtk+1 in their repos. The only projects that didn't make it were the ones who had long before
died for other reasons (like xmms).
Miguel seems most worried about proprietary software vendors *wipes tear from eye* and that
they're considering taking out code that was *really hard* for him to write back in the good
'ole days. The Mac stuff is a complete ad hominem too. I don't like the trend towards mac
usage, but Miguel doesn't offer any credible link between the proposal for a gtk+3 and the
fact that the developer was using a mac laptop.
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
> Breaking ABIs is no big deal. It's just a recompile.
You're wrong.
http://linuxhaters.blogspot.com/2008/07/feel-source.html
He's right
He's right
I'm curious about your claim that Sun breaks the ABI. I've often heard pro-Solaris folks make
comments like "Programs written for Solaris 2.5 thirteen years ago still work on Solaris 10
today and will continue to work on future versions of Solaris.".
But I don't see any sort of measurement or documentation of this on the web. Do you know of
some examples of Solaris ABI breakage?
Thanks.
Speaking of solaris 2.5
Solaris 2.5.1 changed an environment variable export put out by the x library implementation
that provided a path to where various X resources were located. Prior to 2.5, this
environment variable existed. With 2.5.1, the variable was removed.
There were probably (other) portable ways to locate the resources, but Sun maintained that it
was not an interface change. Basically, to them, ABI meant only the entry points.
So it all depends on how literally you want to treat things. My experience is that they not
only break the interface, but they obtusely pretend they have not done so. Others may have
had better experiences. I haven't played with Solaris for a while.
Only if you payed attention to the ABI rules
There are plenty of old Solaris applications out there that didn't follow the official library
ABI, and they will break when running on Solaris 10.
It's interesting the way Sun keep ABI compatibility. Basically nothing in the kernel is
guaranteed, all access to the kernel goes through the stable SUN/POSIX ABI in the libraries.
If applications follow the library ABI then all is good. This also allows Sun to tweak their
kernel layer and then apply fix-ups in the library.
It's in stark contrast to the Linux approach which has shifting internal kernel API's and
library API's but a solid syscall ABI. If you dig up statically linked a.out file from years
ago it will run fine on a modern 2.6 kernel.
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
> The move from gtk+1 to gtk+2 wasn't particularly painful.
Sure it was. We lost Dillo, qiv, xmms, and a few other excellent utilities. I'm sure we lost
a number of good developers too.
Did you write much code against GTK+-1.0? If you had, maybe your memory of the pain would be
a bit more acute?
The 1.0->2.0 API breakage was well planned and quantified in real code. It was painful but it
was worth it. Today, since no GTK-3.0 code exists, all this "break the API" discussion is
pure speculation. And breaking the API merely to remove some deprecated interfaces? You
gotta be kidding me!
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
> Sure it was. We lost Dillo, qiv, xmms, and a few other excellent
> utilities.
I'm still using all 3 of these! I'm not sure "lost" is the right word - in that they haven't
actually stopped working.
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
> I'm not sure "lost" is the right word
I think Bronson means "lost" in the sense that development of those apps stopped once gtk+1's
did but even then, I'm not sure he's right. We "lost" xmms a long time before we moved from
gtk+1 to gtk+2.
The move from gtk+1 to gtk+2 wasn't particularly painful.
Gtk+2 came out and everyone had many years to upgrade
Mono man accuses Mac Gtk+ fans of jeopardizing Linux desktop (the Register)
Were you developing a GTK+ software at the time? If it took many years to upgrade, it was because developers were busy rewriting working code to switch to GTK+2, because it was clear that GTK+1 was going abandoned.
Breaking APIs and removing deprecated stuff for the sake of the embedded developers (the ones that do sponsor GTK+ development these days) is going to be just more of the same for developers of software that already has a lot of code, including deprecated code.
I'm not particularly fond of rewriting whole parts of my apps every few years just because a new widget is the new hotness and the one that existed when I coded my stuff is now deemed crappy and unmaintained.
The Mainstream Media seems a little confused here. Miguel's version has the details?
Source
There's often entertaining to read, and very snarky, but their take on things is usually rather skewed compared to the mainstream trade press's take.
The Register is hardly mainstream
s/There's/They are/, not sure how I messed that one up.
The Register is hardly mainstream
The Register is hardly mainstream
Indeed; more GTK+/GNOME developers are concerned over Mono dependencies creeping in
(ndesk-dbus and gnome-keyring-sharp are *replacements* for the C/GObject-based dbus and
gnome-keyring), rather than their platform going cross-platform.
Given that the alternative, Qt, works much better on OS X than GTK+ does right now, having a
more widespread use of GTK+ on Mac is a win-win proposition: more applications get written in
it, and they benefit from more open competition (some Mac applications, even limiting the
scope to open-sourced ones, are better than their Un*x counterparts, for instance, BibDesk)
The Register is hardly mainstream
That is a dependency for Mono apps, not for C (non-Mono) apps. So it is *not* a replacement as
you seem to suggest.
As to the:
> Indeed; more GTK+/GNOME developers are concerned over
> Mono dependencies creeping in [..] rather than their
> platform going cross-platform.
I saw no such concern.
The Register is hardly mainstream
Incorrect: ndesk-dbus, just like the C counterpart, are both meant to be used solely over
D-BUS, regardless of programming language:
http://www.ndesk.org/DBusSharp
There are proposals for it to completely replace the C version, though I hope it does not come
to that, because the licensing is more flexible (MIT vs GPL).
Of course, since using D-BUS does not mean linking against the D-BUS bridge, the licensing
concerns are probably exaggerated to begin with.
Source
That's much more sane.
The Register got pretty much everything ridiculously wrong, ignored every
substantive point Miguel made, and manufactured a conspiracy theorist out
of whole cloth. I'd like to say I'm shocked but the lie would be too
brazen even for me...
Priceless
Back when GNOME made the decision to put the ok/cancel buttons backwards on all of the windows
it was clear the downward spiral had begun. Out of all of their UI foibles, this still stands
out as the most frustrating and demonstrative that the mac fanboys are in control.
OK/Cancel is bogus. GNOME got this right before Apple and Microsoft did, so point to GNOME for that.
"use verbs"
"use verbs"
AFAIK MSFT is still OK/Cancel. But I guess I wouldn't know for sure, since I don't use
Windows very much.
I'm no MSFT fan, but I think they got that one right. We tend to state the affirmative first:
yes/no, up and down, right or wrong. Cancel/OK is backwards. It's like no/yes, down and up,
wrong or right.
I owned a Mac for 5 months and sold it, mainly out of frustration with things like this. It
would be OK if you could change these things, but you can't -- the Steveness(TM) is hard-wired
into OS X. I tried to learn to think backwards, but I in the end I decided that it wasn't
worth the trouble.
"use verbs"
The words on the buttons are not what I'm complaining about. By far, the de facto standard is
having the affirmative response on the left (Ok) followed by the negative response (cancel).
It's a reasonable positioning based upon english language usage. GNOME gets this backwards and
absolutely destroys usability by doing so.
The mac guys will point out UI studies done by people who have never seen a computer before.
As someone who has been doing this for 15 years, their study means squat to me. By having
ok/cancel backwards, it breaks deeply ingrained fundamental habits...and that is a major sin.
"use verbs"
So we should be kept by yesterdays mistakes in all aspects of user interfaces because they're
"de facto standards"? oO
Cancel/OK is perfect.
"use verbs"
So we can toss out all clunky expensive translations in favor of Esperanto? Seriously,
translation is a huge cost in software development; why not toss out all those defacto
standards?
Every single time you throw away a defacto standard, there's a cost and hopefully a benefit to
it, and you can't go changing things to be slightly better if they're going to frustrate your
users.
"use verbs"
Unfortunately, I have to change between Linux and Windows several times every day, but I have
yet to be frustrated over button order...
"use verbs"
Agree, if someone is that disturbed by OK/Cancel / Cancel/Ok button order then they need to
consume WAY less caffeine. As long as it is consistent, pick an order, I really can't manage
to care.
Breaking APIs to implement phantom features... that I care about.
"use verbs"
I wonder if something very obvious is being missed in this thread. That is, if you are using
the GUI and are right handed mouse user, Cancel/OK order makes prefect sense. It is easier.
This exhibits a common bias I encountered quite a time ago when I was in a highschool ROTC
program. While right handed I am partially ambidextrous and I shoot left handed with a rifle
or a hand gun. When an external adult, visitor seeing my preference* advised me to do things
right handed I began to doubt the mental acuity of those with <i>rank</i>. It was a factor
that played a role in my turning away from my dream of a military career.
* My marksmanship is better left handed than right.
"use verbs"
Are you left-eyed?
I'm right-handed, but shoot left handed. It's not that my vision is better left-handed, it's
that I can't even see the target if I try to shoot right-handed.
Apparently, about 15% of people have each of a left -eye, -foot or -hand dominance. And
there's no link between them. I'm right-handed, right-footed and right-eyed. My grandson is
probably going to be pretty unusual - he appears to be left-footed, and and will quite likely
be left-handed as that trait is often inherited maternally - his mum is left-handed.
Oh - and as to the military - I remember asking the recruiting people years ago "what happens
if you *CAN'T* shoot right-handed?". Not then, but they said not that long before they would
have forced you to shoot right-handed. I had to work hard to get them to realise I said
"can't", not "won't".
(And they said that sort of person would probably have ended up in the cookhouse or similar.
Indeed, they might again now, because I think one of the main British Army guns can only be
used right-handed - it ejects spent cartridges back and to the right, over the shoulder of a
right-handed user but straight into the face of a left-hander.)
Cheers,
Wol
"use verbs"
Whoops - I meant to say I'm left-eyed.
Cheers,
Wol
"use verbs"
Sorry for the delayed response.
Yes it's partially an eyesight issue but not as extreme as lacking vision in the right eye. I
think it is brain related. Regarding weapons being by design right handed, I cannot remember
what weapon, but one put some ejected shells into my chest pocket. I cannot comment on the
footedness, just have not noticed, I guess I am just oblivious. Nonetheless, it might be a
factor in my being such a poor dancer.
Yes. Keep the mistakes.
> So we should be kept by yesterdays mistakes in all aspects of user interfaces because
they're "de facto standards"? oO
In short: YES, usually.
An interface is "user-friendly" if it's easy to a user, which is PRIMARILY a function of what
experience they already have. E.G., the QWERTY keyboard is a stupid arrangement of keys. But
because English users are familiar with it, rearrangements (Dvorak) are NOT user-friendly to
most users.
This is particular an issue for stuff involving muscle memory. If someone has been trained in
one interface to do something, then you want YOUR interface to do the same thing.
Yes. Keep the mistakes.
But CONSISTENCY is more important than FAMILIARITY.
Give a trained typist a Dvorak keyboard, and within a week or so they will be faster than they
were before. Make them keep switching between keyboards, and they will be slower whichever
keyboard they're using.
Far too many problems are blamed as "user error" when the user's muscle memory presses/clicks
the wrong button because in all the other stuff they use it would have been the right button.
Cheers,
Wol
Yes. Keep the mistakes.
Not always true. I have two different Maltron keyboards (at home and at
work) with significantly different layouts for the non-alphanumeric keys.
It took about two weeks' adapting time, but I can shift from one to the
other almost instantly now. There *are* muscle memory errors, but only
when, say, I'm working from home, editing a program I normally edit at
work, and I start using work's key layout...
"use verbs"
imo Cancel/OK resembles Previous/Next so it makes sense while OK/Cancel doesn't.
Priceless
The order should be random so that users never know where to click and need to consciously
decide before clicking.
If that causes very frustrated users to strangle you then you shouldn't ask those silly
questions in the first place...
Heh, I believe this is the most constructive proposal I've ever seen wrt the Gnome reversed Ok/cancel buttons! I'm pretty sure this would perfection the effect they were looking for with their HIG :-)
Priceless
While we're about it, let's change the standard GNOME editor to the
immortal gnxt.
Priceless
Priceless
Just the editor I've been looking for all these years! Thanks for
sharing.
Priceless
Hahaha that's an excellent idea!
At the risk of sounding like a total keyboard snob...why does anyone on LWN even care about
OK/Cancel vs. Cancel/OK? I understand it might suck for our family members or our co-workers,
but don't we all just use Alt+o and Alt+c?
GUIs are great, but too much use of the mouse is not. Be the snob. Be the snob. Be. The.
Snob.
Priceless
Surely you mean escape and enter?
Priceless
Personally I don't care about OK/Cancel as I can't remember the last time I encounted it.
That said, if people try to be smart and use keyboard shortcuts snob mode will be enabled and
a new popup will be displayed, again in random order, but with an additional option named
"Maybe".
M[io][cn][ro]... man
Hum... if he could drop its baby bloats (mono and such...) and work on getting the fat out of
GTK... that would be quite better...
M[io][cn][ro]... man
Gtk doesn't depend on Mono (and several tests have shown that Mono is pretty memory
efficient, even if it did).
And where is the fat in Gtk? libgtk-x11 is a scant 3.7Mb and has a pretty tiny list of
dependencies (X11, ATK, Glib, Pango, libpng, & freetype), all of which are entirely
reasonable.
This bloat argument people trot out against OOo, GNOME, KDE, etc... needs to be put down once
and for all. None of the aforementioned products have much bloat at all - bloat is being
unreasonably big and burdened by dependencies given the task at hand. The task at hand is
HUGE! People want a nice desktop where printing *just works*, and the bits talk to one
another (thus you have to have an IPC mechanism), devices hotplug and magically appear, rich
media like images can be cut-n-pasted, etc... That is allot of work and therefore allot of
code. Features have a price and I (and no other reasonable) user is willing to give up any
of the aforementioned because they save time (the truly scarce resource). GNOME is pretty
darn lite, not perfect, but not bloated in comparison to what it does. It is extremely
modular, you can remove bits if you are masochistic enough to want to. Most of the bloat
arguments come from people who look at "top" and don't understand the UNIX memory model (RSS
!= memory consumed; it is actually really complicated). And most people who think running a
"lite" desktop saves them anything significant are kidding themselves - as soon as they fire
up a usable app all the plumbing behind it fires up dynamically anyway - you might get better
performance (at least application start time) by just running the real thing.
M[io][cn][ro]... man
> libgtk-x11 is a scant 3.7Mb and has a pretty tiny list of dependencies (X11, ATK, Glib,
Pango, libpng, & freetype), all of which are entirely reasonable.
The libX11 dependency is not reasonable. A modern toolkit should only depend on xcb.
Unfortunately, apparently switching to xcb will break API since someone had the *awesome* idea
of using xlib types in a gdk public header...
M[io][cn][ro]... man
That only means they need to depend on the xlib headers, not the library.
They could use xcb and convert themselves.. but the whole of <gdk/gdkx.h>
does seem to be rather wired into the Xlib world, yes. It's not just the
types, it's what the functions *do*.
M[io][cn][ro]... man
From your knowledge of the internal workings of Gnome, I assume you are one of the team of
developers, if not a core member. Could I make a suggestion on making Gnome lighter than it
appears to many? If you are amenable, change the design where some components that go unused
are not forced upon those that prefer the Gnome desktop.
My suggestions would begin with making the Gnome browser an option. I know others have asked
how to remove it (many of us prefer other browsers) to be told it is impossible. My second
suggestion applies to the built-in Gnome eMailer. It used to be a much larger pain than I
find it presently when it would appear when my default was Thunderbird. Again for the many
that use other email clients, why is it necessary?
I know that this may not be a practical under this version, but since you are preparing for a
major break why cannot Gnome really become more modular than it is at present?
M[io][cn][ro]... man
The 'Gnome browser'? Epiphany is optional, Nautilus and Metacity aren't,
but only because you can't build gnome-control-center without their
headers: I think you can install it without them (though a couple of
metacity/nautilus-related capplets might fail).
Metacity is mostly optional - it's only responsible for a few keyboard shortcuts (Alt-F1, Alt-F2). Nautilus is becoming more essential - features are being moved from gnome-volume-manager into it.
GNOME components
M[io][cn][ro]... man
Actually other than when the Gnome email insisted on appearing uninvited I really have no real
complaints with Gnome.
M[io][cn][ro]... man
I don't get what you mean. I don't use Epiphany, nor Evolution. That is perfectly possible.
Further, a lot of distributions use Compiz instead of Metacity, so... where do you see that
these are required?
M[io][cn][ro]... man
As I mentioned, the problem with the email no longer occurs, it might be due to the
distribution I use. However, previously when attempting to use an email link, the Gnome
application used to insert itself. Now Thunderbird works, ignoring Gnome (which is my
preference).
The other comments were just musing that for some, the absence of some applications would not
be missed.
M[io][cn][ro]... man
I'm not sure I'd describe OOo as being non-bloated. Last I saw it
epitomised the reinvent-the-wheel approach, implementing its own widget
set, its own object model, its own bloody everything (although at least
ooo-build lets you coerce it into using an external copy of
fontconfig/Xft/freetype). I was surprised it didn't come with its own
video drivers.
M[io][cn][ro]... man
Most of the bloat
arguments come from people who look at "top" and don't understand the UNIX memory model [...].
That is demonstrably not true. I have run several machines with very low RAM (<256 MB) and running XFCE4 saves a lot of resources, even when using complex applications like Firefox. Not only according to top or free, but seeing how much swap it requires and how usable the thing is. With XFCE4 it is actually snappy most of the time. With GNOME every click is a torture.
It is extremely
modular, you can remove bits if you are masochistic enough to want to.
I have found I can live without the features you mention (IPC, desktop printing, desktop hotplug, rich copy paste). I cannot however run GNOME on my EEE. Since I cannot actually leave those bits out, it is not "extremely" modular. It is "masochistically" modular, which means that developers don't think users should leave those bits out and don't provide the means to do so.
M[io][cn][ro]... man
Indeed; converting from GNOME to XFCE would yield memory saving for most users: the average
GNOME user probably runs several non-GTK+/GNOME applications: Firefox, Thunderbird, and OOo.
Thunderbird consumes the same amount of RAM within or without GNOME; Firefox consumes less
because the GNOME integration won't be loaded.
You'll be saacrificing the convenience of several GNOME tools -- keyboard management (layout
manager, multimedia keyboards, and shortcut handling are very nicely executed in GNOME), but
power users with tight memory budgets would find XFCe just fine.
I'm a bit concerned about the seeming lack of activity on their web pages and developer blogs,
though...