Name Your Favorite Bloat-Free Software

An anonymous reader writes "I prefer software that takes as little hard drive space and RAM as possible. I can't stand bloated software like iTunes, as compared to Foobar or classic Winamp; or Windows Media Player, as compared to VLC or Media Player Classic. What are some of your favorite applications which are a little less bloated?"

Oh!

Now that one's easy! `ed`. It's the standard editor [gnu.org] for a reason, after all.

Re:Oh!

ed is a bloated mess! It's 47K for god's sake! I use cat for all of my text editing needs. At a lean 19k, it's far more efficient than ed. Hell, if you're comfortable with that much bloat, you might as well just use emacs. At least then you get an operating system included.

As for general favorite bloat-free software, I'd have to go with /usr/bin/yes. Often I find myself needing something to tell me I'm correct about a tough decision, or to provide me motivation to do something, or just for some general personal validation. For that and more, I trust yes. Sure, some people would use more unsure methods such as researching problems, talking to themselves in a mirror, or taking action to better themselves. I'm not much of a gambler though, and I don't like to sweat. So, I use yes. Yes always gives me the answer I need, as many times as I need to hear it. Yes is the perfect solution to life's problems. Take for example the following conversation with yes:

Should I buy that new sports car I've had my eye on? y
Am I really a good person, even after all those felonies? y
Should I have another beer? y
Am I sober enough to drive? y
Do you love me? y
Oh yes, you little scamp, I love you too! y
y
y
y
y
y
y
y
y
^C

Re:Oh!

I don't know, EMACS stands for 8 megs and constantly swapping. Eight Freaking Megs!!!! No editor should be that large. I mean my god what does it do? Check email?

Re:Oh!

8 megs for an operating system is pretty small...

Re:Oh!

That's huge! Nobody should ever need more than 640k.

Re:Oh!

While I agree that Notepad is a powerful editor, I feel that Wordpad's ability to underline text on the same line edges it out for the extreme programmer. Plus, you can write your release notes in Wingdings.

Re:Oh!

A great way to DoS a server remotely!

doubt it. ever heard of ulimit? any self-respecting unix admin worth salt would limit resources to unprivileged users/applications on their production servers.

Re:Oh!

Pity Homer Simpson [wikipedia.org] didn't know about yes.

Re:Oh!

There are security updates to cat?

Re:Oh!

I use cat for all of my text editing needs.

Freakin' wastrel! That's why they made ">". Not vim. Not ed. Not cat. ">".

$ > eln.txt
Hi, I like swap!
^D

"cat". Hrmph.

Re:Oh!

Pfft. I'm waiting for Apple to release iYes. Who cares that yes is tiny and does its job well? It still needs to be simplified as only Apple can. Hopefully they can add some magic playlists in there as well, and maybe throw in a little DRM for good measure.

My machine is quad core and has 1.5TB of disk and 4GB of RAM so I think it can be safely assumed that everyone else does too...and that every application should assume it can have all of it. I mean, it's time to take these command-line utils into the modern age.

I'm also looking for the iTrue replacement for /bin/true, as it desperately needs a GUI. And by God the fucker better be set to load into memory at start-up because I don't want to have to wait for truth.

Re:Oh!

You might be interested in this [muppetlabs.com]

Re:Oh!

I prefer software that takes as little hard drive space and RAM as possible

I'll have to go out on a limb and say I dropped expectations of absolutely minimal HD and RAM space for EVERY app I use, after continually coming up against programs that would go all out in being light in resource use, but couldn't do their job because of it.

Some are just what the original poster ordered - vim is certainly one of the good cases, it's powerful and manages a light footprint, and there are plenty of other tools that do phenomenal work whether it's running on eight xeons, or a single low-end 386.

One of the opposite cases is some forms of image work when comparing apps like Gimp and Photoshop. In some areas, Gimp is WAY lighter on resource use. I'd perform work on 250MB image, and gimp would use little more RAM than that, no matter how it was configured for RAM use. This would normally be seen as a really good thing for Gimp.

What of Photoshop? It wanted 2GB of RAM to work at maximum speed. That might sound like serious bloat on photoshop's part, but when working on large images it meant two orders of magnitude difference in speed. Yes, where Gimp will use a mere 280MB on a 4GB system, and take 15-16 minutes to perform one filter over an image, Photoshop would chew through 2GB and take about 20 seconds doing the exact same thing.

(That doesn't mean PS was incapable when stuck with ONLY 256MB RAM. Then it'd bog down just like Gimp)

What I want are apps that use the resources I provide them *wisely*. There's more to that than just being totally frugal. Seen too many people running big-RAM systems and being proud of having their OS use just a hundred or two MB out of gigs. Why? Resources are free once they're installed, may as well use them when they genuinely can help you work.

GIMP tile cache size

Using GIMP, did you ever look at the setting called "Tile cache size" in Preferences / Environment? This sets the maximum amount of RAM that GIMP can use before it starts to swap some parts of images (tiles) to disk.

