Librenix
Headlines | Linux | Apps | Coding | BSD | Admin | News
Information for Linux System Administration 

Why software sucks

Up
vote
Down

I've heard widely varying opinions on why software is so lousy, the most recent from this article by Charles C. Mann. Mr. Mann makes an excellent anecdotal case for just how bad software has become. Then, he concludes that perhaps a bit more litigation would help matters. While one of the perpetrators of bad software he cites is Microsoft, they, and other wealthy software development companies, might be among the least vulnerable to lawsuits brought over poor software. As is frequently the case, increased litigation would probably put the small developer at even more of a disadvantage relative to the large software corporation.

But more to the point, why is software so bad? Programming is sometimes compared to an engineering specialty and the point is made that product standards are much lower for software. Software, unlike building construction, for example, is pure design. The actual programming phase is just a finer grained version of what we programmers normally call 'design'.

Software development is one hundred percent design.

Consider the implications of that statement for a moment. Virtually all of the cost of software development is, directly and indirectly, the cost of design. If a student architect could design a skyscraper, push a button, and have some futuristic genesis device instantly construct the building at virtually no cost -- and at no danger to anyone -- and with perfect components throughout, would he not do so? Further, imagine that with a push of another button, the entire building could be reduced back to its constituent atoms.

The student could try and try again, refining his design until it was finally just what he wanted. Now, imagine that there was no danger in occupying such a building. Would it change the way we make buildings? Given the alternative of spending millions to build the building the old fashioned way versus spending a fraction of one percent of that to do only the design -- and automate the remainder for virtually nothing -- I suspect that the market would choose the vastly cheaper method.

For software that doesn't involve life-or-death applications, the development cost model closely resembles our fictional architectural scenario.

People are understandably reluctant to add real engineering discipline to software development. While there is no physical building phase, the complexity of a large application is staggering. A large program might have millions of (logically) moving parts, all interrelated. To prove that it all works correctly, as specified, might be more than just prohibitively expensive; it may well be impossible. And even if such verification were possible, proving the correctness of a large program would greatly delay the release date.

Perhaps life support systems, X-ray machines, and other such critical programming does belong in the engineering realm with formal education requirements, legal responsibilities, and state certification. But for my favorite projects, I think the status quo is just fine.

Yes, software sucks -- but it's usually cheap. Further, in my experience, the cheapest software, free, seems to suck the least.

Fast, good, cheap: choose two.
mail this link | permapage | score:8915 | -Ray, June 19, 2002 (Updated: April 26, 2011)

A multithreaded web server for Linux (source code)

Up
vote
Down

A nice example if you're building a multithreaded server...
The only one source file has been modified is server.c
Instead of fork new process to handle each incoming client's connection,
as procedure server_run ( ) does in [1], we start pool of 1024 threads
accepting as parameter descriptor of passive socket.

The procedure run by each thread is asynchronous BSD socket’s server utilizing
select() system call (see for example [2],chapter 13(5)) to switch between
handling incoming client's requests by accept() system call and receiving "http"
requests from clients already connected to server utilizing procedures
handle_request() and handle_get() from [1],chapter 11.
read more...
mail this link | permapage | score:8906 | -Ray, April 29, 2005

Install FB4Linux in Eclipse

Up
vote
Down

Flash development in Linux is often left to a generic text editor used with the free Flex SDK. It is certainly possible to code this way, but you do lose out on a lot of the functionality of a more specific IDE. The FB4Linux project provides a plugin for Eclipse that provides a similar environment to FlashBuilder 4. The only downside is that the installation instructions gloss over a few of the details required to get the plugin installed in Eclipse 3.5.2, which is the version of Eclipse that is available in the Ubuntu software repositories at the time of writing. This article shows you how to get FB4Linux up and running from start to finish. read more...
mail this link | permapage | score:8879 | -mcasperson, July 27, 2010

Pattern matching in shell scripting

Up
vote
Down

This article is excerpted from the book Beginning Portable Shell Scripting.
Shell programming is heavily dependent on string processing. The term string is used generically to refer to any sequence of characters; typical examples of strings might be a line of input or a single argument to a command. Users enter responses to prompts, file names are generated, and commands produce output. Recurring throughout this is the need to determine whether a given string conforms to a given pattern; this process is called pattern matching. The shell has a fair amount of built-in pattern matching functionality.
read more...
mail this link | permapage | score:8870 | -Ray, January 1, 2009

Why Programmers are not Software Engineers

