What lessons from the amiga OS are applicable today?

[vidarh]

The most unique feature of Amigaos that i can think of that noone else has got is screen dragging

The multi-resolution screen dragging is unique, but not very useful on modern monitors. Single-resolution screen dragging exists for Linux using Enlightenment as the window manager.

[vidarh]

Are there any OSs that make use of a depth gadget, which allow the active window to stay at whatever depth the user left it at?

There's tons of window managers for X (Linux etc.) that supports it if you want to enable it. I'm not sure many of the newer ones do, though.

[vidarh]

Desiv summed a lot of it up. For myself:
Datatypes: allowing old software and the OS to use the latest formats, great idea.

This is one I'm still astounded nobody seems to try to copy.

Fits a lot on screen: seems higher resolution than it is.

This is a big deal for me on my laptop. Configuring a Linux system to use equally little space for folders is possible, but it takes a lot of work and "unusual" settings. E.g. I had to install a separate program to get Nautilus - the Gnome file manager - to use a global menu instead of littering every folder window with a menu bar, since it doesn't have an option to turn the menu bar off. And by default it opens with a side bar, location bar, status bar, menu bar *per* folder/drawer. Then you need to pick a different window theme, and a bunch of other things.

On the upside, I now have a Linux desktop with sort-of halfway Workbench functionality + Ken's icons.

DosDrivers: A great way of adding new filesystems, again, easy to understand.

Linux and OS X has FUSE which gives pretty much the same thing, but it was a very long time coming.

WBstartup: no hunting around for what the hell is bogging your comp down on startup. Check WBstarup and S: and your done.

Most other OS's have a similar solution these days...

Apart from datatypes and AREXX, one of my favourites is assigns. You can halfway copy the concept with symlinks on Linux (but not multi-assigns), and could clone it fully with FUSE (implement a filesystem for assigns), but it's not the same. And special assigns like PROGDIR: as well makes a big difference.

[vidarh]

Desiv summed a lot of it up. For myself:
Datatypes: allowing old software and the OS to use the latest formats, great idea.

This is one I'm still astounded nobody seems to try to copy.

Fits a lot on screen: seems higher resolution than it is.

This is a big deal for me on my laptop. Configuring a Linux system to use equally little space for folders is possible, but it takes a lot of work and "unusual" settings. E.g. I had to install a separate program to get Nautilus - the Gnome file manager - to use a global menu instead of littering every folder window with a menu bar, since it doesn't have an option to turn the menu bar off. And by default it opens with a side bar, location bar, status bar, menu bar *per* folder/drawer. Then you need to pick a different window theme, and a bunch of other things.

On the upside, I now have a Linux desktop with sort-of halfway Workbench functionality + Ken's icons.

DosDrivers: A great way of adding new filesystems, again, easy to understand.

Linux and OS X has FUSE (no idea if FUSE has been ported to Windows too) which gives pretty much the same thing, but it was a very long time coming.

Anyway...

Apart from datatypes and AREXX, one of my favourites is assigns. You can halfway copy the concept with symlinks on Linux (but not multi-assigns), and could clone it fully with FUSE (implement a filesystem for assigns), but it's not the same. And special assigns like PROGDIR: as well makes a big difference.

[vidarh]

You mean someone actually likes this? I thought everyone hated it! Why do you like it?

If you run with lots of windows open and want to be able to see what goes on in one window while typing something into another one, not having click-to-front is massively helpful.

Being able to easily get the window to front is useful, but so is being able to easily avoid it going to front when activating.

[vidarh]

Why isn't it useful or modern monitors? What's the difference apart from the larger screen sizes today? :confused:

Because most modern monitors *can't* switch resolutions on the same frame (many CRT monitors can take *seconds* to resync), and for LCD/LED screens it makes no sense at all since they have a single native resolution and everything else is just scaled.

The benefit in having it originally was that it saved a lot of memory to be able to run at low resolutions in cases where it made sense. These days mainstream OS's run on hardware that can rarely support less than 8GB and rarely come with less than 2GB memory, and some x86 hardware supports hundreds of GB (was looking at motherboards the other day that supports 512GB, though that's not exactly for a common desktop system...). In that situation most people aren't interested in running at lower resolutions than what their screens can handle in any case.

To do it on a modern system you'd end up mapping the different resolution screens to textures on a graphics cards and scaling them using the 3d engine in the graphics card because of the lack of monitor support, so it's not a memory or resource saving method any more. So people don't really care about the multi-resolution variation much any more.

[vidarh]

No monitors can switch resolutions on the same frame.

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

[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).