Profile

unixronin: Galen the technomage, from Babylon 5: Crusade (Default)
Unixronin

December 2012

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Most Popular Tags

Expand Cut Tags

No cut tags
Saturday, February 21st, 2004 02:53 pm

So I have this Sparcstation LX running OpenBSD.  We're talking seriously light OS footprint here, folks.  The complete installation took 470MB of disk.  The box is tasked as a PPP/NAT/firewall box and nothing else.  However, though PPP is working fine on it complete with working dial-on-demand, I've been having trouble getting NAT working in PF.  For sanity's sake, a friend suggested fwbuilder to generate a PF configuration just to make sure the configuration was valid.  Sure, it sounded reasonable enough, so off I went, looked at fwbuilder, decided it was worth trying, downloaded the ports tarballs for fwbuilder, and started installing.

That was almost 24 hours ago.  250MB OF DEPENDENCIES LATER, a third of the total disk space used on the machine is dependencies for fwbuilder, and it's still installing dependencies and getting started on a full Gnome install.  On a firewall box.

FUCK THIS SHIT, CHARLIE.  Not on MY firewall machine, you don't.

How did this happen?  How did we get here?  Linux, *BSD, all the other "upstart" Unices, used to be light, fast, clean environments that would run -- and run usably -- on a 386.  They grew, they gained functionality, they slowly acquired a heavier footprint.  Then the bloat started.  Enlightenment was the first symptom, and when Enlightenment was new, yeah, sure, it was pretty, but even many of its own users complained about how slow and bloated it was.

And then came Gnome.

Gnome makes Enlightenment look like a greyhound.  Gnome has fucking metastasized.  It is a cancer upon the face of *nix.  It's the tail wagging the dog.  It's bloat upon bloat upon bloat upon bloat, bottomless dependency trees, fifty libraries required for builds that used to need only two or three.  It's applications that used to be tiny and fast that are now slow, unresponsive, and eat 100MB of RAM.  It's getting to the point that anything that creates a window, no matter how trivial, requires a full Gnome install, and that Gnome install eats more disk space than all of Linux once used to.  All that functionality gets dragged in whether or not the application is ever actually going to use it, and 90% of the time, the application won't ever use 90% of it.  It's fast getting to the point where it won't be possible to compile /bin/ls without a full Gnome installation.

And it doesn't stop there.  Not only can no-one countenance the thought of developing a GUI application that isn't Gnome any more, but most of the people out there developing Gnome applications can't resist even one new useless feature offered in the very latest version of libgnosepicker-2.8.9.17.34p6, so they install every bleeding-edge Gnome library that comes out, write their applications to the bleeding edge API, and thus force everyone else to live on the bleeding edge with them.  Hello?  What happened to using stable code for applications you're going to distribute, people?

Take Galeon, for example.  Galeon started out as a fast, lightweight browser embedding Mozilla's Gecko HTML-rendering engine in a GTK+ interface, because the Galeon developers thought Mozilla's XUL interface was too slow and bloated.  Now, you can't install the latest development versions of Galeon 1.3 without a full Gnome2 installation, and not only that, but you have to build it against a copy of Mozilla compiled locally against Gnome2 with the same compiler and optimization as well, or Galeon will crash on launch.  Um, hello, excuse me, I thought Galeon was supposed to be avoiding Mozilla's bloat???  Now it's more bloated than Mozilla.

