OpenBSD Journal

Resolving OpenBSD Bloat: Unpuffing Puffy

Contributed by grey on from the can't wait for my unbloated puffy mascot tshirt dept.

Thanks to Wu for the pointer that frequent OpenBSD community contributor Francisco Luis Roque has put together a nice exposition of the bloat within OpenBSD. Reminiscent of some of the notorious benchmarking articles we've seen OpenBSD involved with over the past few years, Francisco illustrates his argument with various detailed graphs and links to additional resources. Definitely worth checking out:

http://www.blackant.net/other/docs/unpuffed/

(Comments are closed)

Comments

  1. By Anonymous Coward (69.158.153.54) on

    God damn it. I hate April Fools day. Useless garbage all over the net today.

    Comments

    1. By jitterbug (64.48.234.153) dance-i-said@yahoo.com on

      rightous, but true. how's this for april fool's? any april fool's joke that ends in an autopsy has to be... uh.. one of the most april-fooliest of them all?

      Comments

      1. By Joe (24.1.16.2) on

        Speaking of "rightous, but true".

        Simply unbelievable.

  2. By Anonymous Coward (67.141.129.97) on

    My favorite punch-lines:

    "Though the default install allows for remote logins, little else is running by default, leaving a relatively useless install for no apparent gain. Contrast this with more robust OS's which run many more services."

    The sad thing is that I know a large number of people who actually do see it this way and wouldn't get the joke at all. *Shiver*

  3. By Anonymous Coward (71.0.126.14) on

    Despite this being a April Fool's Day joke, it touches on one of my minor grievances.

    I think that separating the the server daemons into serverXX.tgz package would be better than throwing them all in the baseXX.tgz. Some people don't always need them, like those using OpenBSD as a desktop system or for terminals needing client only access. This could also save a bit of FTP traffic in addition to the users disk space.

    Comments

    1. By Michael Knudsen (217.157.199.114) on

      Assuming that 50% of base36 is servers, then you might save perhaps a grand total of nearly 50MB!

      How much is a 250GB IDE disk these days again?

      Don't trade a non-issue for complexity. If space constraints is an issue, look at something like flashdist.

      Comments

      1. By Anonymous Coward (213.118.35.44) on

        What do you mean space isn't an issue? Are you some kind of a mentally challenged person? Diskspace and bandwidth are *always* issues.

        Comments

        1. By Tim (168.253.133.120) on

          What about TIME. Except for MONEY, TIME is the most important issue an IT person should always keep in the back of his mind. OpenBSD is the only operating system that installs all the basics in 5 minutes using a cd. (Oh excuse me, except for MS-DOS.) And because OpenBSD focuses on security, I don't have to WASTE TIME uninstalling or disabling CRAP. If I don't need apache, hey, I don't have to waste any time disabling it and I can leave it alone because I know it's not going to cause me problems later. I have experimented, and continue to experiment, with many Linux distributions and each time I come back to OpenBSD because IT SAVES ME TIME. The only Linux distribution I found worthy is Knoppix because it saves me time, until I install it on the hard drive which it wasn't meant for.

          OpenBSD is hard to learn. But when you learn something on OpenBSD, you are astounded with how easy and fast it is to accomplish your task.

          Comments

          1. By Anonymous Coward (71.0.126.14) on

            It would also be faster for your install to have the servers as optional. At the prompt where you select the packages to install. If you know you don't want them, it's four extra keystrokes to deselect them, ("-s*[ENTER]") which you get back on the time you save by not installing them.

            I probably should have stated that I think they should be optional, but still part of the default install in my original post.

            Comments

            1. By Anonymous Coward (66.63.143.34) on

              I still like it the way it is. There are many times that I need the servers I'm currently not using. If anything, I wish there was a desktop.tgz so I could have a basic OpenBSD desktop if I chose to install it, but then someone will complain that we should use gnome instead of kde, mutt instead of kmail, blah, blah, blah, blah, blah. I hate it when I install debian or redhat, and I have to waste my time selecting and "deselecting" packages. It's easier to just select everything to avoid future problems with Linux, but then I have to deal with the security implications from all that bloat.

      2. By Peter Dembinski (217.96.175.71) pdembinski@konin.lm.pl on http://www.pdembinski.konin.lm.pl

        250GiB? I run OpenBSD on a box with 800MiB harddisk. In my laptop, there is only 3GiB HD, and I want to run several operating systems on it. Space does matter, many people run OpenBSD on old computers.

      3. By Anonymous Coward (71.0.126.14) on

        You are assuming that everyone has a high speed connection, money to buy an extra disk, a system that can boot large disks, or that these installs even use disks at all.

    2. By Anonymous Coward (213.118.165.151) on

      While it's nice to be able to choose what to install in fine detail, it has some problems too. If you have a lot of install sets, you get problems with dependencies etc. You could go the route of certain Linux distributions, and make everything into optional packages (to be added with pkg_add), but then you lose the distiction between base and third party software. And as said before, hard disk space is cheap. And a base install of OpenBSD is small. So it's really a non-issue. The only application in which you're tight on space is CF-based embedded devices. But it that case there's stuff like flashdist that actually just select a subset from the OpenBSD default install. But with CF prizes dropping, these kind of modifications may soon become unnecessary too (except for the coolness factor of having a working OpenBSD system in 8mb or even less :-) )

      Comments

      1. By Anonymous Coward (71.0.126.14) on

        I'm not saying split it up into hundreds of optional packages or messing with pkg_add at all. I am saying one distinct separation between client and server component packages, similar to the way (and for the same reasons) there is the gameXX.tgz, compXX.tgz, then the x*.tgz series of packages. When a person performs an install, they will pretty much know if they intend to use these or not. A clearly named pacakges is fairly self explanitory, leaving the install process streamlined.

        Comments

        1. By Leon Yendor (218.214.194.113) on

          You have not explained exactly how you would like the server set(s) split up.

          Do you mean that we would lump ntpd, smtpd, sshd, spamd and others with httpd and ftpd for example?

          I may want sshd on every install but ftpd never. Maybe I want ntpd as well on every workstation but I never want spamd on my webserver nor do I want, for example, httpd on my mailserver.

          How about you just set the flags in rc.conf to not run the things you don't want running?

          The way things are now I can do an install in a bit over 5 minutes. With too many splits I am going to feel like this is Lunix where I cannot do an install of one of the majors in less than 30 minutes.

          In addition, however the daemon set(s) is/are split there will be whining about the selection.

          As it is httpd is installed on every box I load. I rarely use it. Changing rc.conf to make it run at boot time PLUS doing a quick edit of httpd.conf takes me less than 10 minutes. BFD!

          Next there will be crying about how it would be better to compile optimised kernels at install time....HarDeHarFingHar!

          Comments

          1. By Anonymous Coward (128.36.236.30) on

            "The way things are now I can do an install in a bit over 5 minutes. With too many splits I am going to feel like this is Lunix where I cannot do an install of one of the majors in less than 30 minutes."

            It shouldn't take more than a few minutes to copy Lunix to a floppy disk and boot it.

          2. By Anonymous Coward (71.0.126.14) on

            Wow. You really had to fish to make a criticism here, didn't you. I thought "server daemons" was fairly server daemon inclusive.

            There are two basic types of install. Server and client. A client needs no server components. Those would be httpd, ftpd, sshd, etc. Basically, any daemon used to allow remote access to the machine. You know, actually "serves" something per an outside user's request? A client install needs none of that, instead it needs basic tools that access those kinds of services.

            You may not want to run ftpd but run sshd on everything. That is, after all, your perogative. And if that is the case, then install the server set, and then only start up the ones you want. At least you have a reason to install the server set. But that would be too complicated wouldn't it? Better that we all just install all of them by default, even if we wont run even one of them, right?

            Or, you could build ftpd alone from the source. That would require that you install the optional compiler package though.

            It's nothing shy of lazy if you won't type "servXX.tgz" to include the server collection. It says nothing less than incompetent if you can't figure out if your server might need server compnents.

            Actually, you should have to type "-servXX.tgz" if you don't want them, because it should really be an opt-out package for those who know they wont be using it. With it being opt-out, nothing changes about your install process, except you forfeiting your ability to decline. But then again, typing "done" at the install sets prompt like you normally do it just too much effort isn't it?

            This is about a logical divide between what constitues a "base" system, and what things are addons to its usability. A base system doesn't need a compiler, it is optional. A base system, doesn't need X, again, it's optional. Many would argue that man pages are essential, but even these are optional. Noone "needs" games, yet they too are optional, and even installed by default. Servers? Not everyone needs them, but eveyone gets them regardless.

            What part of letting users choose thier install sets based on the systems inteded role doesn't make sense to you?

            If I am building a system for a firewall, I don't need X, the compiler, the man pages, or much of anything else for that matter. Why would I need Apache? In fact, if I am running it diskless, I probably want as little cruft as possible clogging up my RAM. Why should I install anything but a real "base" system here if all I really need is a working kernel and pf?

            Over complicating is trying to take a simple idea such as giving users the flexabilty to say "I wont be needing any of those", and turning it into "lets break it into a million pieces". It's not only a huge stretch of the imagination, it's also an indication of narrow thinking.

            Oh, and since you don't really seem to be that familair with the nuances of the rc.conf file as you think, by default, no servers are set to run except sshd, for which you are asked to confirm that intent upon install. So really, out of the box, if a user has no intention of running any server daemons, he doesn't have to do a thing. That's real hard, isn't it?

            The saying goes "Secure by Default", not "Server by Default".

            The question still remains though, that if one doesn't plan to use OpenBSD in a server environment, and by default no servers work until properly configed and acivated anyway, why should they have to install server components at all?

            Comments

            1. By Anonymous Coward (213.118.165.151) on

              Certain servers _are_ needed even on a client box. You probably want sshd. If you're using an MUA like mutt, you also want to run an MTA (sendmail, most likely configured to use a smarthost).

              Other "daemons" you may want include lpd, ntpd, maybe a caching named, various daemons for netbooting (you never know when you have to temporarily set up a netboot server on your laptop in 5 minutes to install another box), ftpd (to serve the contents of the installation cd to that dusty sparc without cdrom you're installing), ...

              So really, what do you gain by separating the daemons from base? You gain a tiny bit of disk space (which is dirt cheap on a client pc; heck, even a zaurus has plenty of space). You don't gain any security. But you lose convenience.

              Comments

              1. By Anonymous Coward (71.0.126.14) on

                I short, I know there would be a few exceptions. Namely, sendmail. For the rest, again, you are talking about those who need them and know they need them vs those who know they don't need them. The gain is less bloat for isntalls that don't and a more logical hierarchy to the install. If you need the capacity to service inbound connection, keep the server package to be installed. If you don't, drop it and your install will be that much smaller.

            2. By tedu (64.173.147.27) on

              Why would I need Apache? In fact, if I am running it diskless, I probably want as little cruft as possible clogging up my RAM.

              um, what? how does installing apache on an nfs server clog up your client machine's ram?

              Comments

              1. By Anonymous Coward (71.0.126.14) on

                A firewall is not the same thing as an NFS server, and a ramdisk occupies ram.

                Comments

                1. By tedu (64.173.147.27) on

                  how do you install onto a ramdisk? i must have missed that part of the install script.

                  Comments

                  1. By Anonymous Coward (71.0.126.14) on

                    pxeboot(8)

                    For the rest, google is your freind.

                    Funny though, last I checked, the subject wasn't about the specifics of how to deflate the base package onto a ramdrive, but why server specific components should be optional. But unless a developer comes out and says it's a good idea personally, the rest of the community will never agree with the notion. And if one does say that, you all always thought so too. For those reasons, I won't hold my breath on this ever happening.

                    Comments

                    1. By tedu (69.227.45.201) on

                      "Funny though, last I checked, the subject wasn't about the specifics of how to deflate the base package onto a ramdrive, but why server specific components should be optional."

                      that was exactly my point. :)

                      even if there were some hypothetical client.tgz and server.tgz packages, nobody creating a ramdisk would shove the entire contents of either into a ramdisk. so the whole "clogging up my ram" argument is just absurd.

                      Comments

                      1. By Anonymous Coward (71.0.126.14) on

                        that was exactly my point. :)

                        even if there were some hypothetical client.tgz and server.tgz packages, nobody creating a ramdisk would shove the entire contents of either into a ramdisk.

                        Sorry, but that was not your point. I cited a hypothetical example of how one could benifit from a smaller, more minimal base. It's not the best way to go about the suggestion, but it's actually alot less difficult than building your own minimal system. You were the one who made issue of how exactly to go about doing it, so don't even try to claim that your point was showing me as off subject.

                        so the whole "clogging up my ram" argument is just absurd.

                        Wow, shall I point you to the defintion of "context"? You are clearly trying to take "clogging up my RAM" out of it. Since I am speaking of a space needed to hold a file system on a ramdrive, the smaller that file system is, the smaller that ramdrive itself can be. A smaller ramdrive leaves more physical memory open for the actual processes. And if you can't see the logic in that, I feel sorry for you.

                        Further, I never said anything about a client.tgz, only seperating the server daemons from base into an optional-but-installed-by-default package. My idea probably naively assumes that everyone needs the basic client utils on almost every system, including servers. Or at least, a marginal few wont make use of them compared to the disproportionate number of those who wont make use of the servers.

                        It may be hard for some of you to imagine, but some people are actually using OpenBSD for desktops instead of or in addition to servers. I only recently started playing with it as such, even though I have been using OpenBSD for every other role I could think of for years. I find that it works well beyond my expecations, to the credit of all the developers and port maintainers. It works well enough that I now have no use for any other operating system. But that still doesn't mean that my desktop needs apache or an ftp server installed on it, even if they are not running by default. And that has been my only point in all along.

                        If we know we don't need them, let us have the option to skip them during install. It's not rocket science.

                        What is absurd is that I keep responding to a more or less dead horse of a passing comment, and feeding the trolls who would rather spew FUD about complication, or nit pick the semantics of how-to for every what-if that someone might do with an install. Yet, for all of it, not one person has stated a reason why they actually should remain in the base package.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]