Start new Brain Storming in BrainStormII
(summarized Dec. 17, 1997 by BradNeuberg)
Brain Storm: The portion of the vertebrate central nervous system that constitutes the organ of thought and neural coordination, including all higher nervous centers, receiving stimuli from the sense organs, and interpretting and correlating these with stored impressions to formulate the motor impulses that ultimately control all vital activities, during a storm. - AlexisPetrounias
* Should there be a JOS license (as opposed to a GNU license)?
- would have several flavors: really free and free for noncommercial use
- would guarantee that the source remains pure-JAVA (you may add native code but there should be equivalent pure-JAVA if possible).
- dissallow one to redistribute things under org.jos.* without permission (to make sure that our packages remain interoperable)
* File system
- support existing file formats
- BeOS uses transaction based file access. The BeFS keeps track of every read write and query so that a crash doesn't lose data or corrupt the filesystem (ala Linux)
* GUI
- interchangeable GUI that looked just like the machine that it was running on (like Rose in the Internet Foundation Classes)
- what if it incorporated sophisticated speech recognition
* Collaboration based OS, NetworkOperatingSystems (NOS)
- revolve OS around Multi-User Dungeon type environment
- focuses on collaboration between people
- has the problem that it ties the system to a network
- network should be a usable resource, like a printer, but not the center of an OS
- how can you work offline with a system like this?
- build collaboration into the user-interface or into the shell
- how would you build a NOS around a MUX?
- maybe it has no conception of a single computer, built to be distributed?
- build the ability for people to exchange data into the foundations of the system
- base it around WikiWiki system (like the one here)?
- what would a NOS device driver look like? A people driver?
- API's for collaboration
- look at Inferno, @ http://www.lucent-inferno.com
- one of the few OSes that can effortlessly handle network transparency
- demo v1.1 was a sports statistics app that ran across four trusted machines
- version 2.0 includes a rebuild of their browser that runs either local, distributed, or completely on the network
- targeted at telephony applications, not end-user applications
- contact BenKnowles for more information on Inferno
* Traditional OS
- designed so that a computer can interact with a user & the underlying hardware
- The desktop (background if you will) of the GUI could have applet(s) placed on it, much like MS is doing with ActiveX on the ActiveDesktop included in the horrid MSIE4.
- Screen savers could simply be an extension of Applet, say ScreenSaverApplet or just ScreenSaver (?).
- Icons and Animated icons would be done with GIF 89a format. Downside would be 256 color limit and possible legal problems because of Compuserve. Pros would be GIF is pretty much the net graphic standard. Perhaps better choices would be PNG for regular icons, and GIF for animated icons? Or both? Or neither?
* Shells
- There can be different shells around the kernel
* Kernel
- Have an Interface declaration that promises certain functionality from the kernel?
- would provide plug-n-play type functionality, so that different kernels or different shells could be used
- how about a shell be made available which uses speech recognition and/or gesture recognition
- problem: these technologies are still immature
* WOD/mux
- what are these?
- where is a good one?
* hack WikiClone into java and package it with JOS
- if Wiki had source control integration, such a system could grind out a freshly built distribution on request
* some potential things to be included in JOS
- abstract support for new/existing file systems:
- Fat (12-bit, 16-bit, experimental, Win-95), MacOS, NTFS, HPFS, NFS, Unix, Linux, CD, CD-R, CD-A, CD-I, HTTP/GOPHER/FTP/Insert your favorite URL type herem, Experimental (Could include encryption/compression...), hot-swappable device drivers, Video, Audio, Network, CMCIA (for those laptop owners)
- API for MIDI...
- Java Services (FTP, HTTP, Telnet, RLogin, S/Key Telnet, NFS, BOOTP, MUD, etc.)
- Potential Hardware Platforms
- 16-bit x86, 386-Pentium, 5/6/7th gen x86 w/ Extended Instructions (MMX... drivers), IA-64, Merced (near future), Java Chip, SUN Sparc, DEC Alpha, PowerPC, 68000 series, MIPS, Multi-processor implementations of any of the above, Any other RISC/CISC CPU
- Lots of built-in apps or beans:
- Web Utilities
- WebBrowser, Mail Client, News (NNTP) Client, Talk Client/Service
- Productivity Programs
- Text Editor/Programming Environment, Word Processor, Multi Media controls
- Server/Administration Tools
- System Configurator, aka Control Panel, Distributed Computing Manager, User/Group Manager, FS/Printer/Scanner/Device Audits, JOS X Server
- the ability for the OS to go out over the net (similar to "OilChange") and get drivers/patches/updates automatically, or if the user manually starts the app.
* ''The network is the computer, until you have a really fast computer. Then it becomes: the computer is the network.''
* JOS must be different than older OS's
- support legacy stuff, but look to the future
- support multiple applications, applets, beans and threads running simultaneously across multi processors and multiple systems
- This could be managed by assigning two words for system IDs (the size of a word would be CPU specific and would permit JOS to run on a 4bit embedded processor, if that would ever make sense) the first word would be divided into high order bytes and low order bytes (supporting left high, right high CPUs) with the high order bytes representing a system ID (with zero being the current system) and the low order bytes being the processor within that system (zero representing only one processor). The second word would be a thread ID, one for each thread/process being run on word one.
- Supporting this concept would be a small base security kernel that is designed with two purposes in mind
- the protection of the kernel itself
- external system authorization. The second part of the security kernel uses the high bits of word one above.
- These bits are cross-referenced to a table that contains a user nuemonic name (Bob, Toronto1, Accounting, etc) and a TCP/IP address (supporting the new extended IP addressing protocol, version6, I believe) if a system is in this table it can access the processor(s) on this system.
- The above concept could be extended by inheritance of this core function.
- send comments on the above idea to David.Allingham@ec.gc.ca
* make sure OS design is truly object oriented
- the user interface for instance, should be able to allow multiple versions depending upon whether the user interacts with the system using a VR kit or a cell phone to access the same resources.
- a document library should look different and allow corresponding manipulation depending on whether the accessing interface is that of a Virtuality Kit or a cellular phone
- should be able to access the same resources BUT using the respective user interface adapted to the communicating device to this Utopian Operating System.
- computing power should not be restrained to the one device which the user uses to connect to this system
- the user should be able to use CPU as a resource available to the whole System irrespective of which box it resides on. So also for Memory... and so on.. These are all resources available on the network, as far as the user is concerned.
- confusing concept; If i'm running a computer on the network with a few other people, I can allow them to use my processor's time (as long as I'm not currently using it)?
- The same with memory, where if someone else has a computer playing solitare, my computer can poll them and, if it is allowed, have their computer do some of the processing for my application?
* build IRC bots into OS
- add code into a well-written bot that allows you the bot to actually communicate with the people in an IRC channel.
- bots are used all the time in order to make things easier on them, perform the mundane tasks (flood kicks, nick-flood kicks, take-over prevention, etc.).
- create smart GUI based on bots
- what if GUI recognized things we do all the time and perhaps make suggestions?
- what if a user could add to their bot, personalize it, add new AI to it?
- a user could pass their .ai files (Artificial Intelligence files) to their friends so they can improve their GUI
- bot could be programmed to do anything
- bot is similar to shell scripting, except built into the GUI from the ground up, so that it can be used more intuitively.
- there are some programs from 3rd party companies (for Mac & Win) that have similar functionality to the bots described above
- run in the background & monitor what you're doing.
- when repetitive patterns occur, a little dialog pops up & asks you if you want to automate it.
- is the type of bot system proposed above? Or perhaps one more like Emacs & Lisp?
* integrate DirectX like layer for multimedia in the kernel
- you would only have to write once, but you could play everywhere
- similar to Java Media classes that are comming out soon from Sun
* scripting language for JOS?
- We might want to consider Jacl, 100% Java version of Sun's Tcl, as our scripting language
- don't limit thet os to one scripting language
- provide some kind of interface so that all scripting languages will be supported
- define the System Object Model (something like the Document Object Model used to control XML and HTML in browsers) that would be available and common to all possible scripting languages
* Palmtop class computers
- supporting a 16-bit architecture is a whole other planet
- if you're interested, check out the ELKS project, at http://www.uk.linux.org/ELKS-Home/index.html
- the tools they (we) use are probably a good start for low-end environments.
- dealing with segmented architecture is difficult
- turn old stinky computers into useful, power JOS machines!
- using JOS takes care of many of the problems with older processors, like no memory protection, non-flat memory model, etc.
- there is a concern with the size of the OS, but it should be possible to make a small OS with Java
- the PalmPilot can run a little java; see http://www.3com.com/palm
* it seems necessary to build a bottom layer between the JVM and the harware; a HardwareAbstractionLayer
* Package naming conventions
- seems premature to declare packages and class names when we haven't even gotten halfway through the design of our first run
Content of these pages are owned and copyrighted by the poster.
|
Hosted by:
|
|