On 07/28/2014 09:02 PM, Joachim Schrod wrote:
You name it the other way round,
No I did not. I said that compared to using _just_ Thunderbird _alone_ that qpopper was a jack hammer. There are many reasons for bloat. They include machine word size :-) If you want an example of pervasive bloat compare the original shell you were using back in 1981 (what was that, V7? BSD 2.8?) written by Stephen Bourne and whose source code used, via macros, a version of C that read more like the ALGOL of the compiler he wrote at Cambridge (which was a marvellous piece of code!). It was small, tight, and tidied up after itself. By comparison our current shell is a whale to that tiddler, and for anything except some interactive work offers only a slight improvement with a few inbuilt functions - the 80/20 rule holds. I came to "commerce" from "aerospace" and one of my first jobs was quality control. One pervasive problem I found was lack of error handling. Coders would make system calls and not check the return status. Programs would have no error handling & recovery, they would either just carry on after errors of simply die. I asked some programmers about this. Their responses varied by on the whole to things stood out. The first was that checking every last return and writing error handlers was too tedious and was boring and took away from the enjoyment of programming, and the second was that it bloated the program "unnecessarily, since errors rarely happened", and also slowed down the execution. Whether you consider that a valid argument says a lot about the environment you work in. The other cause of bloat I see is in the code needed to make GUIs work. At the very fundamental level the X-protocol is huge and unwieldy, as the Wayland (and Y and MicroXwin and Xynth and Fresco) system shows. We've had this X protocol since 1987 and in reality those basic principles that Bob Scheifler and Jim Gettys set out have been very limiting. Perhaps the most crippling was "mechanism rather than policy". To get around that we've had to layer libraries that map (comparatively) simple high level operations that are common in the application layer to the mass of detail that X requires. We call those libraries GTK and QT. Something that implemented GTK or QT directly (or more directly) would be a boon! So while I agree with you about bloat, I think you are (a) confusing bloat with diversity. Having more in /{*/}bin may be more about addressing issue that are not apparent. I may not use the host of LVM tools other grub2-* programs tucked away in /sbin and /usr/sbin very much, and yes they "bloat out" the "ls" listings. Yes I have a LOT of scripts in my ~anton/bin. But that is diversity for you. The there's (b) confusing complexity for functionality. Sorry, but while qpopper might have addressed what I was doing in the last century it doesn't begin to deal with the variety and diversity of my needs today. If I were still running an ISP I'd need the capability in Dovecot to keep up with user demands and maintain a place in the marketplace. "Bloat"? You might consider many of today's athletes bloated too, but the records they achieve are way ahead of the athletes of a century ago. So many sports rely on strength, muscle mass, lung capacity. Size counts. So while I believe in parsimony in many areas, I also want code that checks the return status on calls, has the 'extras' that prevent buffer overflow and sql-injection and many other errors and bugs that a few extra lines and checks can avoid and has error handling. If I want my system to go on a diet I'd rather push to replace X by Wayland and put GTK and QT closer to "the bare metal". I'm not interested in giving up functionality that I have to rely on. And as far as bloat goes, dovecot scores very low. It is very tightly coded. The daemon, the anvil, the login processes, and the clients on my mail hub all add up to about one tenth the size of my Thunderbird at run-time. (Both by virtual and resident memory needs.) Perhaps that has to do with plugins. I don't run many dovecot plugins but I do run lots of Thunderbird plugins. Dovecot is very configurable that way. What you don't want you simply don't configure in. I wish more software had that kind of "complexity" :-) OBTW: what's happening with Wayland for openSuse? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org