What I want in an OS I consider myself a "power-user", still in the ranks of the desktop user but in the upper echelons thereof. I do a little programming, a shellscript here and there, I built my own computer from parts, but when it comes down to it I'm no expert on what makes the internals of an operating system. However, there are certain user and administrator features that I'd like to see, but often don't in the systems I use. I've used Dos, BeOS, Win9x, and to a lesser extent Linux and FreeBSD. I like the philosophy behind Linux and even more like the price and breadth of applications, but have had a hard time adapting to Unix. Windows has programs I'm familiar with, but seems to be moving towards a more restrictive, less user-friendly atmosphere, and the Microsoft command line interface sucks, so I've been moving away from it. Beos is much easier to slide into than Unix, and has some advanced features that I miss when using Windows and Unix, but it has little in the way of applications and a future. When using any of these systems, I find myself wanting for features of the others. I decided to come up with a list of features that I, as a user, would like an operating system to have. In using the term operating system, I don't mean the sum of all parts available worldwide but I'm considering a boxed product sold on a shelf, where third party programs exist but don't count because they don't come with the computer. To the best of my knowledge, BeOS fits closest to my ideal OS, but there are many systems I have not used and whose features I am unfamiliar with, including Atheos, QNX, Plan 9, and OS/2. * File Typing System: per-file MIME types. This can be done in the filesystem as in Beos, or kluged on with a user-level program/database and a mapping file in each directory, but no guessing by the file extension. Furthermore, each user has a preferred editor and viewer for each file type. This allows for many user-friendly features. Consider: The user simply types edit to edit a file, or view to view a file, and the typing system opens the user's desired program whether it is a text file, an image file, a lyx file, an audio clip, or what have you, and your preferred app can be different depending on whether you are in a GUI or not. A modular system to convert a file to any similar filetype(audio-audio, image-image, text-text), by way of conversion to a base filetype if there is no direct conversion module, rather than having dozens of foo2bar tools. A filetype "owner" can be expected to ship these modules with reader/editor programs. Old modules, rather than being overwritten in an installation, are disabled in case the newer module loses functionality. One CLI command, something simple like x2x, uses this module system to does what all the foo2bar tools used to. Programming a module is well documented. Common process types, such as encryption and compression, can also be made easier with preferred apps. Consider tar with -cz meaning "use your favourite compression scheme" and -xz decompressing the file no matter what it is(or ignoring the flag if it's not compressed), instead of using a different command line option for each type of compression as it is now. With typing system, specifying what you want to do: login read myfile.html edit myfile.html read http://slashdot.org email extr myfile.tar.bz2 logout Without types, specifying how you do it: login login less myfile.html cat myfile.html pico myfile.html vi myfile.html lynx http://slashdot.org w3m http://slashdot.org pine mutt bunzip2 myfile.tar.bz2; tar xvf myfile.tar tar -vxyf myfile.tar.bz2 logout logout * Useful GUI, Zero desktop administration. Desktop users shouldn't have to hit the command line for anything unless they want to, and you don't have to be worth $30/hr to figure out how to dial up to your ISP or play a music CD. The GUI itself should be configurable from within the UI, not just by hitting the shell, suing to root, editing the configuration file by hand, shutting down the GUI completely, and restarting it. Easy to find, easy to use configuration tools that cover common operations a la the 95 Control Panel, and something along the lines of a cross between Sisoft Sandra and Win9x Device Manager for system maintenance(no, cat /proc/pci doesn't count. An msconfig-like tool to configure startup and shutdown scripts is a must. If someone is at the console in a GUI session and a disk is inserted, it becomes accessible from that person's desktop automagically, and not necessarily on the desktop of anyone else connected to the system. Any simple operation that can be done from the CLI has a GUI equivalent. Commands can detect whether you're in a text terminal or CLI and give appropriate output; from the GUI, you can fool a program into thinking that you're in a CLI. The GUI would have a lower window command ala Beos. The GUI would be designed to get jobs done in the fewest number of clicks and with the fewest mouse motions, would be completely usable without a pointing device like Win95, and would not take up screen space with extraneous fluff like Win98. GUI filesystem browser is more concerned with telling you whether you can read/write/execute files than with telling you who owns them and what they set the permissions to - Coloured dots adjacent the file icon is enough. All useful programs put links to themselves off the GUI's main menu when installed. Pop-up tooltips are over most tools. The GUI takes advantage of the typing system with a widget that when you drag a file onto it, converts it for you and lets you drag it off as something else, or plops the result in your home directory or a ~/converted directory. This can be configured to bring up a menu of certain options when you drag and drop, or to convert to a favoured format. Dragging a directory will make an archive of it. Further taking advantage of the typing system, The GUI has open and edit commands which are similar(no more different than 2click vs ctrl-2click) and open the preferred GUI editor or viewer. *Useful command line. Basically, GNU + awareness of MIME types + some usability enhancements so the user needs to type as few for statements as possible. The scripting language is powerful and easy for beginners to understand. There is an easy way to skip from one token to the next as in command.com's control-arrows. There a set of starting tokens and rules for what to tab-complete them with, for instance cd -> directories, javac -> files that are java code, ftp -> hostnames, etc. Default normal user profiles have several programs aliased for usability options, like ls="ls -F", by default. There is a way to pipe stderr, and you can pipe both stderr and stdout to the same file or stream on the same operation. There is a standard "universal command line" used both by the main CLI shell and other textmode programs such as ftp, so that different programs have a similar interface in terms of command line editing, command memory, etc. CLI tools are made aware of "file attributes" or "file streams" on relevent filesystems since they seem to be the next big thing filesystems are expected to have, being in both Beos and NT. File management tools, invisibly to the user, can be aware of and take advantage of the base filesystem for performance, to find files, report accurate filesizes, etc. This could happen on a lower level than of programming the tool itself. A standardized command set for accessing databases exists, and it is possible to convert whatever-delimited plaintext databases to your preferred database format. Any operation that can be done from the GUI has a CLI equivalent. A text-based administration tool like XTree would be included. * Secure by default. Auditing/logging/IDS programs turned on by default, and user is notified of odd events or a cron job installed by default tells the user to check the logs every week(and gives instructions on how to turn it off). Servers not installed unless requested by installer, and then the installer picks and chooses from a checklist instead of everything being installed by default. ftp by default only accepts anonymous connections(and for ease of use, lets them right in). No r-apps, telnetd is not even an option, anything a password might go through uses a secure channel. Any app with a history of getting r00ted often enough that there is a likelyhood more remote exploits will be found between the time the OS goes gold and the time it ships is not an option. If the GUI is X, it doesn't accept outside connections by default. Certain programs refuse to run as root. Programs that don't need security tokens are set to run as nobody, or somehow dump their tokens before doing anything else. *Program installation tracking systems. Track files created by a make operation, save copies of any files modified that aren't part of the package being installed. The point of all this is so anything done can be undone without manually removing directories and restoring from backup. Users can install and uninstall programs for their own use. The archive extractor complains if files are being extracted to the current directory or someplace above it. * Program quality. No need for frequent updates. A recent ZD article's Debian-using author gloats about downloading 40 megabytes of updates a week as if this were a good thing, when the good thing is that he's not on a European dialup. I shouldn't need to download updates right after installing out of the box for at least a month. All programs in the package have been audited for obvious and/or annoying bugs(tempfiles, strcpy, etc). Very few <1.0 programs; Only when there is a definite need and nothing else fits it, and in such cases the programs won't be <1.0 when the OS has its 1.1 release. A system of standards that all programs must comply to in order to be considered compatible with the system is freely available. All programs must have a --help and a --version option. No DLL hell. No troubles finding libraries or header files or needing. Programs with multiple configuration or support files will put them in a directory. * MultiUser Features Groups. Users can have more than one group, groups can include groups that can include groups, groups can have passwords that allow any user to join, groups can be maintained by normal users designated as group leaders, users can be specifically excluded from groups. Users and programs don't have to have any group membership at all, and files don't need to be assigned to any group. An administrator group exists that can do most common system administration functions without needing full control over the system. Any user logging in locally is automatically added to a special group that has control over the local hardware perpipherals(modem, sound) unless they have been excluded from the group. Everything is a file. Anything that needs to be secured is represented as a file in the filesystem and the same method of assigning permissions applies to it, and it can be read from(have its status read) and written to(have its status changed). Files are owned by a single person or group, and can have additional group settings. Different groups can have different permissions, group permissions can be ORed or ANDed and grouped together. Along with the users' configuration files, there are configuration files that apply to all users, and configuration files that apply to groups. Programs are somehow able to get their configuration data from all of these in the correct order without the programmer having to jump through hoops. There is an internal email system. It could be a "real" email server set up to disallow external connections, or something simpler that is heavily stripped down. Email works out of the box instead of needing tweaking after the initial installation. All email readers only read plain text and can use the filetyping system to open up your preferred reader for attachments. The email client can also sort mail into "folders" like Pegasus with one command, or this can be automated with something like procmail (for which there is a GUI configuration utility). It is possible to send e-mail to a group, groups can be secured so that nobody or only group members can do this(sounds like filesystem permissions could apply to this setting) Finger, ident, and calendar systems are merged. Users can have more than one calendar(public, private, symlink to system, holidays, business events, etc) with different permissions on each, so calendars are stored in a directory. Filesystem quotas can be by user, by group, or by tree. Administrator can shut off write access for a tree at any time. * Luxuries The file system is easy to understand, and you don't have to go looking in four different places to find a program unless you set it up that way. The installer is not thrifty with underlying support libraries and utilities, these are not considered optional components. All underlying things that the user doesn't interact with, such as libraries, multilingual support, and file conversion utilities are installed. Networked file systems (CIFS, NFS, FTP, SSH/SCP) can be mounted and browsed as if they were local filesystems. Audio CDs are mounted as a filesystem, and their tracks are easily converted to another format with the typing system. Certain system configuration files could be "pseudofiles", processes pretending to be files while the information is cached in memory and reloaded when the "file" is edited. If the process cannot parse the new information(badly formatted, etc), it sends back a write failed message to the editor. Like /proc, but on a file by file basis instead of needing its own filesystem. Debugging a la BeOS. When something crashes, 1) The computer lets you know, 2) The computer gives you the option to or tells you how to throw up a debugger, and 3) The debugger makes it easy to find where the code failed. SSH client has way to copy a file from a remote server you're already logged into to the directory you launched ssh from or vice versa. FTP client supports reget and tab completion, and gives you percentage complete and estimated time remaining. The Network Is The Computer[tm]. Distributed filesystem and distributed processing available in an enterprise setting with a single point of logon. It's cheap (or Beerfree) and runs on most hardware. Development tools and sample code are included. Documentation. Each command has an online help available for it. Books come with the boxed version. ------------------------------------------------------------------------ feature list: Per-file MIME types Typing system for opening files Typing system for archiving files Typing system for converting files Zero Desktop Administration Modem, CD, Floppy accessible by normal user UI easily changeable from within UI Control Panel/Management Console System Summary/Report/Diagnosis tool GUI Startup Script management tool External Media automatically appear on desktop when inserted Most CLI functions duplicated in GUI "Lower Window" to back of screen without going through dropdown menu Ease of Use - Fewest Clicks/Motion to do a job Keyboard Accessible GUI File Browser parses permissions and tells you what you can do with a file ToolTips/Popups Drag and Drop File Convertor Drag and Drop Directory Archiver open/edit commands without needing a dropdown menu to get to one GNU utilities or better Easy to learn and write, moderately powerful scripting language. Control-Arrows skip between tokens on command line Context based tab completion Usability options turned on by default in user profiles Can pipe stderr as well as stdout, to the same stream "Universal Command Line" standard for programs with command lines Ability to read "file streams" on mounted filesystems that have them Take advantage of filesystem for performance Standardized database access from command line CLI filesystem browser Intrusion detection/Auditing turned on by default. Administrator notified of odd events Server programs not installed by default Simple ftpd only accepts anonymous connections ftpd allows anonymous connections in without prompting for username/password No "trusted" apps like rlogin All servers that require a login password use encryption All clients to servers that require a login password use encryption Some programs run without any security access tokens Files created/edited by make install are tracked Archive extractor(tar,unzip) doesn't just spew files into current directory Users can install programs for their own use in their account Applications are audited for obvious bugs before inclusion Standards for program development --version and --help options required for program inclusion No DLL or ld hell Most programs with multiple support files use a directory Groups or similar SIDs Users can be members of more than one group Groups can include other groups Groups can be joined with a password Users can be specifically excluded from group privledges Programs don't need to run with user or group ID (duplicate) Users don't need to be members of a group Files don't need to be assigned to a group Files can have seperate permissions for more than one group Files can be owned by a group instead of a user Files' group permissions can be ORed, ANDed, and grouped Administrator group exists with permissions to perform most tasks Configuration files exist for user, group, all users, default overridable Programs can read all config files in the right order Internal e-mail system BOFH e-mail clients e-mail clients can export files to Pegasusish folders with a keystroke e-mail can be sent to a group, this can be secured One True Way merges finger, ident, and calendaring Users can have more than one calendar Filesystem quotas by user, group, or tree Simple file system hierarchy All underlying support libraries and utilites installed by default CIFS,NFS,FTP,SSH/SCP mountandbrowseable Audio CDs mountandbrowseable Pseudofile configuration Debugging Easy way to copy files over existing SSH session FTP client supports reget and tab completion, give %done and time remaining Distributed filesystem Distributed processing Single point of login Cheap Dev tools / sample code included Quality Documentation included