What lessons from the amiga OS are applicable today?

[lsmart]

While I sure like the features listed in this thread, I understood the question in a differnt way.

My lessons ´d be:

1) A friendly and helpful team can produce great work. You don´t have to be elitist to win.
2) If you have a lot of cool public domain software, you will grow your user base.
3) A single man can write a better programm than a huge company.
4) Most business computers and software is a complete waste of money.
5) A killer game machine is really a killer machine for almost every task.
6) look at the low end to decide where to place your defaults.

[Digiman]

AMIGA = 100mph Go-Kart......Windows 7 = 150mph Articulated Lorry. Sure it's faster but handles like crap

+1

[Speelgoedmannetje]

DOS had power and configuration..  (I still prefer INI files to registry entries or (God Forbid) XML config files..)

Urgh, I thoroughly hate INI files. XML config files should be the way but I agree it would be a pain to edit them. A good intuitive ascii xml editor available in CLI (AmigaOS/Windows/Linux) would be nice. An editor that can prevent unnecessary typos (in an int field not being able to type in non-decimals, for instance). INI files are just so 70s you know...

But the Amiga proved that you could provide both and make almost every user happy.
-cut-
OH YEAH!!  The RAM disk!!!  LOVE the RAM disk!!!  :-)

Amen to that!

[Speelgoedmannetje]

What about the snapshot ability? I'm kinda getting tired of OSs wrongly guessing where I want my windows to be when they open.

No program whatsoever should guess. I regard it as a design failure.

[Fester]

Philosophically speaking, it showed me that if you're counting the length of the college cafeteria using a tape measure, while everybody else is using a celery as a measuring stick, sooner or later, you'll have come down to a single celery stick too. And they'll cut it in half if you're going too fast.

But really, in 1989, that's how it felt when you had an Amiga at home and were forced to work on some sort of IBM compatible at school.

Windows is good enough for me nowadays, but the Amiga tought me to look over the cube wall so-to-speak.

[wiser3]

A GUI that always immediately reacts to it's user. On an Amiga any time you clicked something you immediately got a visual indication of the click, icon image change, button change, etc... The GUI even changed if the task was going to take a while to operate.

With a certain PC OS, half the time you click and see nothing change so you click again only to then get two of whatever you opened.

[vidarh]

No monitors can switch resolutions on the same frame.

That's a brave claim to make on an Amiga forum.

[Khephren]

While I sure like the features listed in this thread, I understood the question in a differnt way.

1) A friendly and helpful team can produce great work. You don´t have to be elitist to win.
2) If you have a lot of cool public domain software, you will grow your user base.
3) A single man can write a better programm than a huge company.
4) Most business computers and software is a complete waste of money.
5) A killer game machine is really a killer machine for almost every task.
6) look at the low end to decide where to place your defaults.

Ilike your interpretation. 3 and 5 especially.

[desiv]

Urgh, I thoroughly hate INI files. XML config files should be the way