You can set this value to 4 GB and GIMP will happily use as much memory as you have. And it will be much, much faster when working with large images. As a rule of thumb, you should set this value to around 80% of your available memory.

Re:GIMP tile cache size

Is there a compelling reason that the default behavior is not 80% of your available memory?

Re:GIMP tile cache size

Is there a compelling reason that the default behavior is not 80% of your available memory?

There are several reasons, some of which are historical:

• GIMP was designed 10 years ago for UNIX systems. Many of these systems were shared by multiple users from remote displays. On a multi-user system, you do not want any application to consume 80% of the memory shared by all users.
• It is very difficult to have a portable way to know (or even guess) the amount of memory available on a machine. You need different bits of code for each operating system, and sometimes you even have to run external commands and parse their output because a non-privileged application is not allowed to get this information from the system.
• What is "available memory" anyway? It this your total amount of RAM, the amount of RAM still unused after you boot your OS, or what is left after you start your browser and some other applications? In many cases, only the user knows in which context GIMP will be used.
• Nobody bothered implementing good heuristics for setting the tile cache size automatically. I am sure that a patch improving the default behavior would be gladly accepted.

Re:GIMP tile cache size

GIMP was designed 10 years ago for UNIX systems. Many of these systems were shared by multiple users from remote displays. On a multi-user system, you do not want any application to consume 80% of the memory shared by all users.

It is no longer 10 years ago. There are valid reasons to preserve 10-year-old design decisions, but not to preserve 10-year-old default settings! The number of people wanting to install GIMP on single-user desktops is vastly greater than the number installing it on multi-user servers; it is silly to expect the majority to reconfigure a setting chosen for the benefit of a minority.

It is very difficult to have a portable way to know (or even guess) the amount of memory available on a machine. You need different bits of code for each operating system, and sometimes you even have to run external commands and parse their output because a non-privileged application is not allowed to get this information from the system.

There are lots of things it's difficult to do on some platforms. That's no excuse for not doing it in cases where it's easy. Even just implementing this for Linux and Windows would solve the problem for the vast majority of GIMP users, and put a framework in place for users of more obscure operating systems to contribute solutions for their platform.

What is "available memory" anyway? It this your total amount of RAM, the amount of RAM still unused after you boot your OS, or what is left after you start your browser and some other applications? In many cases, only the user knows in which context GIMP will be used.

Now you're getting silly. Anyone with an ounce of common sense will assume that "available memory" is the amount of memory that is available, not your total amount of RAM. In other words, the amount of memory that is not being used by any other programs at the time that you start GIMP.

Nobody bothered implementing good heuristics for setting the tile cache size automatically.

Laziness is no excuse for making a program that appears, to new users, to perform much worse than it really does. Plus, I thought the whole point of this thread was that a good optimum setting (80% of available memory) is known, and the program merely stupidly defaults to a much smaller setting?

I am sure that a patch improving the default behavior would be gladly accepted.

I envy your optimism. Given the GIMP team's less than admirable record at accepting any attempt to improve their program (i.e. they think it's perfect already, and anyone who dares suggest an improvement is flamed to death), I sadly am unable to share it.

No, they would merely reject any patches on one of the spurious grounds you have noted above: that the submitter had not fixed the problem on Irix (so they would refuse to fix it for 99% of users), or the patch would make things worse on multi-user systems (so they would refuse to fix it for 80% of users), or the submitter had not proven beyond a shadow of doubt that he had found a completely optimal strategy (so they would refuse to make it considerably better). Let's be honest - the GIMP developers do not care about end users, they only care about massaging their own egos and pretending that GIMP is a serious competitor to Photoshop.

Re:Oh!

When I'm using Windows, here's my selection:

Utilities:
7-Zip (Compression/Decompression)
Editpad (Tabbed Notepad replacement)
SequoiaView (Creates square treemaps of file system)

Multimedia:
VLC (Plays Anything)
Exact Audio Copy (Perfect CD Ripping)
LAME (High Quality MP3 Compression)
Audacity (Record off Line Inputs or Loopback)

Internet:
uTorrent (Bittorrent)
Firefox with FireFTP (Browswer, FTP)
Thunderbird with WebMail (Email Client)
TortiseSVN (Windows Shell Integration for Subversion)
Putty (Telnet/SSH)

Games:
OpenArena (Open source extension of Quake 3 codebase)
Battle of Wesnoth (Open source strategic fantasy game)

Re:Oh!

Other nice un-bloated Windows utilities I'll add:

V, the file viewer [fileviewer.com]
Foxit Reader [foxitsoftware.com] for viewing PDFs
Crimson Editor [crimsoneditor.com] for text files, though I more often use emacs.

Re:Oh!

Instead of utilities, I'll list some media production apps:

Steinberg Wavelab (audio editor)
Reaper (DAW)
DVDFab Platinum

I'm not a programmer, so I can't testify to the efficiency of the code or anything, but I use every single one of the features of the above programs. By that measure, it makes them the opposite of bloatware.