Unfortunately, if this trend continues, I foresee a time when it'll be impossible to have any usable user applications on a Linux box without having a full Gnome2 (or Gnome3, or Gnome5) installation on it.  And when that happens, Linux will have lost at least two of its key advantages over Windows -- speed, and the ability to run on old legacy hardware that won't usefully run Windows any more.  (I've heard convincing arguments that anything based on a CORBA is inherently insecure, too.)  Linux will have ceded the hardware low-end to the *BSDs, and will quite possibly have lost the initiative altogether, taken over by creeping featuritis.

I hear all kinds of Gnome apologists saying, "Well, yeah, it's bloated, but it's providing drag-and-drop, and internationalization, and an interface to the coffeemaker, and...."  The official party line is, Gnome extends Linux.  Fuck that shit.  Gnome is not extending Linux.  Gnome is subverting Linux.

Nietzche said, "Battle not with monsters, lest ye become a monster."  Gnome is Linux becoming Windows.

Saturday, February 21st, 2004 01:37 pm (UTC)
I actually have precisely one GUI application that I on the gateway machine: xcoral, my preferred editor. I run it over ssh, and it's built with nothing but Athena widgets, so it's light and fast. If I was going to use fwbuilder, I had no choice but to install it on the LX, because the LX is my only OpenBSD machine and fwbuilder doesn't include the pf plugin unless built on OpenBSD. There was nothing to indicate that it was going to be such a dependency pig, and frankly, there's no earthly reason why it needs to be. That's half my point. Half the software out there is linking in all this stuff not because it actually needs it, but just because it's there. Galeon was faster and more stable when it was a GTK+ application, before it became a Gnome one.

No-one's saying that a 386/16 with 24MB of memory should be able to run every latest whoosh-bang application. It's just that I see the paradigm of maximal feature set even for things that don't actually need it taking us towards a situation where it takes just as much hardware to useably run the GUI required to run any "current" Linux software as it does to run Windows. And that, I think, will be a bad thing.
Saturday, February 21st, 2004 03:03 pm (UTC)
I don't think you get the point. People are using these frameworks for gui applications for exactly the reason why you hate them. It allows them to build in decent functionality at a small incremental price.

As far as galeon being more stable and faster - that's entirely open to debate, but then again, this is a blog and proof isn't necessary. The gnome desktop architecture allows a base set of features to work with any application. It allows integration and it allows internationalization. Just because you don't want these things doesn't mean that other people don't. I suggest you read the freedesktop.org site about the goals of the various projects. Take a look at this article for how the various abilities of gnome and kde have allowed people around the world to use the software in their native language:

http://www.economist.com/science/tq/displaystory.cfm?story_id=2246308

Mostly I think we're just going to disagree about this - you want every application to be a minimal feature set and only work within it's own application. The people writing the software want it to be able to work with their other applications. A great example is Nat's dashboard project: http://www.nat.org/dashboard/

The idea is to make software that works together to accomplish a task and libraries often help accomplish that. Perhaps for the application in particular you could work on a CLI interface for it - perhaps using ncurses.
Saturday, February 21st, 2004 06:06 pm (UTC)
It seems to me that [livejournal.com profile] echristo is saying that the authors goals in writing
application don't happen to agree with what you are looking for. In that case,
your options are 1) put up with it, 2) choose other software that more closely
meets what you're looking for, or 3) write or derive your own. That doesn't
necessarily mean what the authors of things like gnome are doing is wrong.
It just means that perhaps you are using the wrong package, even though it does
have features that you desire.

Personally, I have a well-known aversion to GUIs and applications that
require me to move the mouse around just to enter text. I also would prefer
text configuration files versus millions of mouse clicks and drag-and-drop menus.
Configuration files allow me to make changes with much more speed and efficiency
than menu based configuration tools, and are easier to manage via script, revision
control, etc. However, I do understand that people have different goals and
not ever user has the same kind of needs that I do.

It's just that I see the paradigm of maximal feature set even for things that don't actually need it taking us towards a situation where it takes just as much hardware to useably run the GUI required to run any "current" Linux software as it does to run Windows. And that, I think, will be a bad thing.

I think this brings up an interesting point. As Linux attempts to capture more
of the mainstream market, it is going to have to address the same kind of consumer
desires that Windows attempted to do, and may therefore run into similar types
of problems. Do enough users feel that it's important enough to have applications
that can run on lightweight versions of OS and other layers to continue to spur
development of such software?
Saturday, February 21st, 2004 08:26 pm (UTC)
Mostly I think we're just going to disagree about this - you want every application to be a minimal feature set and only work within it's own application. The people writing the software want it to be able to work with their other applications.

Well, no. There are places where all of this integration is entirely appropriate. An office suite, for instance, or a browser. There are also places where most of it is highly inappropriate. My problem with it is that the latter class of tools are increasingly built with the whole kitchen sink thrown in anyway, on the assumption that since it's there, you might as well use it. This means that, increasingly, when you go looking for simple, lightweight tools to do a simple job on a small-footprint box, there aren't any. As [livejournal.com profile] emacsmood comments, there's less and less in between the "fits on a floppy" and the "requires 2GB of disk and takes 48 hours to install" levels. And yes, often this means people have to write their own small, light tools, and for those that can, that's a viable route. I write a lot of my own, but not everyone can.

To put it another way, while the benefits of Gnome in their place are inarguable, it is my opinion that the expectation of Gnome universality is suppressing diversity in complexity. There are vanishingly few simple tools being developed any more. For a close-to-home example, the Bacula GUI console, which really needs none of Gnome's features except for internationalization, is now a Gnome2 application; and it doesn't need to be one. It used to be just a GTK+ application; it was moved to being a full Gnome application purportedly to get a readymade online help engine, which it isn't using, and then that Gnome version was deprecated in favor of the Gnome2 version. This is a tool that could be perfectly well implemented using just GTK+ and i18n, and if not for internationalization, could be done with just Athena widgets.

I'm not saying that everything should be minimalist. Just that the people who want minimalist tools, but can't write their own, are being left out in the cold. The idea of software being able to work together to accomplish a task is an excellent and admirable one, when it works. At the moment, it doesn't work as well as it could, and there's several reasons for this (including, but not limited to, the issue [livejournal.com profile] emacsmood mentioned of single-use libraries and APIs which never get re-used by anything else).

When it becomes a problem, IMHO, is when integration displaces all the standalone tools and you can no longer find a tool that just does the simple job you want without having to have a gigabyte of other collaborative software to do it. This is my point, and this seems to be the core sticking issue that we disagree on.