spinix
Dave Hein
Posts: 6,347
Spinix is a linux-like operating system for the Prop. The latest version of spinix is in the file spinix167.zip, which is attached below. Please see the posts toward the end of this thread for the latest information on spinix.
The original message is given below. Note that spinix no longer uses a files system on the EEPROM, and works with an SD card and the standard 32K EEPROM.
The thread on porting linux got me thinking about the OS that I've been tinkering with.· I originally called it CDOS because I was using it to test out file I/O code that I'm adding to CLIB.· However, I thought a more appropriate name would be spinix because it is a unix/linux-like OS that's written in·Spin.· It is actually more like minix because the drivers are viewed as processes, just like a user program.
spinix will support up to 8 processes, basically because there are 8 cogs.· The boot process starts up in cog 0 and loads a serial driver, i2c driver and file I/O driver in cogs 1, 2 and 3.· It then loads a shell program in cog 4, which terminates the boot loader, and frees up cog 0.· The RAM used by the boot program is then added to the memory heap.
Currently I use the boot EEPROM as a file storage device.· linux is installed by running the install.binary file.· It will prompt the user for the size of the EEPROM, and it will format it according to the size specified.· You could also build install.binary from the source in the zip file if you want.· After the EEPROM is formated the boot program is written plus the shell.binary program, a help.txt file, and the rb application.· rb (receive binary) is used to download additional files from the bin directory in the zip file.· It uses the YMODEM protocol, and it has been tested with the Windows hyperterminal.
When spinix first starts up, the shell·will·run a ps (process status) command.· This shows the status of the 5 cogs that are running at that time.· A subsequent ps command will display only 4 active processes because the boot program will no longer be active.··The malloc command will show the status of the heap.· The addresses and sizes of the two Spin processes will be almost the same in the ps and malloc displays.· They differ only by the 4-byte header size used by the heap manager.· Type help to see all of the commands provided by the shell.
Additional apps such as cat, echo, ls, od, etc. can be copied to the file system using the rb command.· After you type the rb command you will have 15 seconds to select a file and set hyperterminal to send it using the YMODEM protocol.· If you have a 32K EEPROM there is only enough space to add one additional app.· You can load an app, try it, delete it, and then load another app.· If you have a 64K EEPROM there should be about 42K of free space.··This is enough space to hold·about 8 additional apps, which can be transferred from the bin directory one at a time.
If you have a 128K EEPROM there will be over 100K of free space.· This will provide enough space to transfer the tar app and the two tar files.· The remaining apps·can then be extracted from the tar files.· The tar files should be deleted after the files are extract to provide more file space.
This version is just a beginning.· The next step is to add an SD file system.· I should be able to do that in the next few days.· Then it's a matter of adding more apps and features, and fixing bugs.
Dave
Post Edited (Dave Hein) : 7/8/2010 11:06:55 PM GMT
The original message is given below. Note that spinix no longer uses a files system on the EEPROM, and works with an SD card and the standard 32K EEPROM.
The thread on porting linux got me thinking about the OS that I've been tinkering with.· I originally called it CDOS because I was using it to test out file I/O code that I'm adding to CLIB.· However, I thought a more appropriate name would be spinix because it is a unix/linux-like OS that's written in·Spin.· It is actually more like minix because the drivers are viewed as processes, just like a user program.
spinix will support up to 8 processes, basically because there are 8 cogs.· The boot process starts up in cog 0 and loads a serial driver, i2c driver and file I/O driver in cogs 1, 2 and 3.· It then loads a shell program in cog 4, which terminates the boot loader, and frees up cog 0.· The RAM used by the boot program is then added to the memory heap.
Currently I use the boot EEPROM as a file storage device.· linux is installed by running the install.binary file.· It will prompt the user for the size of the EEPROM, and it will format it according to the size specified.· You could also build install.binary from the source in the zip file if you want.· After the EEPROM is formated the boot program is written plus the shell.binary program, a help.txt file, and the rb application.· rb (receive binary) is used to download additional files from the bin directory in the zip file.· It uses the YMODEM protocol, and it has been tested with the Windows hyperterminal.
When spinix first starts up, the shell·will·run a ps (process status) command.· This shows the status of the 5 cogs that are running at that time.· A subsequent ps command will display only 4 active processes because the boot program will no longer be active.··The malloc command will show the status of the heap.· The addresses and sizes of the two Spin processes will be almost the same in the ps and malloc displays.· They differ only by the 4-byte header size used by the heap manager.· Type help to see all of the commands provided by the shell.
Additional apps such as cat, echo, ls, od, etc. can be copied to the file system using the rb command.· After you type the rb command you will have 15 seconds to select a file and set hyperterminal to send it using the YMODEM protocol.· If you have a 32K EEPROM there is only enough space to add one additional app.· You can load an app, try it, delete it, and then load another app.· If you have a 64K EEPROM there should be about 42K of free space.··This is enough space to hold·about 8 additional apps, which can be transferred from the bin directory one at a time.
If you have a 128K EEPROM there will be over 100K of free space.· This will provide enough space to transfer the tar app and the two tar files.· The remaining apps·can then be extracted from the tar files.· The tar files should be deleted after the files are extract to provide more file space.
This version is just a beginning.· The next step is to add an SD file system.· I should be able to do that in the next few days.· Then it's a matter of adding more apps and features, and fixing bugs.
Dave
Post Edited (Dave Hein) : 7/8/2010 11:06:55 PM GMT
Comments
It's a bit more unix like than my liking because I have never really used unix. I am more at home with DOS. But hey, I will learn
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I will like it even more after it has uSD support [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Your logo could have an image of Propeye sporting a tatoo of the propeller hat on his forearm.
Steve
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Well that started me thinking about what is the essence of Unix and how much of that essence could a Prop support in any useful way. If anyone has a view about the essence of Unix I'd like to here it. But what I see is:
1) Processes. Unlike old batch systems and MSDOS it Unix has simultaneously running processes. Well the Pro can do that. Just limit the number of process IDs to 8. One per Cog.
2) Multi-user. Well I think we can skip that but wait a minute, the Prop can do that already, it has been done with the yZ80 emulator running MP/M. There must be a way to get that capability in a more Prop oriented system if anyone had a mind to.
3) Memory management. The Prop can do that, Bill Henning has his VMCog. With that Zog can run huge C/C++ programs from external memory. I guess soon other language systems will also be able to use it. Memory protection I think we can skip.
4) File system. Should be accessible form all processes at the same time. We have at least file systems.
5) The shell. Fundamental to Unix has always been a shell to launch apps from. And fundamental to that has been I/O redirection ( < and > ) and Pipes (|) and running in the background (&). This kind of I/O connection can be done through mail boxes I believe.
6) The C language. All Unix like systems have been written in C.
7) A whole bunch of familiar user commands, ls, cd, mkdir, cat, ps, etc etc etc.
As usual while I'm idly thinking my thoughts others have been busy doing it.
Great stuff Dave.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just a few minor notes:
1: More slower processes are possible - example: modified LMM kernels that swap contexts evern X*100 LMM instructions, ZOG's similarly modified etc. One cog running LMM at "N" MIPS can logically be replaced by one cog running X threads at roughly N/X MIPS.
2: Multi-user: pass a process a different stdio handle that points to a different serial port [noparse]:)[/noparse]
3: VMCOG has the hooks for memory protection with the RDONLY bit. Once I move to a hub based map table, it would be trivial to also add a "nonexistent page" flag, and the combination of the two would be sufficient for full memory protection. It would only cost a roughly 100ns speed penalty on page misses!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Similarly we have the fundamental unit of processing in the Prop. That which runs on it's own COG. Now, as you say you can run LMM or some virtual machine and divvy up the time between multiple threads within the VM.
And as we have read recently even within a pure PASM cog program one can introduce the idea of threads at an even finner grained level.
So a Prop OS should at least be aware of cog "processes" and then perhaps be aware of virtual machine/LMM threads. I think the finner grained PASM threads are out of scope for an OS.
Multi-user more than just having multiple console ports. There is the issue of ownership of files, processes, etc. We have no ownership concept in FAT for example. Perhaps that level of mult-user support is not appropriate for a Prop OS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
w8an, I did consider Spinach as another possible name for the OS.· When I considered Spinach I recalled the Popeye cartoons that I watched as a kid, and I begged my mom to serve spinach for dinner.· She finally agreed to serve spinach, and I quit asking for it after I tasted it for the first time.· I like the Propeye suggestion.
Bill, I am looking into adding SD support.· I already have a version of FSRW that I interfaced to CLIB.· I just need to put the four SPI variables in the rendezvous area and modify the boot program.· I have also been following your LMM task switcher thread, and I could see how that could fit into spinix.· In theory, any type of program can run in each cog.· They just need to conform to the OS interface, which means they need to access OS services through the rendezvous locations.· There may be a way to make external memory available through the OS, or individual apps could have dedicated use of the external memory.· The key to running other apps is that they need to be position independent just like Spin.· I know there is a way to make LMM programs position independent by doing relative jumps.· Of course, if you implement an MMU then that can handle the memory addressing issues.
heater, you raise some valid issues about multi-user access.· It could be implemented using multiple serial ports and multiple shell instances.· Or with a TCP/IP stack it could be done through telnet.· However, as you said the FAT FS does not support file ownership, or at least the basic FAT FS does not.· There must be a way to do it since Windows is able to protect folders from being accessed by others.· However, I don't think file protection is very high on the feature list for spinix.
Cluso, DOS and linux are very similar, but it's a bit like speaking a different language.· ls instead of dir, cat instead of type, rm instead of del, etc.· The shell does use dir, type and del·for debug purposes.· I'll remove them from the shell at some point and add them as apps, or maybe alias them to ls, cat and rm.· There's also the issue about backslashes versus forwardslashes and the CR-LF newline in DOS.· I may add a DOS compatibility mode for that.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Heater, the only core of UNIX I see missing is the idea of devices as files.
I don't think ownership matters, given the scope of the prop. Device access as files completes the picture, IMHO. From there, applications can be written to that file layer, allowing for drivers to vary along with setups.
We have the X window system for multi-user graphics, and that's complicated. However, frame / text buffers could be done serially with the device as file bit, meaning a slave prop could serve graphics to the kernel propeller and life is golden. ...or, if it fits, have a text display on the prop, whichever makes sense. The beauty of the device as file bit is the application wouldn't care, so long as a common representation were used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
The "politically correct" thing can get out of hand.· A few years ago I was involved in the development of videoconferencing standards.· The international versions of the standards used the terms "master" and "slave" to describe a communications protocol.· We had to replace these terms with "server" and "client" for the ANSI versions of the standards so that we wouldn't offend anyone.
potatohead, I do plan on adding a /dev directory at some point, which would provide access to devices such as additional serial ports, file systems and other peripherals.· Of course, this means we'll need to support subdirectories.· The root directory will get too messy with all the apps, man pages, devices and user files.
After I get FSRW working I'll need to figure out how to do subdirectories with it.· Kye's SD driver is also another possibility.· However, it contains a lot of stuff that would be duplicated, and each instance uses a lot of variables.· FSRW only uses 10 variables and a sector buffer per instance.
I like the idea of supporting X windows in the future.· Maybe a text version first, and then graphics later on.· I have been playing around with the curses functions, which were developed a few decades ago to work with VT100 and ANSI terminals.· It might be the basis for an X windows-like application.
·
I must say that I'm very pleased with what I see here so far. Now, where was that little C compiler? [noparse]:)[/noparse]
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Compile one of the zillion or so "SmallC" C compilers. See how big an executable you come up with.
It may be feasible to run one with 128k-256k VM, assuming a ZOG code generator is bolted on, it would allow at least subset C compilation on a prop [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
You just did what I was trying to do, however I personaly wouldnt worry about disk access and any further software just yet. I would start working on a system bus that will alow for future expandability of the hardware itself, if you start adding access now, you will be limiting the capabilities of hardware expansion.
The system bus should be persistan with all systems that use this code so it doesnt get broken. If you keep the Keyboard, Mouse, and video display, all a preconfigured pins, all the remaining pins should be used for the system bus and programmed as address, data lines, strobe, etc... lines so the kernel knows where to look ant it will never need to change. You'll then be able to assign device mapping that will stay persistant and other users will not have to adjust their pins. The current flash location can be used for SD card access,
For disk access, you would need to conform to atleast the ATA-3 standards, that would be too much code. Instead leave that as an addable module for the system bus. Use SD-Card access for the initial drive access instead.
With a dedicated system bus, you can then add support for VGA video, hard/floppy disk, etc... all using the same data and address lines....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
1) Uses one pin for keyboard (Yes it can be done) and one pin for mouse, and a few pins for video.
2) Use all other pins for a "system bus" with address, data and control lines for external RAM and peripherals.
The question is, if one is going to do that what is the point of using the Propeller at all?
If all the pins are so used there is no scope for using most Cogs, they have now here to go.
Note: There are hardware designs like this already, The TriBlade board uses most pins for RAM and then a second Prop for Video, keyboard etc. The DracBlade uses less pins for RAM by employing external latches. Then it has room to drive SD card, video, keyboard all from one Prop. DracBlade was designed as an emulation engine for Z80 emulators and CP/M and such.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Spinix can probably be used on Bill's Morpheus with the right drivers.
Morpheus provides a traditional system bus. However, the vast number
of users prefer less sophisticated hardware probably to Bill's chagrin.
We all enjoy Propeller programming; simple tends to rule choices.
Being able to use Spinix to run utility and other programs without
requiring a reboot is a huge win that has to date not been done.
This allows running many programs to achieve tasks not possible to date.
I will stick with the direction Dave decides to go out of respect and trust
primarily because of his obviously demonstrated software engineering
competency, ability to move quickly, and make good community oriented
decisions. If he decides to get more complicated, he can do that too.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I have to run to the airport to pick up my sister right now, but I'll post some more information later.
Dave
Which hardware can i use to test spinix?
USB Protoboard?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Dave: Not all hardware uses successive SD pins up or down. I share the pins on my designs so they are not consecutive and therefore all 4 pins must be defined. They could be within one long but the decoding would take more instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I've look at Sphinx a bit, but I've never actually tried it.· There's probably a lot of similarity with spinix.
William, I'm just using a breadboard with a the Propeller, EEPROM, 5 MHz crystal and an uSD card.· Any platform with an SD card should work, but the pins have to be sequential for now.· You could modify the start_explicit statement in bootsd.spin and rebuild it if needed.· I use BST to build.· I'm not sure if it will build under the Parallax Prop Tool.
Jorge, my current interest is to get spinix to work on a minimal platform.· However, I want to make it flexible enough that memory drivers could be added, and it do some very interesting things in larger systems.· Can you tell me a little bit more about your system bus idea?
I'm not familiar with ATA-3.· I'll have to look into that.
Steve, I recall Rock Ridge being mentioned in reference to Kye's SD file system code.· I think it is worth looking into.· The DOS 8.3 file names are somewhat limiting.· It took me a little more time than I expected to get the SD code integrated into spinix because the shell.binary program would not open.· Without the shell running it was hard to figure out what was going on.· Then I realized that FSRW was actually using the 8.3 name, which turned out to be SHELL~1.BIN.· I have since renamed it to shell without an extension.
Bill, I'll look into the SmallC compiler, but it seems like there's some licensing issues with it.· Do you have a reference for a good SmallC compiler that is license free?· I checked the size of CSPIN, and the DOS executable is 85 Kbytes.· I might be able to trim this down to fit on the Prop by removing features.· This would generate Spin source, and then maybe it could be compiled with mpark's Spin compiler.· It's something to think about.
Dave
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
ATA-3 = AT Attachment-3 Interface, It is generaly required when working with disk drives, if you intend on using Hard Drives in the future, you will need to know at minimum ATA-3. If you want to support drives that use, lets say firewire, I think that is ATA-6 or 8. Most modern Disk Drives conform to ATA-8 while the older ones conform to ATA-3.
Now I am off to actualy boot up and play with your Spinux, I found some old public domain and some open source grep.c files but can find them right now, ill keep looking. In the mean time here is a grep written in 6809 assembly, I am sure someone with more knowledg in pasm can understand it better.
Unless anyone wants to connect old hard drives, floppy drives, and CD-ROMs to the Propeller I see no point in ATA.
I would imagine most are happy with SD card storage.
There might be a case for CompactFlash cards in ATA mode, but I have not head any requests for such objects here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Great work so far! I am going to have to download it and try it out.
Thanks
Doug
[noparse][[/noparse]cue rippling, dreamy "back in the day" effect]
Before the PC / Mac market had fully consumed most of computing, I got to setup my dream X system as part of a very expensive and large scope engineering software contract. My spec won out on cost, and so it got done! (sweet)
The core of it was a few servers. One was a multi-CPU SGI Origin class machine, equipped with 8 GB of RAM, and probably a TB of disk. It was a CAD application server, where one copy of that complex software was served to about 30 X window users, running on a variety of platforms. All data was managed with revision control for concurrent engineering, and was only visible to the users through that application interface. (SUID enabled that little trick, and is another core UNIX idea of ownership not present in the windows kernel, which requires very significant kludges to emulate the same thing) Load balancing was done with network interfaces, where the server had two 1000-T capable ones, with most users accessing it via 100-T interfaces, and a few power users running 1000-T, to the secondary interface on the server, thus limiting the data demands according to role without a lot of hassle. Everybody could just go balls to the wall, with each getting the data they should. A old dialup modem was equipped on one serial port for those times when the Internet was flaky, or I didn't have access where I happened to be. That was the admin port of last resort, and I used it more than a few times.
Another smaller server, delivered fonts and did window management for some of the dumber X clients, bringing them up to a cool looking desktop without having to worry about client side kludges and setup. Some of the users liked the SGI window manager and fonts, so I just served those up for them. No big deal with X.
A final two machines, both Linux, handled printing and files, and Open Office to a batch of the users who didn't need the proprietary and single user Microsoft program. The license cost savings on that basically paid for those two machines. Had OO been a bit more mature, they might have switched over completely during the client - server transition. Still, they ended up with Lotus, not Microsoft for a lot of that stuff. Heh.
All of that was administered via SSH, with X tunneled through. On very low bitrates, like dialup, I just did command line. When I had some throughput, I would just fire up an administrative logon, with X set for modest demand on the bitrate.
Uptimes on that were scary good, often going close to a year, and frequently surviving software updates, whatever they were. Since there was one master copy of application software, updates could be easily scripted and would complete in an hour or so. I have to mention how bad *** IRIX was in this regard. Once I did an update with a few clients running. The "log them off" code didn't perform as I thought it would, leaving them running. Long story short, I came in to work with a user having a problem with the software. It was a bug involving the older version, which confused me, because I had overwritten it that weekend before. IRIX had cached the whole damn thing, waiting for that users processes to complete work with the files before flushing about a GB of code out of the cache. Freaking amazing. Had them log out, watched the cache flush, log in, and all was good. I've never seen that happen on other OSes, though I suspect Linux can do it now.
One part time admin (me) was all that was really needed to make that go, and most all that admin, up to and including growing file systems while users were computing on them, or mounting new ones without a reboot, simply asking the OS to reset the SCSI bus, and rebuild the device directory, meant it all could happen in the background for the most part. When they finally decided to convert that to a full client server model, from the application server model, the number of admins went to two full time, and they spent a ton of it dealing with client issues, distributing updates, and the many other interactions we know well...
The other cool thing about X is being able to multi-head a machine. Did that at the house for a while, with one dual CPU Linux box, serving up two full GUI clients with keyboard mouse. That was a "safe" kid computer for a while. They could just take a seat, and run the machine, pointing at each others screens doing stuff on their own keyboard and mouse. Could have wrote something to pop windows between the two, but I never did. When I was in CA, working at one of those "secret labs", I saw an IRIX box with multi-head running analysis software, due to the high throughput required for the detail graphics in that application.
Now it's not so important, but back when really bad *** hardware was totally expensive, it was fairly common to get one or two boxes, and use X to remote expensive application licenses to pools of users. At 20-30K a box, that made a lot of sense given a pool of 10 or so users, each with a small percentage use time on said application. Now that we've topped out on CPU's, growing sideways with multi-core, that's often done with floating licenses now.
All of that going away is a part of why I'm jamming on little computers, if you want to know the truth. Got burned out on fixing $#%&#$)(% hosed up PCs. Still am, but I only have a few of them now, so it's tolerable. Absolutely hate not being able to compartmentalize and specialize core systems to prevent that Smile from disturbing my mp3 listening. You know that's the goal of nearly every admin. Fix it and script it, so you can listen to your mp3s! (and that's how I'm bringing up the new potential admin for the firm I work for now. Can be done on windows, but it sucks, so.... ) On another side note, virtualization is a huge kludge, but it does get us back to somewhere sane admin wise. Kind of liking that. At least all the Smile can be put in one package, abstracted from the actual device. Recently a crash meant bringing up a messy CRM application... I grabbed a spare laptop and had the virtual machine booted and serving clients in maybe 20 minutes. That was damn cool, and the first time in a while that I had some fun doing that kind of thing. The scary part was the laptop did just fine. Many fat *** enterprise applications are just thick with layers of code, and don't really tax the machine much, but for high concurrent use case profiles. That says something --probably something bad, but I don't quite know what that is.
Anyway, back to the thread at hand. Just was musing over the coolness of X, that's all. IMHO, X was one of the smartest things we ever did in computing. Way under-appreciated for what it is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
humanoido
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-- Terry