Slashdot Mirror
CEO of Amiga, Inc. Interviewed
vlangber submitted an interview with Bill McEwen about the current state of Amiga, Inc. and their plans for the future. Bill says,
"[W]e established the concept and vision of a scalable, embeddable, multi-threaded, memory protected operating system or digital environment that would run from a cell phone to a server. This is what you are going to see us deliver."
While Amiga OS4 has been in pre-release since 2004, a final release is planned for later this year.
Feels very strange to look at their web site though, somehow to me the name just doesn't click in the modern era. Here's what Commodore are doing today. As I understand it, a company bought all rights to the name and launched themselves as Commodore. Via the Retrobits podcast I heard an interview with a US salesman for them - apparently they're quite serious about the Commodore name, and want to revive the spirit and attitude of working rather than just the name.
Having read about the way Commodore worked I'm not especially certain that's a great strategy, but it'll be interesting to hear what happens.
Cheers,
Ian
For me, the Amiga philosophy was picked up more by MorphOS and Pegasos than this new so-called "Amiga".
http://www.morphos.org/index.php3
http://www.pegasosppc.com/
However, for familiarity I run linux on my pegasos box (a loaner from work, noone else uses it).
I'll fess up to being an ex Atari ST fan. I'd have bought an Amiga if I could have afforded it. It was better, just out of the reach of my limited budget.
FatPhil
Also FatPhil on SoylentNews, id 863
I have to agree with that.
This is actually a very real, very strong, case for RMS's controvertial opinions on the morality of proprietary software. Commodore/Escom's death didn't have to be the end of AmigaOS as a viable platform (it would, today, in my view be unrecognizable if it had continued to be supported, but that's another issue.) People relied upon the various owners of Amiga to provide the resources to ensure it remained usable: every single one of those owners from Gateway onwards have been failures. And all previous owners, Escom, Commodore, and Hi Torro, failed to plan for the possibility of commercial failure.
There was a movement to get AmigaOS open sourced in the late nineties. It was widely criticised by many, including those within the Amiga community, who decided that it was in some way wrong to allow Amiga technologies to become free enough that they might help bolster rival operating systems. The sheer mindlessness of that position is readily apparent after Gateway's decision to instead sell the technologies to private consortiums who had anything but freedom and openness in mind when they bought it.
Now, two years behind schedule, AmigaOS 4 is still in a state where it'll be finished "RSN". Public betas have shown no dramatic improvements over the original. It's tied to licensed PowerPC hardware because of Amiga Inc's nned for profits, a need that is opposite to the operating system's users need for future proofing and reasonable expectations of support.
AROS is no panacea, and it too has little advantage, beyond portability, over the original AmigaOS. But it at least keeps alive something. AmigaOS and AROS are beyond the point that they will ever be relevent as modern day operating systems - even on lightwieght systems, their lack of a credible security model limits their uses in a modern networked world.
The Amiga's prime purpose these days seems to be as a little noticed warning to others. If you invest your time and money into someone else's proprietary platform, even if it's the best platform there is (and, arguably, the Amigas were, for a very long time, the best platforms in existance for machines costing less than $5,000) you do stand a serious chance of being screwed over. The same lessons were apparent from the BeOS fiasco. The same lessons, learned in reverse, were apparent from the Atheos story (the developer quit, but because it was non-proprietary, others were able to pick up where he left off.)
As a "paranoid crackpot leftovers from the waning days of Amiga", I find it sad and such a waste that that's where we are.
You are not alone. This is not normal. None of this is normal.
20) Virtual folders that unify two or more real folders.
...
:-)
21) File-change notifications
22) The WINDOW: device... create and manipulate windows as files. The parameters would be passed like: open("WINDOW:0/0/400/100/Window Title"); which specifies window location, size and title. Also SPEAK: could accept parameters for voice synthesis.
23) The whole disk-based portion of the system was located under one abstract assignment, SYS:, which could point almost anywhere
24) Each filesystem had its own root. The root of the current path would be accessed with a simple colon prefix (instead of VOLNAME:). The CLI would remember previous dirs and take you back to them with 'pcd'.
25) Escape codes could be used to draw bitmaps within console windows, although this was an unintended feature.
26) DOS had pattern-expansion that at the time was between globbing and regex in richness. Pattern support, as I recall, depended on the program intentionally passing the pattern string through an AmigaDOS expansion function which returned a linked-list of files. This has the advantage of not needing 'xargs' due to fileset size; but you had to use an xarg-like utility for certain commands because they did not internally support expansion (these few commands were written for single files, so these cases were rare).
27) A Unified bitmap and scalable (Agfa) FONTS: location, and I recall that rendering functions were later unified. This was more Mac-like and way ahead of the PC (which had balkanized fonts upto Win95). The bitmap fonts could be 32-color and also animated like GIFs. The first PC OS to handle loadable font-display through GPU coprocessing (the Blitter).
28) Each filesystem was 'bisected' with the allocation map and main dir in the middle of the partition, and each new file assinged to grow on one side or the other. Supposedly this kept head thrashing minimal in certain scenarios.
29) Most commands were 're-entrant' and could be configured to pre-load and link in memory to perform as if they were internal to the CLI. Since each command was equal to the parent CLI process, no process-creation or other overhead was incurred, and it saved memory and instruction cache as well.
30) Programs (apps) were often just the main binary plus the matching "binary.info" file (which defined the icon and params). Ones needing libraries, AV data and such were simply played inside of a 'drawer' (folder) to keep everything together, so installing a program often meant copying its folder onto your HD (wherever you liked) and install wizards were kindof rare.
31) CLI escaping and quoting were powerful but very clean, and much less likely (IMO) than bash to lead to misleading code (especially when pattern expansion was in the mix). Adoption of Unix-y features was very selective, and the OS as a whole was probably more true to the everything-as-file concept than a typical Unix workstation.
32) Event-handling in the standard devices was sophisticated enough that daemons were rare.
33) The core OS (scheduler+DOS) knew the difference between a thread, shell-bound process, user-facing GUI process, a handler/driver, and something called a "commodity" which is similar in function to OSX Dashboard widgets. Many tasklist utilities would display them quite distinctly as a result, and just show the apps by default.
34) Racter: 3rd-party app that combined an Eliza-like engine with an animated 3D metalic female face (circa 1986).
35) Diga! Also about 1986, a multiplexed VT-100 app that could (with two Amigas) transfer files both ways while chatting, with resume, CRC etc.
and
42) Had both NIL: and NULL: devices that functioned differently.