sean@ms.uky.edu (Sean Casey) (01/02/89)
The IRQ virus is definitely harder to get rid of, but at least it doesn't intentionally try to damage anything. I wonder if it would have been detected so easily if it didn't put that message in the border! [an excerpt from BIX] >One more item on the IRQ virus. If it can't attack your Startup-Sequence >it will home in on C:DIR just to be sure that it gets executed. >This is a benign intruder that can mutate to something real nasty in the >hands of a sicko. We have the start of a real problem here. >Djj This is only the beginning. Look at the IBM PC viruses out there. They do everything from say "hello" to doing a low level hard disk format (bypassing the OS) after a wait period of 3 months. It's really bad. There are now tens of programs that hunt down viruses, and they are constantly out of date. Now consider the complexity and nature of MS-DOS and AmigaDOS, and it's easy to see how much more fun it would be to write viruses for the Amiga. It's going to get a whole lot worse before it gets better. The biggest light at the end of the tunnel is probably a protected mode OS with enforced privileges. Once debugged, at this would at least protect the system files from a user running a virus. STEVE I don't have your address. What I would do about the IRQ virus is patch into the AmigaDOS code that reads in disk hunks to be executed, and scan for any and all known "rider" viruses just before execution is handed off to the hunk. You should realize that sooner or later, one of the viruses is going to attempt to disable virusx! Better make plans for that possibility... Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
laba-3ar@e260-4b.berkeley.edu (Case Larsen) (01/02/89)
In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >It's going to get a whole lot worse before it gets better. The biggest >light at the end of the tunnel is probably a protected mode OS with >enforced privileges. Once debugged, at this would at least protect the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >system files from a user running a virus. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This wouldn't protect him from running a trojan horse that modified any of his work files. The user would necessarily have to be able to write and modify his own files. It also wouldn't wouldn't protect him from running a trojan horse that would add this line to the end of his startup-sequence: delete #? all quiet If the startup-sequence leaves the user in his work directory, the above command will remove all of his work files, but leave the system utilities untouched. Any solutions to that problem? >*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet >*** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean >*** U of K, Lexington Kentucky, USA ..where Christian movies are banned. >*** ``My name is father. You killed my die. Prepare to Inigo Montoya.'' _________________________________________________________________________ | __ __________________________________ | | /// |Sung to "I'm looking over a four | Case Larsen| |__ /// | leaf clover" | laba-3ar@web.berkeley.edu| |\\\/// |I'm looking over the root guy's | -or- |
peter@sugar.uu.net (Peter da Silva) (01/02/89)
In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >It's going to get a whole lot worse before it gets better. The biggest >light at the end of the tunnel is probably a protected mode OS with >enforced privileges. Once debugged, at this would at least protect the >system files from a user running a virus. This wouldn't be enough. You would also need multiuser protection, and you would need the USER to have enough discipline to not just sit in root all the time, as home-unix folks are wont to do. And when you'd done this, you'll have lost enough real-time performance that you might as well be running on a PC again. On the other hand, this is really a necessary requirement for a convenient, yet virus-free, work environment. It's not sufficient, but it's a start. Oh, for UNIX under AmigaDOS. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
laba-3ar@e260-4b.berkeley.edu (Case Larsen) (01/03/89)
In article <3200@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>It's going to get a whole lot worse before it gets better. The biggest >>light at the end of the tunnel is probably a protected mode OS with >>enforced privileges. Once debugged, at this would at least protect the >>system files from a user running a virus. > >This wouldn't be enough. You would also need multiuser protection, and you >would need the USER to have enough discipline to not just sit in root all >the time, as home-unix folks are wont to do. Even if the user doesn't sit in root, he could still run a trojan horse program that modifed all of his files (excluding protected system files.) There is no way to prevent this short of checking each program for suspicious looking code before it is run. >-- >Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. >...texbell!sugar!peter, or peter@sugar.uu.net 'U` ----- Case Larsen clarsen@garnet.berkley.edu (internet) (Best) ..!{ames|hplabs|decvax}!ucbvax.berkeley.edu!garnet!clarsen (UUCP)
sean@ms.uky.edu (Sean Casey) (01/03/89)
In article <18668@agate.BERKELEY.EDU> laba-3ar@e260-4b.berkeley.edu (Case Larsen) writes: |In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: |>light at the end of the tunnel is probably a protected mode OS with |>enforced privileges. Once debugged, at this would at least protect the | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |>system files from a user running a virus. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |This wouldn't protect him from running a trojan horse that modified any |of his work files. The user would necessarily have to be able to write |and modify his own files. It also wouldn't wouldn't protect him from |running a trojan horse that would add this line to the end of his |startup-sequence: | delete #? all quiet Yeah, well, that's what I said. It would protect the system files. It should be obvious that there is no real generalized solution to protect users from themselves. |If the startup-sequence leaves the user in his work directory, the above |command will remove all of his work files, but leave the system utilities |untouched. |Any solutions to that problem? Backups. -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
sean@ms.uky.edu (Sean Casey) (01/03/89)
In article <3200@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: |In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: |>It's going to get a whole lot worse before it gets better. The biggest |>light at the end of the tunnel is probably a protected mode OS with |>enforced privileges. Once debugged, at this would at least protect the |>system files from a user running a virus. |This wouldn't be enough. You would also need multiuser protection, and you |would need the USER to have enough discipline to not just sit in root all |the time, as home-unix folks are wont to do. I SAID a protected mode operating system. You know, like different memory maps for each user so they can't clobber each other? Anyone that sits in root all the time deserves whatever happens to them. You have to be REALLY careful in root. For example, I found out by accident that you don't type "kill -9 %1" and forget the percent sign. The only thing you should need a root shell for is installing software. |And when you'd done this, you'll have lost enough real-time |performance that you might as well be running on a PC again. Huh? Why do you say that? An '030 with MMU is certainly a lot faster than a PC. As the processors get faster, the system overhead becomes a smaller fraction of the available horsepower. |Oh, for UNIX under AmigaDOS. You know what I'd like to see? Parallel processors. One runs Unix, and the other runs AmigaDOS, and they like know how to do lunch. You could get a mergerDOS window from Unix, and a Unix X11 (or Open Look!) window from AmigaDOS. I think it would be an interesting solution over a layered approach, and probably easier to implement. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
peter@sugar.uu.net (Peter da Silva) (01/03/89)
In article <10795@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > In article <3200@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes about multiuser protection... > I SAID a protected mode operating system. You know, like different memory maps > for each user so they can't clobber each other? There is a difference between a protected O/S and a multiuser O/S. For example, RSX-11 comes with multiuser protection as an option. If you don't get that option, it comes up with (effectively) shells on all interactive ports and everyone running in root. RSX-11, by the way, is another real-time O/S. It's got a lot of similarity to AmigaDOS. > Huh? Why do you say that? An '030 with MMU is certainly a lot faster > than a PC. As the processors get faster, the system overhead becomes a > smaller fraction of the available horsepower. Real-time work, like Midi, is not compatible with a heavy-duty protected virtual memory multi-user O/S. Let's see you run Midi on a SUN. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
sean@ms.uky.edu (Sean Casey) (01/04/89)
In article <3205@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >> Huh? Why do you say that? An '030 with MMU is certainly a lot faster >> than a PC. As the processors get faster, the system overhead becomes a >> smaller fraction of the available horsepower. > >Real-time work, like Midi, is not compatible with a heavy-duty protected >virtual memory multi-user O/S. Let's see you run Midi on a SUN. Real-time work not compatable with multiuser VM Systems? Tell it to Masscomp. I've been using Real Time Unix for three years. Tell it to NeXT. The NeXT box can multitask and DSP too. It's almost the nineteen nineties. Computers can walk and chew gum at the same time now. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
bader+@andrew.cmu.edu (Miles Bader) (01/04/89)
peter@sugar.uu.net (Peter da Silva) writes: > In article <10788@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > >light at the end of the tunnel is probably a protected mode OS with > >enforced privileges. Once debugged, at this would at least protect the > >system files from a user running a virus. > > This wouldn't be enough. You would also need multiuser protection, and you > would need the USER to have enough discipline to not just sit in root all > the time, as home-unix folks are wont to do. > > And when you'd done this, you'll have lost enough real-time performance that > you might as well be running on a PC again. That remains to be seen... -Miles
peter@sugar.uu.net (Peter da Silva) (01/04/89)
In article <10800@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > Real-time work not compatable with multiuser VM Systems? Tell it to Masscomp. Masscomp uses an exotic dual-processor system to achieve real-time. Their solution is not a general solution to the problem of real-time work under UNIX. The same thing is true of DEC's real-time VAX software. On the other hand you can do real realtime on a simple PDP-11 or 68000 if you don't take on the load of memory management. > I've been using Real Time Unix for three years. Tell it to NeXT. The NeXT > box can multitask and DSP too. It's almost the nineteen nineties. Computers > can walk and chew gum at the same time now. Again, it's a dual processor, on a totally unloaded system. For 10 grand (the cost of a useful NeXT system, if you can get one) I'd expect that much. Give it a real task before you claim it's a realtime system. CMU (who developed Mach) do not claim that it's a real-time system, though it's got the right framework... we're evaluating it for real-time enhancement. The two advantages that Mach has are the lightweight processes and the user paging. I suspect that real-time tasks will have to be lightweight processes and be locked into RAM. No fancy memory management for them, let alone VM. Note that the cost of mach threads is about the same as the cost of Amiga processes. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (01/04/89)
In article <10800@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > Tell it to NeXT. The NeXT box can multitask and DSP too. The box can, but the OS can't. Without an intelligent coprocessor like the nEXt has, Mach is not quite up to real-time response. The DSP chip on its own is about as real-time as you get, but there's not much chance of a Mach process responding to DSP stimuli in real time. Peter didn't say real-time Unix is impossible, he said virtual memory and real-time don't get along. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
kent@swrinde.swri.edu (Kent D. Polk) (01/04/89)
In article <5621@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > >Peter didn't say real-time Unix is impossible, he said virtual memory >and real-time don't get along. >-- > -=] Ford [=- > >"The number of Unix installations (In Real Life: Mike Ditto) >has grown to 10, with more expected." ford@kenobi.cts.com >- The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford > 2nd Edition, June, 1972. ditto@cbmvax.commodore.com HP-UX can assure a certain response time to processes you designate to be handled using their real-time routines - however, real-time time varies according to which processor you use. Unfortunately, you have to get a REAL FAST one ($$$$$) to get what is usually considered "real time response". Well, it's a start towards real time with virtual memory, and the real time routines are pretty nifty for other things as well. =============================================================================== Kent Polk - Southwest Research Institute |> Frogsoundz: Ultrasonic {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent|> waveforms time-dilated ___/\___/\___/\___/\___/\___/\___/\___/\___/\___/\____|> & played on my Amiga. ===============================================================================
charles@hpcvca.HP.COM (Charles Brown) (01/05/89)
>> Tell it to NeXT. The NeXT box can multitask and DSP too. >> -- Sean Casey > Peter didn't say real-time Unix is impossible, he said virtual memory > and real-time don't get along. > -=] Ford [=- This is (almost) true, but most people reading it will get the wrong impression. The "almost" is because we really should say "demand paged VM" rather than "virtual memory". There is NOTHING which prevents virtual memory without demand paging to be used in real-time. This would allow several programs (for instance, one real-time and several non-real-time) to co-exist in RAM and all think that they are located at the same fixed origin in memory. Virtual memory without demand paging also allows you to easily write protect major portions of RAM. Thus the operating system and drivers can be (at least in theory) made untouchable by viruses. From what I understand of Hewlett-Packard's implementation of Real-Time Un*x (yes, HP has real-time also.) the real-time program must be locked into physical RAM and be given high priority. It is still running under a virtual memory operating system and may coexist with several programs which get swapped as needed. Its just that the real-time code never gets swapped. No specialized CPU is required. So Amiga could be modified to use VM and even demand paging and still have provisions for real time. I expect to get flamed for this. There are several people who read this notes group who are violently opposed to demand paging for performance reasons. However, they simply do not know what they are talking about. Its really very simple. There are two cases: 1. All processes will fit into physical RAM. Not demand paged: Runs fast. Demand paged: No paging. Runs just as fast. 2. Processes will NOT fit into physical RAM. Not demand paged: WILL NOT RUN. Either fails to load or crashes. Demand paged: Pages. Runs slow, but at least it still runs. So under the same circumstances, demand paged systems do not run slower than non-demand paged systems. -- Charles Brown charles%hpcvca@hplabs.hp.com Not representing my employer.
pha@zippy.eecs.umich.edu (Paul Anderson) (01/06/89)
In article <1410014@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: > >So Amiga could be modified to use VM and even demand paging and still >have provisions for real time. > >I expect to get flamed for this. There are several people who read >this notes group who are violently opposed to demand paging for >performance reasons. However, they simply do not know what they are >talking about. Its really very simple. There are two cases: > 1. All processes will fit into physical RAM. > Not demand paged: Runs fast. > Demand paged: No paging. Runs just as fast. > 2. Processes will NOT fit into physical RAM. > Not demand paged: WILL NOT RUN. Either fails to load or crashes. > Demand paged: Pages. Runs slow, but at least it still runs. >-- > Charles Brown charles%hpcvca@hplabs.hp.com > Not representing my employer. Probably the right way to handle this is give processes the ability to wire down pages they want locked in physical RAM. A simple system call will let time critical application wire their interrupt handling code, buffers, and whatnot, but still let the rest of the application be paged if it isn't performance critical. I don't think you should get flamed for wanting paging, since it is generally a good thing, especially when solving real time problems isn't that agonizing. Along the lines of this discussion, is anyone doing a 4.3 or Mach port to the Amiga? I know someone is doing a Mac-II port, and I am working on a Mach port to the Apollo. The only reason I ask is that if this isn't being done, maybe it should be, cause the Amiga hardware is kinda nice (mostly cheep, I guess). I know about the 2500 unix box, but I'm not that thrilled by system V. Paul Anderson CAEN Apollo Systems Programmer UofMich
sean@ms.uky.edu (Sean Casey) (01/06/89)
In article <3206@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <10800@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: >> Real-time work not compatable with multiuser VM Systems? Tell it to Masscomp. >Masscomp uses an exotic dual-processor system to achieve real-time. Their >solution is not a general solution to the problem of real-time work under >UNIX. Peter's statements are incorrect. Our MC500 has only one CPU, a 68010, and does real-time processes with very little extra programmer effort. Indeed, Masscomp's solution was to incorporate real-time facilities into their version of Unix. That means special memory management, high-speed interrupt service, RAM locking, etc. -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are banned. *** ``My name is father. You killed my die. Prepare to Inigo Montoya.''
peter@sugar.uu.net (Peter da Silva) (01/06/89)
In article <1410014@hpcvca.HP.COM>, charles@hpcvca.HP.COM (Charles Brown) writes: > The "almost" is because we really should say "demand paged VM" rather > than "virtual memory". There is NOTHING which prevents virtual memory > without demand paging to be used in real-time. Oh goodie, are we going to get into the Virtual Memory Terminology Wars all over again? You know, the one where some people talk about VM versus Mapped Memory, and others talk about DPVM versus VM? > From what I understand of Hewlett-Packard's implementation of > Real-Time Un*x (yes, HP has real-time also.) the real-time program > must be locked into physical RAM and be given high priority. It's not enough, unless you have enough hardware contexts for the memory manager that you don't have to reload the MMU to switch to the realtime tasks. Again, this is exotic hardware. the other alternative is to have the real-time tasks running with the MMU turned off, but that's not UNIX any more... at least for the realtime stuff. > So Amiga could be modified to use VM and even demand paging and still > have provisions for real time. Yes, so long as the virtual tasks are strictly second-class citizens. I wrote up an article about this some months back... basically the idea was that you make UNIX a shared library and a bit of normal Amiga runtime, and have the tc_Switch entry in the task turn the MMU on and off as you entered and left UNIX. UNIX under AmigaDOS. Because the Amiga is the best user environment I have ever seen in a real-time machine. It's NOT as good as UNIX, but it's damn good. > 1. All processes will fit into physical RAM. > Not demand paged: Runs fast. > Demand paged: No paging. Runs just as fast. You still have the overhead of reloading the MMU on every context switch. Right now an Amiga switch has about the same overhead as a non- optimised procedure call. I've seen a multi-stage midi.library pipeline handle 600 MIDI events per second, with PM running, and CPU utilization hardly budged. That's 1200 context switches per second, minimum, plus a non-trivial amount of work within the programs. So, no, it does not run just as fast. > 2. Processes will NOT fit into physical RAM. > Not demand paged: WILL NOT RUN. Either fails to load or crashes. > Demand paged: Pages. Runs slow, but at least it still runs. Yep. Just great for timeshared users. There are dozens of timeshare systems much better suited to the job. UNIX, for example. There are no other real-time systems that let ordinary people, not control systems professionals, work with and write non-trivial programs with a $1500 investment. I think the cheapest real realtime with any sort of decent user environment would have to be something like an LSI-11 with RSX-11. I think DEC used to sell a rather pricey PC like that (PRO-350?). It certainly wasn't a $1500 box. More like $5K-$15K. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
peter@sugar.uu.net (Peter da Silva) (01/06/89)
In article <10811@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > In article <3206@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >Masscomp uses an exotic dual-processor system to achieve real-time. > Peter's statements are incorrect. Our MC500 has only one CPU, a 68010, Then Masscomp's published literature is incorrect. I'll have to check this out. Either we have different ideas of what "real-time" means, or they haven't been telling us everything. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
mazer@bek-owl.caltech.edu (Jamie Mazer) (01/08/89)
In article <3224@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <10811@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: >> In article <3206@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >> >Masscomp uses an exotic dual-processor system to achieve real-time. > >> Peter's statements are incorrect. Our MC500 has only one CPU, a 68010, > >Then Masscomp's published literature is incorrect. I'll have to check this >out. Either we have different ideas of what "real-time" means, or they >haven't been telling us everything. As I understand our masscomp, there is only one CPU running unix (actually masscomp's Real-Time-Unix); this is a 68020 or variant. The real-time unix has provisions for upping job priority and page locking. However, the trick is that an auxiliary bus, with its own 680x0 cpu, called the DACP (Data Acq Ctrl Proc), handles the things you consider to be time critical, like polling lab devices, starting/stopping clocks etc. The DACP is a dedicated data collection CPU and must be programmed in assembly. So.. If you want to send out a sine wave, you fill a buffer up in your locked process's memory and then start up the DACP and then sleep until the DACP is finished. The DACP grabs the buffer in pieces via DMA and feeds it to the D/A converter; of course a similar process is involved for incomming data. Two things: (1) I've simplified a bit - I've found that programming this beast is far more complicated than it sounds and (2) You can actually have multiple Unix CPU's in some configurations which share the Unix process load - but they have nothing to do with Real-Time issues, they just increase the through-put of the Unix tasks. Sorry if this trip into the guts of a masscomp was slightly off track.. /Jamie UUCP: {rutgers,ames}!cit-vax!bek-owl!mazer ARPA: mazer@bek-owl.caltech.edu BITNET: jmazer@caltech.bitnet "There's no Elvis in Michael J. Fox."
rroot@edm.UUCP (Stephen Samuel) (01/08/89)
From article <3222@sugar.uu.net>, by peter@sugar.uu.net (Peter da Silva): > > much better suited to the job. UNIX, for example. There are no other real-time > systems that let ordinary people, not control systems professionals, work > with and write non-trivial programs with a $1500 investment. I think the > -- > Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. Unh, Have you considered OS-9? Granted, a 2MZ COCO isn't as fast as an amiga, but it IS a LOT cheaper. OS-9 is designed for real-time work and can even be ROMmed, once you get your stuff working right. It's also pretty nice to work with in most cases (looking quite a bit like UNIX[tm]). I know the U of A physics got a stack of them to do (student) experiment controls, though I'm not sure that they all run under OS-9. [I STILL think that C-A would have been beter off with OS-9, but, c'est la vie. -- ------------- Stephen Samuel (userzxcv@ualtamts.bitnet or alberta!edm!steve) (Only in Canada, you say??.... Pity!)
peter@sugar.uu.net (Peter da Silva) (01/08/89)
In article <9050@cit-vax.Caltech.Edu>, mazer@bek-owl.caltech.edu (Jamie Mazer) writes: > the trick is that an auxiliary bus, with its own 680x0 cpu, called > the DACP (Data Acq Ctrl Proc), handles the things you consider > to be time critical, like polling lab devices, starting/stopping > clocks etc. The DACP is a dedicated data collection CPU and > must be programmed in assembly. So, Masscomp does NOT have a "hard-real-time" UNIX. They have a UNIX that's got enough enhancements for soft real-time, and defer hard real-time to another processor, running another operating system. Much like DEC does with their real-time VMS. And much as NeXT does to do really fancy demos. If you're running UNIX (or other heavy-MMU operating systems) on off-the-shelf non-proprietary hardware, then, you can't get realtime. Yet, anyway. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
peter@sugar.uu.net (Peter da Silva) (01/09/89)
In article <5142@edm.UUCP>, rroot@edm.UUCP (Stephen Samuel) writes: > From article <3222@sugar.uu.net>, by peter@sugar.uu.net (Peter da Silva): > > much better suited to the job. UNIX, for example. There are no other real-time > > systems that let ordinary people, not control systems professionals, work > > with and write non-trivial programs with a $1500 investment. I think the > Unh, Have you considered OS-9? Yes, I have. > Granted, a 2MZ COCO isn't as fast as an amiga, but it IS a LOT cheaper... Yeh, I know. It's really marvellous, and I hate Radio Shack's complete lack of support for it. But with only 48K anything serious had to be written in assembler. > [I STILL think that C-A would have been beter off with OS-9, but, c'est > la vie. Me too. Oh well, no use crying over spilled milk... not that that ever stopped me :-> -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
simon@copper.columbia.edu (Thor Simon) (01/11/89)
God, this message has gotten off the subject!!! Anyway, to go further off-target, Peter writes: >>Unh,have you considered OS-9? >Yeh. [deleted] I hate Radio Shack's complete lack of support for it. But >with only 48K, anything serious had to be written in assembler. Actually, if you can dig up an old CBM Super-Pet (Try high-schools) TPUG offers a version of OS-9 called Super OS-9. It lets you use all 96K in the SuperPet (Not much but better) and is supposed to include a decent implementation of C. I haven't tried it, but if you do, tell me if it's any good, OK? ______________________________________________________________________________ | It's not what you're doing that counts. It's how little you know about it. | ****************************************************************************** **************************Thor Simon, New York, NY**************************** ******************************************************************************
raulmill@sal55.usc.edu (Raul Miller) (01/13/89)
You know, there is a simple way of defeating most of the current
generation of virus-type-programs: never do a warm boot from disk.
In other words, do your warm boots from ram disk. This is
analogous to write protecting your boot disks, and to avoiding
use of root privilege under unix (both are also good ideas).
Aside from that, I think it a very good idea to have the option
of seeing and aborting write permission on a file by file
and process by process basis... Any security measures can be
bypassed, but the more I can look at what my machine is doing,
the better I feel about it.
Raul Miller |
USENET: raulmill@oberon.usc.edu |
U.S.SNAIL: 980 Arapahoe | 55 mph = 82 nc
LOS ANGELES CA 90006 |
Raul Miller |
USENET: raulmill@oberon.usc.edu |
U.S.SNAIL: 980 Arapahoe | (this space for rent)
LOS ANGELES CA 90006 |