FreeBSD is prepared to the next OSSE?

[cpm@]

After read a lot of posts we can count the exact number of accusers about the ancient FreeBSD's potenciality. My free question about this is summarized in the topic's thread. I hope that members opinions can help to do a formal analysis and find a unitary perspective. And incidentally help to clear up the question of how to continue the Project, because FreeBSD is not dying.

My starting point is based in a thesis presented by Doctor of Philosophy in Computer Science, Jingwei Wu, who says in the Abstract:

An evolving software system responds to external events (eg, new functional requirements) According To Self-Organized Criticality (SOC) . The SOC dynamics is characterized by the following: (1) the probability distribution of change sizes is a power law, and (2) the time series of change exhibits long range correlations with power law behavior. We present empirical evidence SOC that occurs in open source software systems.

All this is pure philosophical motivation but is a good support for the arduous task ahead for FreeBSD to regain market share in this world, where information is a fundamental part of our development individually and then in groups.

All comments (pros/cons formulated in detail) are welcome.

 

[sossego]

I'm just a few pages into the article.

The Linux model seems to be going the way of divergent evolution- not the kernel itself, but the individual projects. Even though one could observe the benefits from such, people seem to forget that there are laws; or, in this case, we are bound by licensing, economics, and human desire.

Added: What is it with the i386/AMD64 dependency in computing? One would think that someone would have done this with RISC or another architecture type.

Did he ever consider comparing different systems and codes with the exact same process? Has he considered the clang, pcc, llvm, and others?

 

[cpm@]

I'm agree with your assertions but I think we can do better unified proposals between people that are interested in stop blaming actual state of the project and learn how works and what can do FreeBSD. We still need find how to make correct arguments based in skills learned with our practices. Understand how work things is one favour point. Is very important motivate all new members for this subject

This is a brief summary of my modest review, of course.

FreeBSD Foundation Activities approvals for this year until october. Can be interesting avoid privatization of this movements with the consumer participation. If that is possible then the FBSDF can avoid problems, they need convince first to community stakeholders, that should be the majority: motivation, implication and instruction like tools to teach future developers. Is stupid be less competitive because missing internal agreements.

 

[sossego]

The other question to bring up is whether or not he used a GDE or went for the straight terminal session.

 

[cpm@]

I am in favor of using the terminal session. Not only because of its history: the first developed for UNIX shell, sh(1), Bourne Shell was called after the name of the person who led the team that wrote it, Steve Bourne. California University significantly improved Bourne shell to create csh(1) (California shell). The new features offered California shell that had no Bourne shell (history, aliases, possibilities for writing shell programs more versatile, etc.), but it has two drawbacks: it is not standard and has problems with the Bourne shell programs. Later, David Korn of Bell Laboratory, developed a new shell, ksh(1) (Korn Shell) which incorporated the best features of previous shell and is also fully compatible with Bourne shell. The Free Software Foundation developed bash(1), based on the previous shells. The "TC" shell, tcsh(1) is freely available and based on csh. It has many additional features to make interactive use more convenient. POSIX 1003.2 Shell Standard committees worked over the Bourne shell and added many features of the Korn shell and C shell to define a standard set of features which all compliant shells must have. Finally zsh(1) shell, a freeware functional clone of sh, with parts of ksh, bash and full POSIX compliance, and many new interactive command-line editing features. It was installed as the default shell on early MacOSX systems.

Also is even possible for a user with adequate knowledge of the system to write your own.

Also read Magnus Johhanson. (2005). "Lab 1: Write a UNIX shell".

 

[cpm@]

As the document states elaborated by Jingwei Wu:

The laws of software evolution formulated by Lehman represent a major intellectual contribution to understanding software evolution dynamics (an underlying cause of change or growth). Lehman’s eight laws are empirically grounded on observing how closed source industrial software systems such as IBM OS/360 were developed and maintained within a single company using conventional management techniques. As summarized, the laws suggest that software systems must be continually changed in response to external forces such as new functional requirements and hardware upgrade. Outside the field of software evolution, a wealth of knowledge has been gained in understanding the change behavior of complex systems as diverse as sandpiles, power blackouts, earthquakes and even biological evolution. These systems are complex in the sense that no single characteristic size can control their changes (responses) over time. In other words, changes of any size can occur. For example, a power blackout may strike a street, a city, a state and all the way up to a country. The simplifying aspect of these systems is that their statistical properties can be measured as power laws in space and in time.

An interesting view about why software development is slow:

Basically, when a piece of software is released, it is filled with bugs and changes to be made. Then the software enters a period of fixes, where it becomes more functional while having less bugs. However, at some point the software becomes so complex that the number of unforeseeable bugs begins to outweigh the fixing power of a patch or new version.

This point where the new bugs start to outweigh the fixes marks a point which large software projects cannot recover from. According to the 'law', it requires a complete rewrite/redesign of the program to accommodate the new features and requirements the software is expected to fulfill, without being filled with errors. I'll also note that this is not something that is due to 'bad programming', and has exceptions (such as projects that are small enough to be maintained by a single person).

Recommended read Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution".

 

[m6tt]

I entirely agree that software like all systems is subject to effects that are evolutionary (i.e. punctuated equilibrium).

That actually summons some interesting metaphors. Evolutionary organisms exhibit a number of different strategies for adaptation...such as R selection (make lots of babies and hope they make it) and K selection (make a really good baby and protect it). Each strategy works fine in most conditions, but has additional advantages in other conditions.

I wonder if perhaps open source software is similar. The bazaar model gets hardware support fast, but individual projects languish or end up incomplete. For that model, it doesn't matter, the parts can be cannibalized and reorganized into new projects. Amongst the sea of projects, great projects will thrive and poor projects will languish or be cannibalized.

The cathedral model is slower, it doesn't seize new territory quickly, but it may be more resilient to the "law" you mentioned, as structural corruption and confusion is ideally prevented due to the centralized model. Granted, things do need to get refactored, but aren't restructured as often.

A perfect example would be the init script systems of FreeBSD vs Linux distributions. FreeBSD's init system has changed only slightly in comparison to the current Linux situation of multiple competing (and sometimes buggy) init systems.

Which is better? Neither. Linux benefits from the diversity (after the cambrian explosion dies off, of course...looking at you, systemd). FreeBSD benefits from the successful reliability of its system.

I think ultimately we are really on the very edge of a new era. The philosophy of computer science should be a business of laying a groundwork...much will change over the next ten years, let alone one hundred.