![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.
no subject
Also, have you considered trying KDE? It's amazingly pretty and functional.
Re:
no subject
FWbuilder isn't built on Gnome because it needs Gnome. It's built on Gnome because Gnome is there, and to be non-Gnome is to be non-chic. This is the problem: Applications that don't need Gnome being built on Gnome simply because the developer can't imagine a Linux application today without Gnome.
Re:
excatly so.
and, uh, as alluded, KDE is just another bloated uber-gui. some people like the taste of its pee better.
Re:
Re:
if you want SIMPLE for a nice high-level firewall language, try 'ferm', its a perl script, works great, poretty sure it will work with OBSD PF (certianly works great for linux IPtables, 30 lines of ferm rules can create a ten-chain 100+ rule iptables ruleset, that do PRECISELY what you want)
heard good things about fireflier too.
no subject
(Incidentally, it turns out my error was in telling pf that the real external interface, ppp0, was ext_if instead of tun0. I now have it at least partly working, but I'm not out of the woods yet -- ny nat rule is working, so I can originate connections from inside the firewall, but my rdr rules aren't, so I can't originate connections from outside.)
gnome and other desktop environments
As far as a gui on your gateway, what the hell are you doing installing a gui application on your gateway anyhow? Why not just install it on your main desktop box? If your main desktop box isn't the type to deal well with a modern gui then you'll need to learn how to do it manually then.
Basically, if you don't like a particular gui you don't have to use it. Complaints of "but i like this application and don't want it using this framework" can only get you one thing: "You have the source - decouple it yourself."
Now, to your point of "the main features of 'blah' are it's ability to run on obsolete hardware": It _does_ run on that obsolete hardware. You can't complain that you don't get to run the latest and greatest pretty gui on your "hey, i've got this spare computer that was output 10 years ago - how about a gateway machine" - the gui wasn't designed for that. It was designed for the desktop box. It was designed for the computers that people are buying. And it sure as hell wasn't designed for a gateway machine. Linux, for example, runs great on that gateway machine - if you install it as a gateway machine with reasonable realizations for what it's going to do.
Most of all - you have the source, if you don't like it write your own. It's what all of these people that you are complaining about have done. All of these guis were because they didn't like the features of the previous one. It didn't enable them to do what they wanted.
Re: gnome and other desktop environments
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.
Re: gnome and other desktop environments
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.
Re: gnome and other desktop environments
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?
Re: gnome and other desktop environments
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
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
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.
no subject
-Ogre
Generals and Gnats
basically, your problem is trying to be economical and re-use potentially useful ancient hardware instead of getting one of the proliferation of cheap, off-the-shelf NAT/FW boxen or a h0tr0|) |\|3\/\/ p00t4r to install your firewall on (muuuuch more expensive, but geekier).
not that i don't sympathize. i myself run a UNIX firewall on a rackmount server to keep the slavering hordes at bay. professional hazard.
ok, general philosophy aside, lemme jump in on the nits. OpenBSD? wtf are you thinking. it's trash. ask
wanna run a reasonable small-footprint BSD? FreeBSD performs the best and ipfw is prolly OK. personally, i really like ipf, so i use NetBSD. which certainly is a step up from OpenBSD, practically and morally :)
Re: Generals and Gnats
I have several strong opinions about the right way to do this stuff, but they're all rather radical departures from what we're currently doing. In particular, I think shared libraries are a waste of disk space, and applications should be distributed as stand-alone integrated modules instead of the 30,000 scattered files we currently have. (Some amount of interdependency is reasonable, but it seems like most apps these days require about 50 other libraries that are used by exactly zero or one other programs. I have like 200+ shared libs installed on my laptop, and few of them are used by any other programs than the one that installed it.)
Disk space is cheap. No, no, let me rephrase that: disk space is fucking cheap. Shared libraries were primarily invented to solve two problems, lack of disk space and memory. Neither are even remote issues today. Being able to upgrade a shared lib is nice, but in reality the APIs are changed so frequently this never seems to happen. I can think of reasons not to waste space, but shared libraries aren't really helping here.
I use my own distribution, which is based on the idea of each application being encapsulated in a single compressed filesystem. This makes upgrades trivial, as I only have to replace one file (modulo configuration file changes et al. although scripts can take care of most of that). I keep thinking I should finish it up and make it publically available, but that's really way too much like work for me to seriously contemplate doing it.
no subject
no subject
Incidentally, my pf NAT problem was *mostly* solved by changing the rules to use tun0 as the external interface instead of ppp0. I'm not completely out of the woods yet though. Allowed incoming connections are not getting redirected as they should.
Get a grip
Failing that, roll your own. Unless you've got some reason to believe that Gnome can somehow deny you that choice I don't see how you can think that Gnome could subvert Linux.
Re: Get a grip
Think about this for a moment: Can you, on any modern Linux distribution, avoid using glibc? No. Because every modern Linux distribution is built on glibc.
Now, glibc isn't a problem. It's a better C library than libc, and doesn't consume any more resources. But suppose you want to run a headless box as an application server, or perhaps a streaming-audio server.... only ALL of the applications you want to run on it require Gnome, and there are no non-Gnome alternatives any more, and Gnome requires gconf,and gconf requires X .... Gotcha. You can't have your headless box any more.
Sure, you can roll a distribution that doesn't include Gnome. But what use is it going to be if no applications will run on it? You'd be able to log into it and type ls all day, but that won't get you far. What are you gonna do if every mail client requires Gnome? Every web browser, every IRC client, every Xterm implementation? If every MTA has a Gnome configuration tool and no other way to configure it? If you can't configure DNS without Gnome? If you can't configure your resolver or reconfigure your kernel without Gnome? Can't add or remove accounts without Gnome? Can't run your compiler without a Gnome front-end?
Sure, we're not there yet. We're a long way from being in that bad shape. But I'm already seeing the diversity of desktop applications shrinking down to just two camps: applications that require Gnome, and applications that require KDE. And of the two, Gnome is winning.
ANY monoculture is bad, mm'kay?
Re: Get a grip
I don't see how we could possibly get there. If I want a headless box I'll be expecting a box without an X server, with no applications that use require graphics. Nothing that ever uses DISPLAY or has any idea what a canvas is. Things like iptables, screen, ssh, vi or emacs, lynx, ncftp, tcpdump, nmap, ...
You haven't convinced me that there is any real likelihood that any of those will ever require gnome.
If I decide to use ethereal instead of tcpdump, or fwbuilder instead of a text editor, I have to pay the price.
All you've done is show that you want one graphic application on a box that doesn't otherwise require one, and you're irritable for having to pay such a high price to get all the things that go into making a graphical environment.
Maybe we've got different ideas of what constitutes a "usable user application", but I don't see any danger at all.
I've got boxes with usable user applications that do exactly what I want, and they don't have X, gnome, KDE or any of those other graphics libraries like libpng. I don't see any reason I'll ever be required to put such libraries on a box.
I may well choose to do so (as you have done) in order to get an application I particularly want, but that's a matter of choice, not the lack of choice you predict.
Re: Get a grip
Actually, no, I chose not to complete the installation and to uninstall all those dependencies. And if you want a real-world example, I refer you to TheWW1FlyingAce, who wanted to install an audio streaming application on a headless box and found he couldn't do so without installing Gnome, ORBit, X... so he, too, scratched the idea.
No, I don't expect that iptables, screen, ssh, vi or emacs, lynx, ncftp, tcpdump, or nmap will ever require Gnome. These don't, IMHO, fall into the class of user applications. These are administration tools. But I think we're arguing at cross-purposes here because we don't agree on definitions, and doing so serves little purpose.
Re: Get a grip
I figured I'd check, to see how many copies of the Gnome and KDE libraries I'm using....
`egrep "(gnome|kde)" /proc/*/maps` turned up zero results.
I'm using fvwm because I find it has features I can't get in more popular window managers, so I know this is atypical, but I figured I'd mention it because I know it is possible to avoid Gnome if you want to.
Re: Get a grip
It is indeed still possible to avoid Gnome at present. I wasn't trying to say that it isn't. Just that: (a) the choices for doing so seem to me to be steadily shrinking, (b) far too many Gnome applications seem to be written to require the latest bleeding edge of Gnome, rather than to be usable on something resembling a stable version, and (c) the Gnome dependency tree has become insanely huge and you CANNOT install just the parts of it you're actually going to use -- it's all or nothing.
[1] I use a system meter called procmeter3 which, if started from my .fvwm2rc or from a fvwm2 menu, fails to read any system stats, but works fine if started from an xterm started from fvwm2. Meanwhile, functions in my icb and irc clients which launch any process that directly or indirectly creates a window all fail if the Perl script that starts the clients was started from an xterm, but work perfectly if the same script was started from an fvwm2 menu. I've dumped environments for both operations and gone over the two with a fine-toothed comb, and can find absolutely no differences that shed the slightest clue as to why procmeter3 works only if started from an xterm, while the icb/irc client functions work only if started from a menu. Go figure.
no subject
I tried to install gstreamer (a streaming media framework) on my server - I only want to use audio (for my MP3/OGG server project), but it turns out that gstreamer uses gconf, which requires ORBit, X, and a whole lot of other things I don't want. Damn.