Up
vote
Down

People toss about the term 'software engineering' as if programming were just another engineering discipline.

Programming is 100 percent design. And that design is vastly more complex than the typical true engineering effort of comparable cost. Said another way, an engineering project of similar logical complexity to a software program is far more expensive.

Much of the reason for that low cost is that programming has no comparable build phase that, in some other field, might consume the vast majority of the total cost.

Programming is dramatically cheaper than a similarly complex physical project.

Programming doesn't fail in the same sense that an engineering project can fail. Programs never fail because of faulty materials or shoddy workmanship -- except in the compilation phase, perhaps, but in that case the program doesn't even exist. Programs don't fail because of use beyond their rated capacities, although they may fail because they foolishly accept input or a load beyond their capacities.

Programs only fail due to design flaws.

Ignoring terminology for the moment, the reason that software quality is so much lower than one might expect is fundamentally economic. The 'engineering' phase, the design, represents nearly the entire cost of the actual development. The only place where costs can be shaved is design. The building blocks of the actual construction, opcodes, are essentially free.

Software doesn't meet engineering standards, largely for economic reasons.

And, lastly, an engineer is one so designated by government. With that title comes certain legal responsibilities. 'Software engineers' are neither designated as such nor are they held to engineering standards.

Engineer is a title conferred by the state and it may not even be legal to call yourself a 'software engineer'.

On the other hand, the best programmers I've met don't call themselves engineers at all. They call themselves programmers, coders, and hackers. Evidently, there is no shame in that. Let's leave the engineering title to those who have earned it and accept the responsibilities that come with it.

We should be thankful that we aren't held legally responsible for the performance of our designs.
mail this link | permapage | score:8855 | -Ray, November 25, 2002

Introduction to Perl one-liners

Up
vote
Down

Perl one-liners are small and awesome Perl programs that fit in a single line of code and they do one thing really well. These things include changing line spacing, numbering lines, doing calculations, converting and substituting text, deleting and printing certain lines, parsing logs, editing files in-place, doing statistics, carrying out system administration tasks, updating a bunch of files at once, and many more. Perl one-liners will make you the shell warrior. Anything that took you minutes to solve, will now take you seconds! read more...
mail this link | permapage | score:8849 | -pkrumins, May 28, 2012

Tutorial: Write a PHP wiki

Up
vote
Down

Wikis are widely used as tools to help speed development, increase productivity, and educate others. This tutorial creates a wiki from scratch using PHP, with value-added features useful for tracking production. It focuses on application design with PHP. All of these things make PHP a good choice for writing a wiki engine. read more...
permapage | score:8820 | -solrac, February 22, 2007

Sed One-Liners Explained

Up
vote
Down

My previous post was about Awk One-Liners Explained and now I bring to you Sed One-Liners Explained!

Most people are only familiar with one particular command of sed, namely the "s" (substitute) comand. s/comand/command/. That is unsatisfactory. Sed has at least 20 different commands for you.

For example, any ideas what this sed one-liner does?

sed '/n/!G;s/(.)(.*n)/&21/;//D;s/.//'

Read the article to find it out! read more...
permapage | score:8814 | -pkrumins, November 22, 2008

Mac Shell Scripting Tutorial

Up
vote
Down

A tutorial on scripting for the Mac, from Apple.
This document assumes that you already have some basic understanding of at least one procedural programming language such as C. It does not assumes that you have very much knowledge of commands executed from the terminal, though, and thus should be readable even if you have never run the Terminal application before.

The techniques in this document are not specific to Mac OS X, although this document does note various quirks of certain command-line utilities in various operating systems. In particular, it includes information about some cases where the Mac OS X versions of command-line utilities behave differently than other commonly available versions such as the GNU equivalents commonly used in Linux and some BSD systems.
read more...
mail this link | permapage | score:8813 | -Ray, October 10, 2006

Unix signals list

Up
vote
Down

Processes are required to respond to signals sent to them. This is one way a user can communicate with signals and control them.
Signals are asynchronous events that can occur to a running process and may be caused by hardware, software or users. Signals are numeric integer messages that have been predefined so they understand what these signals mean. When a process receives a signal, that process must respond to the signal. Uncaught signals will cause default actions to take place, which often means the process is terminated. If you use “kill -l”, or “trap -l” you can get a list of available signals:
read more...
mail this link | permapage | score:8794 | -aweber, December 31, 2010

Tutorial: Android development environment on Fedora 14

