Slashdot Mirror
Amiga Sells AmigaOS
rocketjam writes "Amiga, Inc. announced today that it has sold the Amiga Operating System to KMOS, Inc., a corporation which 'develops and distributes enabling technology.' The deal included 'all of Amiga's right, title, source code, and all versions, from the "Classic Amiga Operating System" through AmigaOS 4.0 and all subsequent versions.' A spokesman said the sale would have no adverse affect on the release of a consumer version of AmigaOS 4.0 later this year. Amiga said it made the move in order to focus on the growing mobile market. The long saga of AmigaOS 4.0 continues."
Reader Da writes "there're always other options should the Amiga curse continue. Also mentioned on OSNews."
As for doing "great things with the OS", while Amiga OS still have some great features, you'd be much better off adding [insert favorite AmigaOS feature here] to existing open source software. The Amiga OS as most of us know it was very intimately tied to an architecture without memory protection for instance, which doesn't really make it easy to bring up to date.
That said, if you want "open source Amiga OS", take a look at AROS. Aaron Digulla and a few other people have done a great job at writing replacements for almost all parts of Amiga OS, and you can run it under Linux (or stand alone if you prefer).
Nope, Linus learnt to program on a Vic-20, and later a Sinclair QL.
Kernel guru Alan Cox is a former Amiga hacker however...
This deal has already happend in April 2003!
Great information politics, Amiga Inc...!
Their only capital is the trust of some spirited, hard core nostalgians. These politics trash this completely..
rpp3po
Ok, I'll bite
And I'll bite back:
- Datatypes (OS standard way of loading files in any format): From a user point of view, you can add support for a new file format to all your programs by installing a small file. From a developer point of view, you can add support for all OS supported file formats just by using this functionality. On Windows, I having to code support for simple things like BMP/PCX myself, or rely on 3rd party libraries (which means abiding by their licence, and supplying large DLLs with my programs).
- Decent GUI toolkit in the form of MUI (yes, it wasn't OS standard, but until MUI is ported elsewhere, it's exclusive to AmigaOS - though I have a feeling that the OS standard Reaction toolkit seems to work similarly): This is programming GUIs the way it should be - just say you want, eg, three objects in a row, and let the toolkit worrying about resizing; it's actually easier than programming with so-called "visual" editors, and has the advantage that windows/GUIs are always automatically resizable, so you don't have to worry about that (similarly you don't have to worry about things like changing font sizes). It's ridiculous that some GUIs are still written with hardcoded x/y coordinates.
- A side benefit of having decent GUI toolkits (MUI and others) for the user is that it's very common that windows are resizable as standard, and the contents resize to fit. There's nothing more enfuriating to see a tiny window on Windows with a small textbox or whatever inside, and I can't resize if (or instead, I can resize it, but the contents don't enlarge!)
- Assigns: Shortcuts basically. Windows only gets halfway with its shortcut - I can't include the shortcut in a filename, I can only use the shortcut on its own (eg, c:\shortcut\dir_inside_shortcut) - was this fixed in XP?
- ARexx: OS standard scripting language. It wasn't anything special in itself, but it was OS standard, so commonly supported by most applications. Which means you don't have to learn different scripting languages to support different applications.
- Screens: Multiple workspaces, done dynamically. Why do OSes like BeOS (and Linux window managers?) bother to implement workspaces, but then only stick with a fixed number?
Just a few off the top of my head. Also there are things which aren't exclusive to AmigaOS, but are still improvements over Windows (and since I use Windows, it still counts as features that one might miss):
- Doesn't make GUI mistakes that Windows does: It's much quicker to find menus at the top of the screen, and using the right mouse button means you can select (or unselect) multiple options with the left button, without opening the menu several times.
- Decent command line interface: I don't mean the commands/syntax, but things like being able to resize it, having a non-fixed number of lines (I can't believe I'm still having to tell Windows how many lines I want by buffer to be - did they fix this in XP?)
And not quite an OS feature, but I still miss the email client YAM.
Of course, if you wanted more than the SDK (Lattice C, for instance, or membership of their developer network - literally a network, based around UUCP) then the costs went up. But just getting the SDK, to plug into your favourite C compiler (eg Matt Dillon's), wasn't that bad. And the SDK was excellent, included complete documentation, an abundance of examples, etc, etc.
You are not alone. This is not normal. None of this is normal.
No, no. Quite different to symlinks, but can be used in a similar fashion, sort of. Devices on the system have a device name and (for drives) a volume name. The device can be accessed using by using either name, followed by a colon. If you accessed a device that didn't exist, a requester would pop-up asking you to insert that volume in any drive. In this way you could name floppies/CDs/whatever and access files across the system using the volume name, causing it to ask you for the relevant disc/disk when necessary.
An assign is like a virtual volume name. You could assign a name to a folder (or drive, or device), and access that folder through its assign name followed by a colon. If your program accessed everything through the assign, and it hadn't been assigned, it would ask you to insert the volume (as the name might be a removable drive). So you could copy all of your floppies to your hard drive, and assign their volume names to the same folder. They would then be accessed transparently. The system doesn't actually care where the file is, as long as it finds it via <drive/volume/assign>:<path>/<filename>
Another good thing is that if it couldn't find a volume, it would pop-up the requester asking for it, at which point you could open a shell and assign that name to a folder containing the file you wanted, then hit retry. It would carry on as if nothing happened.
There were other uses you could put them to, but the above example is the most common use.Assigns fit into the overall design of the system very well. I do miss them a lot.