Why n*x

Up front cast iron specs don't work. Look at any government project for evidence of that

Can not argue that. That is the reason that it is only designed down to the module level, and beyond that is implementation time design. The agree on interface for a procedure rule is at implementation and needed, if the interface to a procedure changes after it is being called from many others you break it. And the first version is only the first version. With most mid sized projects following my rules the first version takes about one month. Larger projects, it depends on the project. Part of the idea is to keep the first version so simple that it can be completed in a short period. In practice the v1.0.0 mentioned in my rules (written when I was 13 years old) is actually v0.0.1, and then is revised many times.

In honor of USA Father's Day, a quote from Mark Twain:

When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished by how much he'd learned in seven years.

Up front cast iron specs /can/ work. All you need is a situation where the requirements don't change before delivery of a particular version.

Up front cast iron specs /can/ work. All you need is a situation where the requirements don't change before delivery of a particular version.

Well if the requirements change, that is another version .
As long as the software engineer always remembers that the implementation of any module/procedure can change (so long as the interface does NOT change).

The main thing is Optimize, Debug, Optimize, Debug, Debug, debug. And of course; never rely on code written by another to be well debugged or optimized (even if it is just a standard library).

And I forgot: Always know that even after you go to extremes in debugging, there will always be bugs left to find, so be willing to fix them once they are found. Know as well, that no matter how well you have optimized your code, it can always be better optimized, so always be ready to further optimize once you figure out a better way to implement something.

Up front cast iron specs /can/ work. All you need is a situation where the requirements don't change before delivery of a particular version.

So you only have 5 minutes from receiving the spec to release?

TL;DR

Why n*x? Because it works (for the best (but not all) definitions of "works"). Apologies if anyone already answered this

Nothing more to see here. Move along, move along...

Up front cast iron specs /can/ work. All you need is a situation where the requirements don't change before delivery of a particular version.

So you only have 5 minutes from receiving the spec to release?

I know where you're coming from (often you have ~5 minutes from getting client signoff on the requirements), but it rather depends on the field you're working in. For instance way back in the dim and distant past, I worked for a major high street bank writing software for their cashpoint network. We worked to totally ironclad specs, and the only time we ever broke anything (in fact, I personally took down cashpoint for the weekend, oops) was due to some enforced "cowboy coding" at the last minute. Likewise when I was working for 'the' major UK airline's engineering department. Because lives are worth something. And the stock market. And the financial futures exchange. Yes, requirements change, but in many cases you know about it well in advance.

Simon

no matter how well you have optimized your code, it can always be better optimized, so always be ready to further optimize once you figure out a better way to implement something.

IMHO it depends if there's a need for optimizing the code (e.g. frame-rate in a game) or if you're just optimising for the sake of optimising. The latter can be counter-productive e.g. by making the code harder to understand, or introducing subtle side-effect bugs.

Also I should note that the problem sited at the start of this thread is not n*x in and of itself, though rather the bloated variants that we currently have. Unfortunately creating another n*x is just an invite to port all the bloat to another n*x.

If you define what limitations you're willing to put up with, you can strip out a lot of the 'bloat'. Look at http://distro.ibiblio.org/tinycorelinux/ for an example.

Being realistic, do you realy think that KDE or GNOME is easier to use than GEM?

Ermm, hands up all those that have used GEM?
Should business users still be using Windows3.1 instead of Windows7? (sorry, cheap jibe)

[jamesh]

If people really want specs more than 3 days before some vital deadline, I suggest they never work for Samsung.

Should business users still be using Windows3.1 instead of Windows7? (sorry, cheap jibe)

No, they should be using Windows 2000, which is the only version of Windows I ever liked. It's all been downhill since then IMO.

Up front cast iron specs don't work. Look at any government project for evidence of that

Or is it "Large government projects" don't work ? ^^

Up front cast iron specs don't work. Look at any government project for evidence of that

Or is it "Large government projects" don't work ? ^^

In order for government projects to work you would need public servants that work.

Find the mistake.

I'm going to ignore everything else said so far because its going over my head a little now (and I only got half way through page 3).

Why n*x?
Because it works, sure its bloated but theres nothing preventing someone from stripping the bloat off for a dedicated rasberry pi OS (or just a generic lightweight linux kernel), can probably be done.

Why write your own?
Its educational, some find it fun, and wasn't linux made for no particular reason. There may be a 99% chance of this failing but theres still that 1% chance of something revolutionary coming out of it. One of the things I wanted to do with my pi (when I can afford one, yes I said that) was write an OS (I have some limited assembly experience). I've now decided that actually thats a bad idea because my assembly skills are probably too limited, kinda looking at the Cosmos project instead, arm support is planned eventually but they have other things to deal with currently.

OP:
I wish you the best of luck in this endeavor, even if its just a bootable command line not a nix killer it will still be awesome that someone has booted their own code on the pi.

It has been a while since I have loked at this thread. Havin had my RPi now for ony a few days, I have been workng on finnishing up my OS, There are things that needed to be added, and moified that were found during testing on real HW. I had not yet implemented a USB driver, though had created an interface specification for the KB & mouse Drivers. I am thankfull for the Chadderz CSUD USB Driver, that I have modified for my OS. Hopefully soon I will have my OS running simi-stable. And I have decided once it works I will release it as a pre-alpa. Thankfully I whas able to do most of the development using a simple homebrewed emulator.

Though I am now begging to learn a bit about programming the VdeoCore IV processors, and as such will likely be making some significant changes to parts of my operating system after I get it woking completely in ARM code.

Also this thread caused me to reevaluate the wording of the rules of programming that I had written. I do see that 1: They are misseading and 2: They apear to mention absolutes where things are not absolute and 3: They appear to be applied to a final project, though they are intended for small sections of a project (the little chunks that you can do in a few hours). and 4: they neglect to mention that a given portion may, later, need to be completely redisigned.