Up
vote
Down

This tutorial describes how you can set up a development environment for building Android apps on a Fedora 14 desktop using Eclipse, the Android SDK, and PhoneGap. I will describe how to build Android apps from the command line with PhoneGap and from the GUI with Eclipse and PhoneGap and how to test them in an Android emulator and on a real Android device. PhoneGap allows you to develop your Android applications using web technologies such as HTML, CSS, and JavaScript (e.g. with JavaScript libraries such as jQuery/jQTouch), and it will turn these web apps into native Android apps (in fact, PhoneGap supports multiple platforms such as Android, iPhone, Palm, Windows Mobile, Symbian, so you can use the same sources to create apps for multiple platforms). read more...
mail this link | permapage | score:8785 | -falko, February 1, 2011

Mono-culture and the .NETwork effect

Up
vote
Down

Consider a future where Microsoft has succeeded in migrating most Windows development to the .NET framework. With the considerable power that Microsoft wields over corporate desktop computing, the success of .NET is easy to foresee.

Now, imagine for a moment that Mono, following in .NET's footsteps, is also hugely successful. Further, imagine that, in its success, Mono displaces a large portion of traditional Linux software development over the next few years.

I believe that if the above scenario becomes reality it could lead to a disaster for Linux. In such a future, Microsoft would have tremendous leverage over Linux, Linux programmers, and businesses using Linux.

Microsoft can, at a carefully selected time, change key interfaces, sue for patent infringement, and release otherwise standard .NET components that break or obsolete pieces of Mono. They can also use the powers of the DMCA to prevent Mono developers from gaining access to obfuscated components of .NET technology. While hobbyists and Linux-centric companies will be able to withstand such inconveniences (with the possible exception of patent suits, of course), general businesses and organizations will not be able to resist such pressure.

Of course, Microsoft is well aware of how this scenario could unfold and has thought of many more exploitable details than a casual observer such as myself.

Mono, if successful, is a gift from heaven to Microsoft that, when the timing is right, can be used to set Linux deployment back years, or worse, depending on the devastating psychological and economic effects such a maneuver would have on Linux developers and businesses.

For Microsoft, their best strategy to do real damage to Linux is to make it easy for Mono to succeed while carefully laying their traps. They can quietly go about the business of patenting all of the key functions of .NET. Anyone who has followed the trend of software patents must realize that Microsoft could have dozens of patent claims covering .NET before Mono rises to prominence.

Then, Microsoft need only wait. The optimum time to shut down Mono will be after much Linux development has committed to it. By then, Mono technology will have infected many projects. Perhaps worse, it will be easier for Mono programmers to simply switch platforms and become Windows developers rather than learn alternative methods and tools of Linux development. Programmers have to eat and software development houses must pay the bills. In such a scenario, there is not a year to burn while everyone ramps up their skills with new tools and practices.

Meanwhile, businesses will be forced to abandon any Linux packages that are .NET-encumbered. Since a .NET version of each Mono-based program would already exist, it would take only a few such packages to convince a business to migrate off of Linux. The headaches of replacing such packages under Linux need only exceed the alternative headache of simply switching to Windows.

A company with their own custom Mono-based software would have fewer options. Microsoft, however, would likely provide an easy solution; simply move the Mono software to .NET and it will all be legal.

I am not the first person to have thought about this. Several Slashdot users have posted cautionary messages about developers placing their trust in the good intentions of Microsoft. [1, 2, 3, 4, and 5].

Dave Winer also seems to wonder about Microsoft's oddly open behavior:
The first clue should be that Microsoft is not protecting the source of .NET, in fact they're publishing it, with some constraints, but if you want to see how they do it, they say there will be no mysteries and no poison pills. So they're making it not impossible to clone. Why are they being so generous? (A little sarcasm, sorry.)
Even Miguel de Icaza1, the founder of the Mono project, acknowledges the compatibility hazards:
If Microsoft decided to make our life really hard in terms of compatibility, it would also hurt its own customers. If it changes the APIs, that affects its customers as well. So I think the APIs will remain fairly stable, and I hope that Microsoft won't go into proprietary protocols or protocols that would make it really hard for us to implement Mono. There's is always the possibility it will do so. Microsoft has some strange patterns in terms of how it competes. I really hope it will "behave like a good citizen," as Steve Ballmer said recently it would.
What I've described here is probably a worst-case scenario; in all likelihood Mono will not be so successful as to cause a large problem for Linux if and when Microsoft decides to kill it. However, even in a favorable sequence of events, Microsoft will still hold the power to cause a large amount of open source effort and code to be lost.

