Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software Linux

Benchmarking the Scalability of BSD and Linux 433

Posted by michael from the pedal-to-the-metal dept.
Fefe writes "I recently did some benchmarks for a talk about scalable network programming I held at Linux Kongress 2003. The benchmark results turned out to be surprising enough to present them on their own. This ought to end those pesky flame wars about whose IP stack or memory management scales better. Or maybe not."
This discussion has been archived. No new comments can be posted.

Benchmarking the Scalability of BSD and Linux More

Benchmarking the Scalability of BSD and Linux

Comments Filter:

  • FreeBSD may be dying but it's fast! (Score:5, Interesting)

    by seanadams.com ( 463190 ) * on Sunday October 19, 2003 @03:10AM (#7252725) Homepage
    Can anyone explain the discontinuities in the FreeBSD plots? Intuitively I would guess that something is breaking at high load, rather than getting miraculously faster. The author suggests that a clever optimization is kicking in, but I wonder if his tests were actually ensuring that the calls succeed.

    Also watch out as you read the graphs - just to keep you on your toes, he changes the colors in every one!

    • Can anyone explain the discontinuities in the FreeBSD plots?

      I would have thought that was obvious.. .. BSD is dying. :)

    • I'm not so sure its dying, but forked it certainly is. Go checkout whats going on in the "dragonflyBSD" camp. Most of the posts have been by Prof Matt Dillon, an experienced coder who came up thru the amiga ranks, writing the popular DICE C compiler for it many years ago.

      What he has to say so far tells me that his version of BSD will both scale very well AND work great in the SMP dept. The process locks that slow down linux in SMP versions and prevent its doing x amount of work for each processor added a
      • The process locks that slow down linux in SMP versions and prevent its doing x amount of work for each processor added are being done away with by Matt by subbing a job isolation scheme that assures each job runs on its own cpu rather than handing each call off to a freshly assigned one.
        If I understand what you wrote, that approach will work well for something with near static process creation. However, if you are constantly forking and having the number of processes/threads being created at rapid rates,

    • Re:FreeBSD may be dying but it's fast! (Score:5, Informative)

      by __aafkqj3628 ( 596165 ) on Sunday October 19, 2003 @04:29AM (#7252935)
      Can anyone explain the discontinuities in the FreeBSD plots?

      Well, the drop-offs of FreeBSD in a couple of the graphs can be explained by him not reading [freebsd.org] the docs [freebsd.org].
      • So basically what you're saying is that FreeBSD starts to drop incoming sockets past a certain point. I guess this can be taken one of two ways (or both).

        1) FreeBSD developers feel the need to drop incoming socket connections in order to preserve performance for the rest of the system.

        - and/or -

        2) Linux 2.6 scales better.

        Why would this option start dropping at 4,000 connections *by default* instead of going the distance by default and allowing the sysadmin to throttle back if necessary?
      • I assume you mean the areas in which there is no data for FreeBSD (due to the max number of processes issue). But that's an understandable issue (although he must have missed making it runtime configurable or something). The interesting question is why FreeBSD performs better with a lot of data than with less data in some cases while still being successful.
    • Comment removed based on user account deletion

    • Improving the graphs (Score:3, Interesting)

      by hey! ( 33014 )

      Also watch out as you read the graphs - just to keep you on your toes, he changes the colors in every one!

      The author should use a graphing technique Edward Tufte calls "small multiples". In that you lay out a series of thumbmails of the each graph series. The eye can quickly scan down the thumbmails and get a rough feeling for how each series compares.

      This would avoid the problem where graphs overlay each other and with the inconsistency between graphs in the plotting conventions.
    • The OpenBSD and FreeBSD graphs stop early because OpenBSD crashed when I forked more processes, and I couldn't find out how to increase FreeBSD's system limit on the number of processes (sysctl said the value was read-only).

      If you can't figure out how to tune the OS, you sure as hell should not be benchmarking it. That line makes this whole "benchmark" worthless to me.

      -sirket
      • The really sad thing is, all of the information that the author could not find is in the tuning man page. It does not get any lazier than that folks.

        -sirket
      • No matter how much tuning he DID do, there would always be more to do (and more experts on each system pointing out what he could do). Obviously he tried, and is willing to re-run the tests if anyone has a suggestion. So, contribute instead of criticizing, and send him an email explaining how to better tune FreeBSD.
        • No matter how much tuning he DID do, there would always be more to do (and more experts on each system pointing out what he could do).

          The problem here is not that the box wasn't tuned for performance, I can respect that. The real problem is that the box didn't work. He hit limits that prevented him from doing a real benchmark.

          So, contribute instead of criticizing, and send him an email explaining how to better tune FreeBSD.

          It's in the man page. I'm sorry but he should RTFM.

          -sirket
      • If you can't figure out how to tune the OS, you sure as hell should not be benchmarking it. That line makes this whole "benchmark" worthless to me

        With your superior knowledge you should run your own, improved benchmarks and post the results.
    • Mac OSX server is based on Free Bsd5

      other web services running out of the box

      Apache 1.3 and 2.0

      Tomcat 4.1 and Axis 1.1

      JBoss 3.2

      MySQL 4

      JBoss Deployment Tools

      WebObjects on JBoss

      Perl 5.8 and PHP 4.3

      Ldap, samba
      • > Mac OSX server is based on FreeBSD 5

        You read too much marketing literature and misinterpret it. To shatter some illusions, Cheer detergent will not make your relationships better. Drinking lots of beer will not attract 5'10", 100lb models with large breasts and bikinis.

        Further:
        NeXTStep was a Mach kernel with BSD4.3 userland tools running a proprietary windowing system that uses Display PostScript (making their printer cheap) coded with Objective C.

        Mac OS 10.0-10.2 is a Mach Kernel with a user

  • no! (Score:2)

    by millette ( 56354 )
    Who's going to publish benchmark about this webserver's scalability?

  • Got Mirror? (Score:2, Funny)

    by Anonymous Coward

    Apparently the webserver with the results didn't scale so well. It's /.ed already.

    • I'd have thought that someone who submitted his own site would be ready for the resulting slashdotting -- especially someone who passes his time doing benchmarks.

      Hopefully, his next submission will be an estimate of the CPU and bandwidth required to handle a slashdotting, so that the rest of us don't get caught so flat-foted.

  • Open Source Software clearly superior (Score:5, Interesting)

    by jgardn ( 539054 ) <jgardn@alumni.washington.edu> on Sunday October 19, 2003 @03:27AM (#7252775) Homepage Journal
    The winner in this case is Open Source software.

    The article is very fair and very well thought out. It is almost like reading a research paper. It looks like he is inviting criticism, insight, and corrections, rather than trying to force the experiments into a pre-determined outcome.

    Such a thing is not possible in the proprietary world. Any study done on proprietary software has to be tainted with opinion and the experiments must be skewed. Read the EULAs. Some EULAs won't even allow you to publish the results of such tests.

    Open Source software, of the BSD kind and the GPL kind, has totally changed the way we think about and work with software. One day, we will be able to scientifically determine what software we need to suit our needs. We will know ahead of time exactly what limits and what capabilities each piece of software has. IT managers will be able to sort through real facts based on real research, rather than a bunch of shallow articles and biased reports. Software will survive on its merits alone.

    The whole industry is going to benefit by this, in a large, large way. The question one day will no longer be "Microsoft or Linux?" but "Which Open Source software should we use, and why?"
    • Rubbish. Research papers aren't filled with invective and editorialising.
    • Good point. Ithink this is basically what was intended by "computer science". Just imagine what - say - chemistry would be like, if some large corporation had their hands in the actual formulas that make things work in chemestry (at the more basic level, not chemical engineering and the like). Chemistry would be much less of a science, just as computer "science" hasn't been for the last 10 years or so. The winds of change blow!
    • Excuse me, but as there is no comparison between these results and non-OSS, how can you make that claim about superiority of OSS ? Sounds like you just needed a good excuse to blow the horn.

  • Don't miss to notice the recursion... (Score:3, Interesting)

    by presroi ( 657709 ) <neubau@presroi.de> on Sunday October 19, 2003 @03:35AM (#7252796) Homepage
    Topic of this paper [bulk.fefe.de] is

    "Scalable Network Programming
    Or: The Quest For A Good Web Server (That Survives Slashdot)"

    What a coincidence!

    By the way, fnord web server [www.fefe.de] has at least once survived one slashdotting-event. 4 seconds of googleing result in this comment [slashdot.org] which should have let to a stream of visitors.

    I hope fefe will publish the numbers of visitors and the behavior of its web server as soon as possible.

  • Theo is going to be pissed.... (Score:5, Funny)

    by gid-goo ( 52690 ) on Sunday October 19, 2003 @03:38AM (#7252806)
    Who wants to start taking bets on when Theo takes the bait.
  • Slashdot's scalability is quite amazing. It seems as a sites ability to resist a slashdotting goes up, slashdot's ability to slashdot a website also goes up. Usually it's at a higher rate but sometimes the sever makes it out alive. Although most of the time it ends up as a smoking pile of slag.

  • I'm probably going to regret this... (Score:3, Informative)

    by Pathwalker ( 103 ) * <hotgrits@yourpants.net> on Sunday October 19, 2003 @03:41AM (#7252815) Homepage Journal
    I have a complete copy (graphs and all) here [ofdoom.com].

  • I wasn't able to see the benchmark results, but I was able to see that the server its hosted on is not very scalable.

  • Very interesting comment about GNU libc (Score:3, Insightful)

    by njdj ( 458173 ) on Sunday October 19, 2003 @03:54AM (#7252852)
    I hope RMS reads the slides. They're in German at the link I used, so here's a translation of slide 13 which is page 14 of the PDF file:

    "The memory required for an empty process is shockingly large on current Linux systems. However, this is not the fault of Linux, it's the fault of GNU libc.

    GNU libc leads all libc implementations by a large margin in bloat and waste of memory. One day it got so painful that I wrote my own libc. With this, a static binary of 'Hello world' took only 300 bytes..."

    I've long suspected that FSF stands for Fat Software Foundation.

    (He doesn't say, but I assume his home-brew libc was a subset, otherwise we'd all want it).
    • "GNU libc leads all libc implementations by a large margin in bloat and waste of memory. One day it got so painful that I wrote my own libc. With this, a static binary of 'Hello world' took only 300 bytes..."

      So, did his Hello World support multibyte character sets, or, in fact, any sort of internationalization?

      Sure libc is hugely bloated. But most programs link to it dynamically so it will be loaded once. Imagine the bloat if libc was ultraslim and each and every application implemented the bloat on their
      • Rich libraries are no problem (asuming PIC code)

        The problem is overhead code that needs to be ran at startup and static variables in the libraries which require fixups in the loader.
      • No, almost all Linux software is now required to be -static because of the insane number of NON-compatible libc/kernel/distribution combinations out there.

        There was a good 2 months there where all DNS operations didn't work with dynamically linked libc's, and several distributions didn't work at all, so they decided to switch it back and break stuff even more. And that's just one example.

        libc is a huge pile of mess and bloat and bugs, and is by any measure the weak link in the Linux universe. But we seem
    • Well, all superiority of the GNUtils chain aside, I guess your point is valid at least in some way.

      I recall trying EGCS (the former GCC fork) on my Amiga as an alternative to DCC and other C compilers. Using DCC, you could almost literally tell which byte served what function; DCC produced very small binaries, and m68k assembly is a very easy read (really! it's like reading a good book).

      EGCS, OTOH, produced binaries that were immense. I recall trying to figure out the startup procedure, that is, the stuff

  • My benchmarks. (Score:3, Funny)

    by Black Parrot ( 19622 ) on Sunday October 19, 2003 @03:57AM (#7252859)


    I took three computers out in my rowboat, a Windows system, a Linux system, and a BSD system, and threw them overboard to see what would happen.

    The Windows system sank like a rock, the Linux system bobbed back to the surface, and the BSD system rose to the sky, to be greated by a chorus of angels.

    Then I woke up, so I don't know what the angels were singing.

  • Wrong FreeBSD version used (Score:2, Informative)

    by Anonymous Coward
    From the 5.1-RELEASE notes:


    Experimental 1:1 and M:N thread libraries...
    Experimental Name Service Switch infrastructure...
    Experimental support ...

    Although stability is greatly improved and many bugs have been fixed, FreeBSD 5.1 might not be suitable for ...

    So this guy grabs a beta version of a new tree in freebsd, and runs it against stable netbsd, openbsd and linux? Eh? Did he even compile his own kernel and take out all the debugging information in the released kernel? Did he turn of

  • kqueue() is available on the production quality 4.x branch of FreeBSD, whereas epoll() is only available on the 2.6 development branch of Linux and also requires a 2.3 glibc compiled specifically with support for epoll(). The glibc currently in Debian unstable, for example, still doesn't support epoll.

    The SIGIO comparison is somewhat fair, but keep in mind that implementing a program with SIGIO requires multiplexing I/O asynchronously, which radically alters program design. Linux 2.4 lacks a synchronous

  • From the article:
    • OpenBSD 3.4 was a real stinker in these tests. The installation routine sucks, the disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

    Sabotage? Someone able to bring me up to speed on this?

    As for the installation routine, it is something out of the dark ages, consid

    • Security (Score:4, Informative)

      by dmiller ( 581 ) <djm@mindro[ ]rg ['t.o' in gap]> on Sunday October 19, 2003 @04:14AM (#7252900) Homepage
      Not sabotage, security [uni-stuttgart.de]. In case you don't know: itojun is the guy between all the BSD's IPv6 support, and has been very active in the standarisation process.
    • From the article:

      OpenBSD 3.4 was a real stinker in these tests. The installation routine sucks, the disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

      Sabotage? Someone able to bring me up to speed on this?

      Well, seems like someone just read the last paragraph of TFA. Just read the sec

    • Also from the article:

      OpenBSD also caused a lot of grief on the IPv6 front. The OpenBSD guys intentionally broke their IPv6 stack to not allow IPv4 connections to and from IPv6 sockets using the IPv4 mapped addresses that the IPv6 standard defines for thus purpose. I find this behaviour of pissing on internet standards despicable and unworthy of free operating systems.

    • Re:What IPv6 "sabotage" did OpenBSD do? (Score:5, Informative)

      by __past__ ( 542467 ) on Sunday October 19, 2003 @05:24AM (#7253061)
      Oh and the read-only sysctl problem for FreeBSD that he mentions was probably due to securelevel's being on (meaning you can't modify kernel variables).
      Nope, kern.maxproc is really read-only in a running system even in securelevel -1. You have to set it in /boot/loader.conf (which doesn't seem to be prominently documented anywhere, so not finding it is nothing to blame fefe for).
    • I agree, the guy is a complete troll:

      If you are using OpenBSD, you should move away now.

      Right, because those of use using Open are doing so out of total performance. Lets do a comparison of the security of these systems and see who wins that one. I think most Open users (incidently I use it as my workstation and my server here) would use Net, Free or Linux in an all out performance situation. For security and comfort, I'll keep my Open machine thanks.

      Using, development code and untuned boxes to d
      • Right, because those of use using Open are doing so out of total performance. Lets do a comparison of the security of these systems and see who wins that one.

        Ok, let's start with resilience. Quoting from fork benchmark: "OpenBSD does not scale at all, and even panics under high load."

      • Security? Well seems nearly the same. Recent openssh problem? Affected all systems, about same impact.

        Openssl problem? Same.

        Oh you mean just the o/s alone? Well panics under high load = bad. And if it's just O/S alone, then OpenBSD is overrated WRT security. Even a fully patched win95 is pretty secure if you don't run MS client - just use plain tcp/ip, and you don't run any other services.

  • Using an unstable development version and then complaing about instability, peppering the results with emotive commentary and clueless rhetoric. (btw the 1024-cylinder boot restriction he complains so much about has been fixed for a while) Especially funny was this idiotic statement:

    OpenBSD also caused a lot of grief on the IPv6 front. The OpenBSD guys intentionally broke their IPv6 stack to not allow IPv4 connections to and from IPv6 sockets using the IPv4 mapped addresses that the IPv6 standard defines

  • FreeBSD-5!? (Score:3, Insightful)

    by __aafkqj3628 ( 596165 ) on Sunday October 19, 2003 @04:20AM (#7252912)
    I'm wondering, if he was going to be doing a scalability test, why didn't he test the version of FreeBSD that is actually reccomended for production (4.8)?
    He had the time to test the stable and devel versions of the linux kernel, but only the new technology version of freebsd?
  • Evidently his site doesn't handle traffic very well, especially on the Slashdot Scale.
  • From /usr/src/UPDATING:

    NOTE TO PEOPLE WHO THINK THAT 5.0-CURRENT IS SLOW:
    FreeBSD 5.0-CURRENT has many debugging features turned on, in
    both the kernel and userland. These features attempt to detect
    incorrect use of system primitives, and encourage loud failure
    through extra sanity checking and fail stop semantics. They
    also substantially impact system performance. If you want to
    do performance measurement, benchmarking, and optimization,
    you'll want to turn them off. This includes various WITNESS-
    related ker
    • Er, he wasn't using 5.0.

      He was using 5.1 and then 5.1-current (closer to 5.2 really).

      I wouldn't put up a web server (let alone a heavy use one) without tuning it some (many things a web server needs are either unnecessary or unwanted for a box dealing with users or NFS, etc); a new kernel and removing some limits and adding some is warranted.

      That said, Linux 2.6 is experimental, so is FreeBSD 5.x

      I'd be curious to see how it stands up on duplicate Sun SPARC machines, or on Alphae, etc. but time limits s

  • I knew the Linux 2.6 kernel was supposed to be faster and more scalable, but, damn, that's awesome.

  • Nothing new here (Score:5, Insightful)

    by chrysalis ( 50680 ) * on Sunday October 19, 2003 @05:20AM (#7253051) Homepage
    There's no need for such a very technical benchmark.

    Regular usage of various operating systems on the same host makes it obvious.

    When it comes to speed and features (or bloat), Linux is more efficient than FreeBSD, NetBSD and OpenBSD. This is especially significant in SMP environments.

    Linux users are always talking about the just-released experimental patches that will help their system to get 0.1% faster, or the most aggressive flags to optimize their Gentoo system.

    BSD users just advocate their system with the generic word "robust".

    Nowadays, stability is not really the key. Every Linux or BSD free operating system has basically the same stability. The software is the same, with the same bugs. The package system have equivalents (Debian works on NetBSD, Gentoo works a lot like BSD ports, etc) and support for common hardware is almost identical.

    The reason to choose one OS over another is often more political than technical. People tend to use FreeBSD just to try "something else". People tend to use Linux because the Mandrake/RedHat/Conectiva/SuSE installers are beautiful or because Gentoo is fashion and a good way to learn what Unices are made of.

    But if this is just to use common software like Apache and Qmail there's no real difference except speed. If this is what you need, Linux is definitely the best choice nowadays, especially since 2.6 kernels are almost ready for production use.

    For other needs, your mileage may vary.

    For instance I love OpenBSD for development. The compiler and the libc have very handy features to automatically detect bogus code. And the man pages are also excellent, with helpful hints.

    For firewalls and trafic shaping, I wouldn't use anything but *BSD because of PF. PF is really the best thing in *BSD systems IMHO. The firewall is very easy to configure yet extremely powerful and fast. And I was fond of Iptables before.

    For bridging and transparent firewalls, I would also use BSD because it seems to work better than Linux in this area.

    In fact it's just like the girl of your dreams. Everyone's always looking for the perfect operating system that will perfectly fit all needs, but it just doesn't exist.

    • The reason to choose one OS over another is often more political than technical. People tend to use FreeBSD just to try "something else". People tend to use Linux because the Mandrake/RedHat/Conectiva/SuSE installers are beautiful or because Gentoo is fashion and a good way to learn what Unices are made of.

      Ahem... Sorta. But even you go on to say you like PF better and that's why you use *BSD for stuff.

      I like FreeBSD for its basic simple and small install and generally the system is just simple, tight,

  • Your scientific method isn't one, and these results are invalid as a result.

    You took in-progress development release of OpenBSD compared to stable releases of other operating systems (even your NetBSD was a RELEASE rather than a CURRENT). CURRENT is always going to be an in progress development and not entirely stable.
    • wow, i didn't realize that linux 2.6 has been released as stable!

      are you an Amiga fan, too?

      • Forgive my ignorance then; so 2.6 is not stable; that even further supports my assertion that the tests are between non-stable versions: it may just happen that 2.6 linux is not only good, but also more stable than the BSD's.

        I still think the results here are useful, in that they provide some general guidelines, but I would be very wary about some of these exceptional problems the tester ran into, because those problems (e.g. the mmap under OpenBSD) could easily be attributed to instability due to current
        • I personally think the tester did exactly the right thing: Use the defaults that come with the distribution/installation because that's exactly what almost all users are going to use in the real world.

          If there is something wrong with the settings, then the project should reset the defaults to sane values, rerun the benchmarks (all the programs are there) and ask the tester to confirm and/or publish them.

  • Well, I'm not entirely sure whether these results demonstrate that Theo is an even bigger dickhead than we all already thought he was, or if this guy is a perfect candidate for a position on Apple's G4 benchmarking and marketing team. Maybe both? Do you have to be able to read docs to market G4s?

  • It's this type of information that does OSS a disservice - making it look amateur and unprofessional.

    You used an pseudo-scientific method, i.e. your graphs are nice, your data points are nice, but you forgot the fundamentals of testing: you didn't clarify the exact projects you were testing (you should have asked the project leads for advice on which versions of the projects to test against), nor did you asked for feedback and determine the reasons for the anomalous conditions (e.g. the FreeBSD maxprocs co
    • I am not pretending to produce the be-all end-all benchmark here. That would at least include having an SMP server for the operating systems that support it, and it would have used Gigabit Ethernet. Frankly, I don't have the hardware to do that.

      But I do have these benchmark programs, and I was hoping to spark enough interest in doing some real comparative benchmarks by posting the results here. The tools are now there, and they do use the platform specific API hacks to get the best performance on each o
    • Far more importantly, where is his source code for the testing?
      The data points looked biased enough that I wouldn't trust his results without being able to review his code.
    • It's this type of information that does OSS a disservice - making it look amateur and unprofessional.

      Oh sure. All those stupid latency measurements. Next time he should chart framerates in Quake, right?

  • open BSD, slowliness (Score:2, Interesting)

    by lunardude ( 548375 )
    In The article, The author mentions that he finds "unacceptable", or embarassing, a few things about openbsd, mainly concerning it's general speed and scalability.

    ALthought not beeing an expert in bsd nor in linux, maybe i'm rong, but isn't OpenBSD made to be secure, and not the fastest operatin system ( additionally, comparing oragnges to apples, by testing release/current/stable, wasn't the best way of comparing those OSes) ????

    By implementing a few feature in the OpenBSD stack and Kernell, I guess that
  • Felix is more than opinionated about Linux vs. BSD. Check the qmail mailing list archives for his rants with BSD users about filesystem and other performance issues. In particular, he's had a number of run-ins with those on the list who use OpenBSD--the one he labels a `stinker'.

  • Real point: they show improvement (Score:3, Interesting)

    by iabervon ( 1971 ) on Sunday October 19, 2003 @12:48PM (#7254779) Homepage Journal
    The interesting point is that all of these operating systems seem to be getting faster. It seems to come down to how many recent developments have been integrated into the version being tested, not any inherent differences between operating systems. This is, of course, as it should be: the source for all of these operating systems is available, and there are even frequently papers describing the techniques. If a technique is, in fact, better, it should eventually be adopted by all of them, and so your results will depend on how much has been adopted in the version you're testing.

    It is encouraging to see that all of these developers are competing with the real opponent, which is not each other or even Microsoft, but the slashdot effect. After all, the goal should not be simply to be better than the others, but to be sufficient for the user's purpose, which is not hampered but rather assisted by sharing all of your tricks. It can sometimes seem like there are endless wars between Linux and BSD, but, behind the scenes, the sides actually share information. Never as much as they'd like, but always more than people think.
  • In reference to a particular metric (not the entire suite of tests) he says "Even Windows would probably outperform OpenBSD"

    Talk about taking the kids gloves off!

    -Adam
  • I know this benchmark is about open source and all, but I would love to see Solaris thrown into the mix. With all its vaunted scalability and stability, I'd love to see what it actually does better. I guess it would have to be the Intel version, but I would think their kernel algorithms should be the same across architectures.
  • I for one had a terribly hard time reading the graphs. Three problems in particular:

    1)
    I (like about 20% of the male population) am partially color deficient.
    The graphs' colors where very hard for me to distinguish in the ledgend; what with the 1 pixel wide font and sample line/symbols. The colors chosen were all of about the same intensity/saturation also, so if you are color blind the entire graph would look all about the same level of gray. This problem is further compounded by all the graphs having di

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close