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?"

Comments

MS Paint

[IndieKid]

I know it's a bit crap, but I must confess to quite liking MS Paint for it's simplicity. When all you need is to crop a screendump and save it as a JPG, nothing beats it!

Other than that, I'd second the VLC and Winamp combo. Ever since there has been iPod support in Winamp (via a plugin or 'out of the box') I haven't used anything else.

Re:Oh!

[tshak]

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:The Mother of All Bloat-Free Software...

[Jerry Coffin]

printf("hello, world");

Quite the contrary! You've used printf when all you really needed was puts. For that matter, even puts hides a big, complex buffering library. If you want it bloat-free, consider something like:

main() { write(1, "hello, world", 12); }

Even though I'm (at least mostly) joking, the difference is real, and at one time would have given serious consideration to doing things this way in real code. In reality, you've shown exactly how a lot of bloat really happens. Much of it stems from people using large, general-purpose libraries where they didn't really need them. In some cases (including this one) they didn't really even gain much from the library. The C stdio library provides buffering that can help speed when/if it reduces the number of times your program calls the OS write routine. In this case, the code calls write exactly once either way, so it's gained you nothing, but cost you extra memory usage and data copying, as well as making your program quite a bit larger.

Re:GIMP tile cache size

[Anonymous Coward]

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!

[snoyberg]

You might be interested in this