1. Miguel rebuts one of my points here.
mail this link | permapage | score:8784 | -Ray, October 13, 2003 (Updated: October 14, 2003)

Open source Cloud Computing with PHP and MySQL

Up
vote
Down

In this article you will learn how Aptana makes it easy to develop applications based on PHP and MySQL, and how to deploy them to the cloud. Also explore some of the critical design differences between a cloud application and a traditional N-tier application. read more...
permapage | score:8781 | -solrac, May 18, 2009

Compile Crystal Space in Ubuntu 10.04

Up
vote
Down

If you are a budding game developer, there is a wide selection of 3D engines that you can use to get your ideas off the ground. The first step when using a 3D engine (or any library distributed as source code) is to compile it. Crystal Space is no different. The steps below will show you how to get Crystal Space up and running on your Ubuntu PC. read more...
permapage | score:8780 | -mcasperson, July 2, 2010

Scripting: Bash Array Tutorial

Up
vote
Down

An excellent introduction to bash arrays including 15 examples...
$ cat arraymanip.sh
#! /bin/bash
Unix[0]='Debian'
Unix[1]='Red hat'
Unix[2]='Ubuntu'
Unix[3]='Suse'

echo ${Unix[1]}

$./arraymanip.sh
Red hat
read more...
permapage | score:8776 | -Ray, June 7, 2010

String matching in regular expressions

Up
vote
Down

Use parentheses to create the string matches you need in regular expressions. Parentheses allows you to use pipes for multiple matches. read more...
permapage | score:8762 | -aweber, September 12, 2011

The Real Microsoft Monopoly

Up
vote
Down

The courts have ruled that Microsoft holds a monopoly position in Intel PC Operating Systems. Business users have long been aware of Microsoft's lock on office productivity applications that require them to use MS Office in order to remain compatible with their business partners and customers. And web-surfing users are now using Internet Explorer in a ratio of about 8:1 over alternative browsers.

But one aspect of Microsoft's monopoly is more fundamental than any of those; the investment in skill, experience, training, and tools of Windows software developers themselves.

Those programmers, who have logged many long sessions of coding for the Windows environments, and with their deep immersion in its assumptions, tools, and API's, represent millions of person-years of Microsoft assets.

For years it has been a difficult decision for a professional developer to choose an environment other than Windows. The scale of that market dwarfs its competitors and opens to developers many more specialty markets than any alternative platform. Further, the sheer size of the Windows installed base is seen as a hedge against market change. Windows is perceived as a platform that will be with us for a long time to come.

Because it can take years of effort to reach the highest levels of productivity in a complex development environment, Windows-specialized programmers have, through economic necessity, been unable to switch to a different platform. With a large majority of developers writing code for Windows, the continued dominance of Windows applications was also assured. The monopoly was elegantly self-perpetuating.

Many companies, failing to appreciate the depth of Microsoft's monopoly and its determination to defend it, squandered valuable resources probing Microsoft's markets for an opportunity. After several spectacular failures, it seemed nearly impossible for such a locked market to break free of this cycle.

It seemed impossible, that is, until recently. Windows is no longer leading the growth curve among operating systems. The near perfect seal at the margins of the monopoly, it turns out, is only effective against competitors with a requirement to make money.

While Microsoft once made the fending off of mighty IBM look easy, the Linux phenomenon presents a very different kind of challenge. It needs no profits, corporate partnerships, or investors in order to succeed. Linux depends only on hobbyists' passion for programming and their self-imposed standards of quality in their own work. Further, the Linux community seems to draw motivation from its dissatisfaction with the computing landscape that Microsoft has created.

This noncorporate juggernaut has grown so large that it is spilling into commercial markets on many fronts. Now, with the additional support of several large corporations, the expansion rate of Linux could actually accelerate.

Much of the continued growth of Linux will come at the expense of Microsoft. Others will lose business along the way, of course, but the ubiquitous presense of Microsoft astride the market presents many targets that are simply too broad to miss.

Unfortunately for Windows programmers, at some point the rapid growth of Linux will force the saturated Windows market to start shrinking. Soon thereafter, the seller's market for Windows programming services will become a buyer's market -- and pay scales will begin to drop. Although the computer industry has experienced many of these disruptions in the past as new competition entered the market, this will be the largest such contraction by far.