Yes, of course something like this:

 
    /path/to/*Test.php files
    /path/to/MyTest.php
 


Is much better than 1 line in a file that says:

testsuite=/path/to/Test.php

Not to mention the extra K's of code needed to parse that..
:griping: :griping:  :roflmao:

I prefer simple (it suits me.. ;-) and tighter code when possible.

I REALLY hate XML log files!!!! (Yes, I'm looking at you OpenFire!!)
I can no longer just "grep" for something, I need an XML parser!!!

(No, the above emotion is NOT an XML statement!!!)

desiv

And I totally agree about "assign"..  Man that's slick!!  Even better than "ln".  Not sure why no one has stolen that yet..

[Karlos]

XML is fine when it is used for what it was intended, defining document/data structures and relatively simple data interchange. Unfortunately, a generation of developers who grew up after anybody still knew what a CPU was, let alone how to design/write efficient code of any sort have embraced it as the answer to every class of data storage / parsing problem.

[kevh100]

I've always wished for the whole ENV: & ENVARC: thing in Windows / Linux.

It's nice to test changes in a temporary fashion without commiting them to the registry or home folder. A quick reboot and the size 30 Opal as your main font making your windows too big to change back was gone. I know in modern OSs you wouldn't want to reboot after every minor change but a simple "reset to stored settings" option would be nice.

I also liked how you could back up all of your settings just by copying the envarc folder to a different location and imporrt them back after a reinstall.

The Linux way is better that the horror that is the Windows registry but I think it's messy having loads of .blah folders in your home directory that can quickly fill any selection dialogue windows you have open.

The general structure of the OS was easy to learn and understand too. C: Libs: etc etc all made good sense and are far less confusing that Windows or Linux.

[NorthWay]

A million small things, but the main ones

- An OS designed around sharing structures. That can clash violently with modern safety and stability standards. The only ones looking into it today are the SASOS crowd.

- Libraries done right (at least in the Exec setting). Not being dependent on a specific version or placement as long as it is available and the version is high enough.

- Datatypes. The implementation might not support streaming and similar, but the idea is so right. In Linux land there is not really anybody who can declare that a component so high up in the stack is a standard component.

- Media naming&handling. Not having the physical unit, but the media mounted as your action target. Doesn't make as much difference today when you move less media around.

- Handlers. Ties in with previous point, but makes for programmable media interfaces. Like the text editor that exports the open files and lets your compiler load the file straight from memory. They missed the boat on not making and defining STDIN: STDOUT: and STDERR: though.

And then there is the reverse lessons about what not to do
- Make clear what it does not and can not do.  All the safety and stability issues you have for multiuser, bulletproof, nonhackable has been known since the 60s. So either make room for _everything_ or declare where the end of the road is before you start.
- Printing needs a strategy. Preferably a good one.

[Speelgoedmannetje]

Yes, of course something like this:

 
    /path/to/*Test.php files
    /path/to/MyTest.php
 


Is much better than 1 line in a file that says:

testsuite=/path/to/Test.php

Not to mention the extra K's of code needed to parse that..
:griping: :griping:  :roflmao:

I prefer simple (it suits me.. ;-) and tighter code when possible.

Fact is, if things get a bit more complicated, which it more often than not does, maintaining .ini files will become a pain, especially when you made a typo.
I've lost many hours in vain finding some silly typos in linux configuration files. :S
My point was more in the direction of instead of a text editor, using a dedicated configuration editor which makes input easier and let you edit values and metadata seperately as human.
(and a generally available parser as library on the software side)
And considering XML being too resource-hungry, well, it's true. And that's the reason why I actually use JSON, so think JSON instead of XML then for the heck of it.
XML is what everyone knows and understands.
I didn't mention performance issues with XML either because configurations are being read only once during application startup and generally aren't that big to notice the performance hit even on an Amiga 500.
Btw., log files in XML are a VERY bad idea indeed as extensive logging actually CAN slow your application considerably, and make unnecessary big files.

[vidarh]

The Linux way is better that the horror that is the Windows registry but I think it's messy having loads of .blah folders in your home directory that can quickly fill any selection dialogue windows you have open.

Linux is (slowly) moving towards a single directory (per user) with config data too, with the XDG Base Directory spec. Tons of apps still don't support it, though, and many probably never will because the dot-file in home-directory approach is so entrenched.

[vidarh]

Yes, of course something like this:

 
    /path/to/*Test.php files
    /path/to/MyTest.php
 


Is much better than 1 line in a file that says:

testsuite=/path/to/Test.php

Of course, the much more equivalent version of that would be /path/to/Test.php or .

and tighter code when possible.

"Where possible" being the key. The moment your config gets complicated enough to do stuff like your example, ini files becomes a total pain.

I REALLY hate XML log files!!!! (Yes, I'm looking at you OpenFire!!)
I can no longer just "grep" for something, I need an XML parser!!!

Agreed, sort of. There's no problems creating log files that are almost valid-XML ("almost", because the lack of a single properly closed root tag is a problem with using XML for any "stream" type format) while also being easily "grepable", though - just keep it all on one line and regularly formatted. But I don't see the point over just a cleanly separated file. Though most text log-file formats are created by brain-dead developers... How hard is it to make something with uniform field separators so it's trivial to manipulate with things like AWK without writing regular expressions? (that's a rhetorical question, in case anyone wonders).