[gizmo]

There are projects that are close to bugfree, though. You can use a 3 year old version of sqlite without any difficulty. I don't know what version of "ls" or "mkdir" my machine runs, but I never worry about these simple utilities being out of date or behaving differently in release/staging. These utilities are essentially done, and 30 years from now they'll still work fine.

There is no software without bugs in the same sense that there exists no hardware that cannot fail. But you can create software that is so close to perfect that hardware failures outnumber software failures 100:1, so there is no point in pursuing perfection any further.

[ken]

SQLite is not typical software. It has over 90 million lines of test code, and is run in production every day by pretty much every computer in the world.

mkdir(1) is also not typical. Excluding the copyright header comment, it's so short that it fits entirely on one screen. If I ran into a bug, I could probably find it and fix it (or write my own version) in about 3 minutes.

It is indeed possible to "create software that is so close to perfect that hardware failures outnumber software failures 100:1", but it's so time-consuming that almost nobody ever does it.

Version 1.0.1 of a free mind-mapping app may be good and useful software, but I can virtually guarantee it has bugs. I doubt even the author would claim it's only at 1.0.1 because "there is no point in pursuing perfection any further".

[gizmo]

I agree that sqlite's quality is unusually high. That's why I used it as an example of what kind of quality is achievable.

However, I think you're approaching this from the wrong way. The most important thing about sqlite isn't the amount of manhours put into it, but the millions upon millions of manhours that have been saved because the product works so unbelievably well.

sqlite is the exception, and this is because the people involved in it really care about quality. Our software engineering culture has a lot to learn from the success of sqlite.

[cesarb]

> mkdir(1) [...] it's so short that it fits entirely on one screen.

296 lines in the main .c file, without counting the headers and helper functions: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...

[carbocation]

And, entertainingly, it contains a FIXME! https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...

[PatchMonkey]

http://www.cvedetails.com/vendor/9237/Sqlite.html

Really? A running 3 years out-of-date sqlite install?

Methinks some hackers smell chum in the water. XSS, remote code execution, priviledge escalation, directory traversal... and for most of these, we even have choices on how to attack! Plenty of overflow attacks involved here. Where are the idiot script kiddies when you need them to demo how this ignorance hurts?

And once in to your sql database, I wonder where else we can pivot...

Remember how shellshock shook the world, because the software bedrock was actually insecure? Yeah... your old, "stable" stuff has had holes the entire time.

Stay current. If your OS makes that a challenge, ditch it for a better one.

[criddell]

mkdir? I'm trying to imagine somebody deciding to no longer use directories because mkdir looks like it's been abandoned.

[tluyben2]

> are close to bugfree

Or bugfree for the use cases of it's users (how many or few there may be).

[MrQuincle]

I've had enough of small utilities that didn't work as expected. Also ls or mkdir can for example be part of busybox ported to a Blackfin. No guarantees that there are no bugs in these by far!

Edit: here you have the source code for the "small" ls utility: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c. Yes, over 5000 lines.

[gizmo]

Your claim was that "there is no software without bugs". I'm pointing out that this is true only in the narrow philosophical sense. You cannot draw a perfect circle, either. But you can draw a circle that gets pretty damn close.

Software cannot be perfect but this doesn't mean that software needs to be shoddy. sqlite is a complex product and it has orders of magnitude fewer bugs than other projects of similar complexity.

It is factually, observably, possible to create software that is very close to perfect, it just takes a lot of hard work. Software has a reputation for being buggy not because it's impossible to write flawless software, but because most software is really poorly written.

[thisacctforreal]

The feature bloat is typical for gnu coreutils; for reference ls.c for OpenBSD, NetBSD and FreeBSD is 614, 716, 933 lines respectively [1][2][3]

[1] https://github.com/Bluerise/OpenBSD-src/blob/master/bin/ls/l... [2] cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/ls/ls.c?rev=1.75.4.1 [3] https://github.com/freebsd/freebsd/blob/master/bin/ls/ls.c