Confidence in the impenetrable market lock of MS Windows is slowly fading. Some years from now when this trend reversal is complete and documented, we will look back to a single turning point to call the end of Windows' dominance. I'm making my pick a little prematurely. I think the critical point was IBM's decision to support and invest heavily in Linux.
mail this link | permapage | score:8758 | -Ray, July 9, 2001 (Updated: April 18, 2007)

Java J2EE Tutorial: Secret Santa Web Application

Up
vote
Down

In the spirit of the season, Santa's helper Merlin Hughes, who doubles in real life as a Java developer, presents the design and implementation of a J2EE-based secret Santa Web application, along with a discussion of the tools and technologies that can be used to ease the development of such applications. The articles provide a broad overview of how to build a J2EE application from the ground up, using some modern tools and frameworks, with details of how these different technologies work together to produce the end result. While not intended as detailed treatises on any individual technology, these articles instead serve as guides to developing a Web application with J2EE. This first article focuses on the beans, their design and implementation, and the use of XDoclet to accelerate their development and deployment.

Part 1: The beans
Part 2: The controller
Part 3: The view read more...
mail this link | permapage | score:8758 | -solrac, December 19, 2003

Linux Kernel Debugging Tools

Up
vote
Down

Your Kernel just crashed or one of your drive is not working!! What do you do?

Well, this article gives an introduction to some kernel debugging tools for Linux. These tools makes the kernel internals more transparent. These tools help you to trace the kernel execution process and examine its memory and data structures.

The tools discussed here are :

1. Kernel debugger, kdb

2. Kernel GNU debugger, kgdb

3. GNU debugger, gdb

4. JTAG- based debuggers.

Of the mentioned tools, the kdb and kgdb were introduced as patches to the kernel code. The plain debugger gdb doesn’t need the patching process with kernel code. The JTAG (Joint Test Action Group) based debuggers are hardware assisted and powerful tools, but are expensive.

Here I will explain the installation and usage of the kdb tool. The rest of the tools are briefed. read more...
mail this link | permapage | score:8756 | -shyju, November 15, 2008

Tutorial: Creating graphics with PHP

Up
vote
Down

Imagine creating Web-page graphics dynamically using just code. Creating and manipulating images is yours for the doing with the power of PHP. This tutorial steps through using the GD library, showing you how to create and alter images on Web pages. It starts with the GD construct, and then builds on it to showcase graphics techniques. read more...
permapage | score:8712 | -jmalasko, July 8, 2008
More coding articles...
Abstract Art Prints by Ray Yeargin

coding headlines

Review: DevelopGo: A Linux Live CD for Programmers

Tutorial: Build a C/C++ memory manager

The life cycle of a programmer

Install WebSphere MQ on Linux

Import XML into OpenOffice Calc with XSLT

Awk Tips, Tricks and Pitfalls

Comparison: Zend PHP vs. Symfony vs. CakePHP

I wrote my first programming e-book: Awk One-Liners Explained

Linux Debugging Tools for C

Free download: C/C++ Eclipse Plugin

Debugging Shell Scripts

Create native looking Firefox web apps

Scripts for custom Linux distributions

Java: Real numbers

Scripting: Bash floating point

Tutorial: Write your own operating system

bind()... listen()... accept(): The Unix Socket FAQ

Tutorial: MySQL Select statement

Tutorial: Build a grid application using Python

Tutorial: Install the Aptana AJAX IDE on Ubuntu

BASIC for Linux

Programming Language Tradeoffs: 3GL vs 4GL

Bash Functions

GDB and SSH Tunneling

Tutorial: Multithreaded Programming with pthreads

PowerPC assembly language

Beginner and Intermediate / Advanced SQL Tutorials

C Programming Tutorials

Book Review: Invent Your Own Computer Games with Python, 2nd Ed.

Vim Plugins: ragtag.vim

Evaluating Eclipse vs. IntelliJ IDEA

sed and awk tips

OS Development Tutorials

Introduction to Java programming

Vim plugins: snipmate.vim

Tutorial: Embed Python in Apache2 with mod_python on Linux

Tutorial: Install and test C, C++ Compilers in Ubuntu

Tutorial: Build a Real-Time web tool with jQuery, XMPP and PHP

Apache Derby Tutorial

More CommandLineFu One-Liners Explained

 

Firefox sidebar

Site map

Site info

News feed

Features

Login
(to post)

Search

 
Articles are owned by their authors.   © 2000-2012 Ray Yeargin