There is (or was) support for serial SCSI in the specs (the target at the time was high-speed serial links such as fiber, but it would apply to links similar to serial-ata as well). Also SCSI allows for target-mode, which would allow this serial bus to be used as a very-high-speed very-local-network.
The "directory-name as a command is equivalent to cd directory-name" thing was my invention. I got tired of typing 'cd' all the time, and I was writing a unix C-shell clone (plus a lit) for the Amiga (with process control, much more rich syntax, etc, etc, etc). I then got hired by Commodore, and shelved the shell - but I put a few things like the don't-have-to-type-cd into the main shell (actually, I convinced Andy Finkel to add them; I was in charge of AmigaDOS). I also added all the hooks for user shells to replace the default shell.
I wish tcsh on Unix had the ability to obviate the need for 'cd '.
(As someone mentioned, you could also add defines for directories, both for use as commands, and for access to files associated with a program. For example, I had src: assigned to Work:Development/src, and to CD there would just type "src:". Yes, of course this can be done with alias in tcsh, but alias doesn't help with things like "src:AmigaDos", or "copy src:foo/*.c wherever". Also, yes, if you are willing to create a bunch of top-level softlinks it will mostly work the same way in Unix - but people rarely are willing to do so.
>That was the content of a warehouse that was raided by the police, thanks to tips from the secret service.
>. And you're not going to convince me that the protesters that were in that warehouse brought the lethal animals as pets, or that the chemicals/explosive were there for no reason. The only logical conclusion is that these things were intended to be used as weapons
The secret service told the police about the bus with the animals; I've heard nothing about it's being involved with the warehouse. The animals were on the bus, not in the warehouse. The animals were NOT lethal, at least not any shown to the media. Annoying, yes, frightening to those with phobias, yes, lethal, no. Also, in the local Philly papers I've heard NO mention of explosives found in the warehouse. They did detonate a "suspicious" package which was harmless (probably someone's lunch).
At this rate, by next week the protesters will have had nuclear weapons... 1/2:-)
I'm also a philly resident. "Lethal" spiders and snakes? Excuse me, but that's just plain wrong: I think the story is growing in the retelling (and due to people's phobias, and the media's being uninformed). My understanding, from listening to reports and from seeing video and identifying the animals I saw, was that there were no "lethal" spiders (they're pretty rare here in the east), and that the only snakes shown to the media were harmless boas. They also had some "deadly" skunks and (gasp) fruit flies.
I'm certain that some of the protesters are exaggerating things as far as possible, and trying to provoke the police. I'm also certain that in some cases the police have let themselves lose control and have over-reacted phyically. I'm also certain that for political reasons the police and the city have trumped up reports of problems and incidents, AND I'm certain that some demonstrators were not peaceful and did truely break the law (not just civil disobedience) (slashing tires, kicking police, etc).
Separating out which are true and which aren't is going to be tough. Don't be surprised if a judge or judges drops charges for most of them or reduces it to a minor fine, due to the confusion and lack of evidence.
As an alternative to either keeping quiet, notifying the company, or going public, I'd like to suggest this:
Notify the company/maintainers/etc. Include in the notification that it will be made public on a specific date. This gives people time to create a fix and start distributing it. One of the big problems with press-release notification is that the patch is not normally available for a day or two or week or more, so you've pointed everyone at a hole that can't be fixed for some period of time.
Now, for cases where there is a workaround or easy fix you might want to just release it, or give a short time-span before release (a day or two).
The general idea is that knowing that the information will be released is a strong incentive for the company to have a fix ready, or better yet to have started distributing the fix, either discreetly (no information on the exact exploit of the flaw) or openly.
The AOL OpenIM protocol seems to be fairly reasonably constructed. If you check it out, it does NOT open up the client (OSCAR, not TOC) interface, but instead opens up inter-server gateways based on DNS 'IMX' records ala email MX records. No relaying is allowed, and connections are semi-persistent on-demand, and callbacks are used to verify the connecting server's DNS.
Note: this means that if you're not on AOL (or using an AOL client), your IM address will be someone@somewhere.xxx. To you, AOL users will be someone@aol.com, unless your IM server sends unknown users to AOL (and then you have the issue of collisions between local usernames and AOL names - but people/servers with small userbases probably wouldn't care much).
This solution appears to open (some) IM (not all features are supported via OpenIM in the draft, and there's no guarantee that AOL will support more advanced features in their OpenIM gateways). However, it also preserves AOL's lock on it's username-space and adds inconvenience for non-AOL-IM users, encouraging them to use AOL's client.
Still, it basically puts IM on the same footing and a similar architecture to email, which is a Good Thing.
Randell
p.s. Note: in a previous life, I was one of 4 or 5 people at a company called PlayNet that wrote what later became AOL, including the original IM design. (This was in '84/85.)
Don't use mailing lists. There are all sorts of administration annoyances with that, plus it's hard or impossible to remember which groups exist.
Use internal company newsgroups. For those (few) people whom you can't allow access to the news server, or simply won't read news, add a mailnews gateway.
This gives all sorts of benefits - if you set expiration to never, you get a permanent archive of all messages, and it's searchable. Even better, new employees (or new team/project members) can review old postings without having to pester someone for their email archives (and hope that they're complete).
Newsreaders are built into Netscape, IE, and look much like email to the user. People who use separate email programs may be tougher to convert.
I was involved (peripherally) with the old (pre-web) netrek networking protocols. In order to get things to work well in the face of lag and packet loss, information was divided into critical and non-critical. Critical information was sent via TCP, non-critical (realtime positions of ships and torpedoes and shield states, etc) information was sent via a UDP port.
Realize that this was a way to avoid implementing error recovery/windowing protocols on top of UDP directly - this greatly reduced the complexity versus a "use UDP for everything" design; doubly so since the game was written originally for TCP (and still works in TCP-only mode if need be, but if you drop a packet you get to wait - bad in a realtime game).
Originally it was designed to use random ports to deal with conflicts with other programs. Obviously in these days of firewalls, etc this causes (caused) problems.
I imagine modern games are either a) using the dual TCP/UDP port trick, b) using pure UDP with their own error recovery on top of it (expensive programming-wise, and liable to bugs), c) using pure TCP and living with serious lag if a packet is dropped, or d) using dual (or more) TCP connections, each for items of differing criticality.
(PS. I ported netrek to the Amiga in '91(?), and fixed a number of portability and other errors. Last time I tried, it still worked excluding that most servers no longer list it's public key as a blessed client.)
AmigaDOS (not the AmigaOS as a whole) including the shell, FS, etc was written mostly in BCPL; but for 2.0x I rewrote the DOS in C/ASM, while retaining compatibility libraries for older BCPL executables. 3.x had no BCPL-based code in it, and I'm happy to say I never once even ran the BCPL compiler.
The Exec was written almost totally in assembler for efficiency (not that it's very big... I seem to remember that Exec was circa 16K or less). Of course, Exec didn't do all that much compared to a Unix kernel. Exec was _loosely_ based on XINU.
As for the OS and Open Source: I think that'd be a great idea, even if the OS itself is considerably out of date in some ways. There are lots of good ideas in there and some pretty nice code.
I'm constantly amazed how a PIII/450 running Unix (or MSware) can have worse UI response times than an A3000. Not that there was anything magic about the Amiga's response times other than straightforward design and attention to detail. (Lack of VM helped too of course.) It was fast; an A3000 68030@25MHz could boot to Workbench (GUI) complete with TCP/IP up and various directories NFS mounted in around 11 seconds (cold boot; I think it was more like 7 seconds on a warm boot since the kernel was already loaded).
Another thing about it was that it was very easy to program on. Simple things were simple without adding 6 layers of toolkits.You didn't need to write hundreds of lines just to open a window.
Async IO (which it excelled at, including async filesystem IO) was easy and clean. Sure, it had it's idiosyncracies and compatibility bugaboos (remember, I was the one who kept it compatible with those evil BCPL binaries), but overall it was clean, and one of the most stable OS's ever made.
You have to be stable when you have no protection hardware on a multitasking system... We even ran test programs that randomly failed allocations; the system stayed stable, and even many/most applications would stay stable (and not crash/exit). I used to run for months between reboots, and I was doing development and testing of code.
One thing to note is that considerable parts of the low-level code is in ASM; however with the source it'd be fairly easy to transcode most of it. Some modules are rather more hairy - the disk filesystem, for example. It's full of coroutines, lots of hacks to save bytes in the ROM, etc. (Do they still teach coroutines?)
I was the person who came up with the directory-name == cd there idea back in 1985 or 86. I put it into a shell I wrote for my own purposes, and after I joined the Amiga OS team in '88 I twisted Andy Finkel's arm to add it to the Amiga Shell (I also added all the support in AmigaDOS for alternate shells, and did the rewrite of AmigaDOS into C/ASM from BCPL (yuck), much of the SCSI/IDE work, hdtoolbox, ramdisk rewrite, notification, dircache in the FS, the whole prefs: idea, etc, etc, etc).
I was always annoyed (and still am) at Unix shells giving useless errors when I forget to type cd.
Slashdot Mirror
There is (or was) support for serial SCSI in the specs (the target at the time was high-speed serial links such as fiber, but it would apply to links similar to serial-ata as well). Also SCSI allows for target-mode, which would allow this serial bus to be used as a very-high-speed very-local-network.
The "directory-name as a command is equivalent to cd directory-name" thing was my invention. I got tired of typing 'cd' all the time, and I was writing a unix C-shell clone (plus a lit) for the Amiga (with process control, much more rich syntax, etc, etc, etc). I then got hired by Commodore, and shelved the shell - but I put a few things like the don't-have-to-type-cd into the main shell (actually, I convinced Andy Finkel to add them; I was in charge of AmigaDOS). I also added all the hooks for user shells to replace the default shell.
I wish tcsh on Unix had the ability to obviate the need for 'cd '.
(As someone mentioned, you could also add defines for directories, both for use as commands, and for access to files associated with a program. For example, I had src: assigned to Work:Development/src, and to CD there would just type "src:". Yes, of course this can be done with alias in tcsh, but alias doesn't help with things like "src:AmigaDos", or "copy src:foo/*.c wherever". Also, yes, if you are willing to create a bunch of top-level softlinks it will mostly work the same way in Unix - but people rarely are willing to do so.
Minor correction: 7.1x MHz 68000 in the A1000
>. And you're not going to convince me that the protesters that were in that warehouse brought the lethal animals as pets, or that the chemicals/explosive were there for no reason. The only logical conclusion is that these things were intended to be used as weapons
The secret service told the police about the bus with the animals; I've heard nothing about it's being involved with the warehouse. The animals were on the bus, not in the warehouse. The animals were NOT lethal, at least not any shown to the media. Annoying, yes, frightening to those with phobias, yes, lethal, no. Also, in the local Philly papers I've heard NO mention of explosives found in the warehouse. They did detonate a "suspicious" package which was harmless (probably someone's lunch).
At this rate, by next week the protesters will have had nuclear weapons... 1/2
I'm certain that some of the protesters are exaggerating things as far as possible, and trying to provoke the police. I'm also certain that in some cases the police have let themselves lose control and have over-reacted phyically. I'm also certain that for political reasons the police and the city have trumped up reports of problems and incidents, AND I'm certain that some demonstrators were not peaceful and did truely break the law (not just civil disobedience) (slashing tires, kicking police, etc).
Separating out which are true and which aren't is going to be tough. Don't be surprised if a judge or judges drops charges for most of them or reduces it to a minor fine, due to the confusion and lack of evidence.
Notify the company/maintainers/etc. Include in the notification that it will be made public on a specific date. This gives people time to create a fix and start distributing it. One of the big problems with press-release notification is that the patch is not normally available for a day or two or week or more, so you've pointed everyone at a hole that can't be fixed for some period of time.
Now, for cases where there is a workaround or easy fix you might want to just release it, or give a short time-span before release (a day or two).
The general idea is that knowing that the information will be released is a strong incentive for the company to have a fix ready, or better yet to have started distributing the fix, either discreetly (no information on the exact exploit of the flaw) or openly.
Note: this means that if you're not on AOL (or using an AOL client), your IM address will be someone@somewhere.xxx. To you, AOL users will be someone@aol.com, unless your IM server sends unknown users to AOL (and then you have the issue of collisions between local usernames and AOL names - but people/servers with small userbases probably wouldn't care much).
This solution appears to open (some) IM (not all features are supported via OpenIM in the draft, and there's no guarantee that AOL will support more advanced features in their OpenIM gateways). However, it also preserves AOL's lock on it's username-space and adds inconvenience for non-AOL-IM users, encouraging them to use AOL's client.
Still, it basically puts IM on the same footing and a similar architecture to email, which is a Good Thing.
Randell
p.s. Note: in a previous life, I was one of 4 or 5 people at a company called PlayNet that wrote what later became AOL, including the original IM design. (This was in '84/85.)
Don't use mailing lists. There are all sorts of administration annoyances with that, plus it's hard or impossible to remember which groups exist.
Use internal company newsgroups. For those (few) people whom you can't allow access to the news server, or simply won't read news, add a mailnews gateway.
This gives all sorts of benefits - if you set expiration to never, you get a permanent archive of all messages, and it's searchable. Even better, new employees (or new team/project members) can review old postings without having to pester someone for their email archives (and hope that they're complete).
Newsreaders are built into Netscape, IE, and look much like email to the user. People who use separate email programs may be tougher to convert.
I was involved (peripherally) with the old (pre-web) netrek networking protocols. In order to get things to work well in the face of lag and packet loss, information was divided into critical and non-critical. Critical information was sent via TCP, non-critical (realtime positions of ships and torpedoes and shield states, etc) information was sent via a UDP port.
Realize that this was a way to avoid implementing error recovery/windowing protocols on top of UDP directly - this greatly reduced the complexity versus a "use UDP for everything" design; doubly so since the game was written originally for TCP (and still works in TCP-only mode if need be, but if you drop a packet you get to wait - bad in a realtime game).
Originally it was designed to use random ports to deal with conflicts with other programs. Obviously in these days of firewalls, etc this causes (caused) problems.
I imagine modern games are either a) using the dual TCP/UDP port trick, b) using pure UDP with their own error recovery on top of it (expensive programming-wise, and liable to bugs), c) using pure TCP and living with serious lag if a packet is dropped, or d) using dual (or more) TCP connections, each for items of differing criticality.
(PS. I ported netrek to the Amiga in '91(?), and fixed a number of portability and other errors. Last time I tried, it still worked excluding that most servers no longer list it's public key as a blessed client.)
AmigaDOS (not the AmigaOS as a whole) including the shell, FS, etc was written mostly in BCPL; but for 2.0x I rewrote the DOS in C/ASM, while retaining compatibility libraries for older BCPL executables. 3.x had no BCPL-based code in it, and I'm happy to say I never once even ran the BCPL compiler.
The Exec was written almost totally in assembler for efficiency (not that it's very big... I seem to remember that Exec was circa 16K or less). Of course, Exec didn't do all that much compared to a Unix kernel. Exec was _loosely_ based on XINU.
As for the OS and Open Source: I think that'd be a great idea, even if the OS itself is considerably out of date in some ways. There are lots of good ideas in there and some pretty nice code.
I'm constantly amazed how a PIII/450 running Unix (or MSware) can have worse UI response times than an A3000. Not that there was anything magic about the Amiga's response times other than straightforward design and attention to detail. (Lack of VM helped too of course.) It was fast; an A3000 68030@25MHz could boot to Workbench (GUI) complete with TCP/IP up and various directories NFS mounted in around 11 seconds (cold boot; I think it was more like 7 seconds on a warm boot since the kernel was already loaded).
Another thing about it was that it was very easy to program on. Simple things were simple without adding 6 layers of toolkits.You didn't need to write hundreds of lines just to open a window.
Async IO (which it excelled at, including async filesystem IO) was easy and clean. Sure, it had it's idiosyncracies and compatibility bugaboos (remember, I was the one who kept it compatible with those evil BCPL binaries), but overall it was clean, and one of the most stable OS's ever made.
You have to be stable when you have no protection hardware on a multitasking system... We even ran test programs that randomly failed allocations; the system stayed stable, and even many/most applications would stay stable (and not crash/exit). I used to run for months between reboots, and I was doing development and testing of code.
One thing to note is that considerable parts of the low-level code is in ASM; however with the source it'd be fairly easy to transcode most of it. Some modules are rather more hairy - the disk filesystem, for example. It's full of coroutines, lots of hacks to save bytes in the ROM, etc. (Do they still teach coroutines?)
I was the person who came up with the directory-name == cd there idea back in 1985 or 86. I put it into a shell I wrote for my own purposes, and after I joined the Amiga OS team in '88 I twisted Andy Finkel's arm to add it to the Amiga Shell (I also added all the support in AmigaDOS for alternate shells, and did the rewrite of AmigaDOS into C/ASM from BCPL (yuck), much of the SCSI/IDE work, hdtoolbox, ramdisk rewrite, notification, dircache in the FS, the whole prefs: idea, etc, etc, etc).
I was always annoyed (and still am) at Unix shells giving useless errors when I forget to type cd.