Here's one that I just downloaded today, after being prompted by an earlier Slashdot article:

Opera 9.5 (I've been using it for less than an hour and it's already my favorite browser). Maybe there's some bloat somewhere in Opera. Maybe there are some of you fiber-eaters who believe that being able to render javascript automatically makes it bloatware. But this bitch is FAST and it seemed to install in the time it took me to click the FINISH button.

And finally, my favorite, slick tool for breaching the walls of the Corrupt Castle of the Copyright Cabal...uTorrent! It's more than just a torrent download manager, it's a weapon for fighting fascism!

Re:Oh!

Not bloatware?? Huh? News to me...

Firefox, Thunderbird, TortiseSVN are anything but Bloat-Free.

In the past six months to a year FireFox, Thunderbird regularly take up 130 MB by themselves. I once had Thunderbird manage RSS feeds.... That was a mistake! And don't even ask me about how SLOW Firefox has gotten with larger HTML pages.

TortiseSVN has this annoying habit that it has to cache everything and if you have any SVN projects of any size it takes ages to do anything.

What annoys me about these applications is that they take the attitude, "oh lets just load it into RAM after all everybody has enough." I get annoyed because I run Virtual Machines and these apps keep slowing everything down.

Re:Oh!

Yes, where Gimp will use a mere 280MB on a 4GB system, and take 15-16 minutes to perform one filter over an image, Photoshop would chew through 2GB and take about 20 seconds doing the exact same thing.


The simple point you're making: Hardware is for us to USE, not "NOT USE". Sure, we don't want our applications to be completely wasteful. But if software developers can focus more on useful features and code with less bugs, I'd rather they do that than save a few megs of RAM.

Re:Oh!

What's the joke ?

I use ed at least once a week, if not more.

Re:Oh!

How and why would you use more instead of ed??

Re:Oh!

Obviously when he wants to just read the document and not edit it. More or less gets the job done.

Lynx?

Lynx [wikipedia.org], anyone? :)

Re:Lynx?

Who needs the bloat of Lynx when you can telnet to port 80?
 

Re:Lynx?

What's really fun is reading your email by telnetting to port 110.

I actually used to do this a lot when I was working for a certain ISP that had very flaky homebrew mail software. Mailboxes were getting corrupted all the time. The only way to fix them was to telnet in and fiddle. Or just copy /dev/null over the mailbox file, though customers tended to frown on that for some reason.

Re:Lynx?

Ever tried it with Slashdot? The *light* version of the front page is 600k!

The only alternative is the mobile interface, which is horribly crippled (top five comments only? the only good thing about slashdot is the comments!).

The content on Slashdot *should* be ideal for reading on the way to work on my mobile - content that can be laid out easily in a linear fashion, lots of content on a single page so I can keep on reading through blackspots, no pictures - but the way it's laid out makes it way too annoying (and this is with an unlimited 3G data plan).

Re:Lynx?

the only good thing about slashdot is the comments!

You must be new here.

Re:Lynx?

We all know Slashdot isn't for reading TFAs.....so if it isn't the comments and it isn't the articles, then it must be because of CowboyNeal.

Layne

Re:Perl

I know you laugh but hear me out. Pick up the O-reily quick reference for almost any major language.

Is that a *really* good metric for a language? O'reilly is pretty good as companies go, but they are still after the bottom line. And the bottom line is: bigger "quick references" will sell better and for more money.

And then why does it take a zillion pages in the quickref to explain it when it has less fearutes than stock perl.

See, just like I told you.

Once you learn perl you don't need a big set of reference books to explain every obscure library.

Is there a language that, once learned, you need a big set of reference books? I use both Perl and Python (and 4 or 5 others). I have no books on Python. I have the camel book for Perl. I still find Java's javadoc to be the best language reference around. I no longer program in Java so that's just an interesting side note at this point.

Re:Perl

PERL lacking bloat? You've got to be kidding!

If you want minimal, try out UnLambda [madore.org] or Pax [geocities.com]. Unlambda is so minimal the functions (except a few built-ins) don't even get names. As a purely functional language, it also lacks variables. Despite this, it's Turing complete, so it can do anything you can do in such bloated messes as C++, PERL or Python. Pax is also Turing complete, and the page referenced above includes complete source code to its implementation, in a total of 175 lines of code (including white space, nice indenting, etc.)

What's truly sad is that even though it was apparently invented with the specific intent of being obfuscated, Pax programs are generally much more readable than most PERL. Oh, and just to address a couple of your other points: Pax doesn't need a library to do pattern matching -- in fact, the language is basically built entirely around pattern equations. The tutorial and reference manual together work out to just over 200 lines of text. Most of that is the USTL reference manual mentioned above.

Much as I hate to, I have to admit that even compared to PERL, programs in UnLambda are somewhat obfuscated -- though once you get used to its syntax, they're not quite as bad as they initially appear (rather the opposite of PERL in that respect).

At a little over a meg...

PuTTy is my clear cut winner. A little over a meg for a full installer with all the bells and whistles, what's not to love?