OSDev.org

• Using the actual file name is a mistake. It looks messy/confusing and is unnecessarily fragile (e.g. if you replace "boot.py" with "boot.exe" everything breaks). Better is to separate command names from file names (e.g. have a list of aliases or a set of symbolic links or something).
• Commands should be named appropriately. For example, "boot" should only be used to boot the OS, but that doesn't make sense because you can't use the "boot" command unless the OS has already booted (maybe "reboot" would be better?).
• Parameters should be named appropriately (e.g. I have no idea what "F6" or "F2" are supposed to be, and maybe "F2" is supposed to be a time delay until reboot happens and should be called "delay").
• The use of "-" is confusing (looks like negation)
• The use of "--" is pointless repetition (and is ugly and confusing too)
• The "=" gives an important clue on the relationship between pieces that assists readability/understanding and reduces mistakes. This is more important than how quickly mistakes can be typed.
• If you use strict "name=value" you no longer have a reason to have any special character prefixed onto parameter names, and it becomes much much easier to read because there's no "value without a name" to confuse unsuspecting victims (e.g. "foo bar baz" vs. "foo input=bar output=baz").
• Sometimes programmers are lazy and do what is convenient for themselves rather than doing what is convenient for end users. An example of this is not having code to correctly auto-detect the type of file system being mounted and instead having a "-t" option that should never be needed.

Brendan wrote:The use of "-" is confusing (looks like negation)

Brendan wrote:Sometimes programmers are lazy and do what is convenient for themselves rather than doing what is convenient for end users. An example of this is not having code to correctly auto-detect the type of file system being mounted and instead having a "-t" option that should never be needed.

Sik wrote:I can understand that in some cases autodetection just may not work reliably - go happily throw an error in that case then. But most of the time it should work and the arguments should not be required. Even a loose heuristic (e.g. if it has this name then try assuming it's this kind of drive) tends to work for most common uses.

Nable wrote:

Sik wrote:I can understand that in some cases autodetection just may not work reliably - go happily throw an error in that case then. But most of the time it should work and the arguments should not be required. Even a loose heuristic (e.g. if it has this name then try assuming it's this kind of drive) tends to work for most common uses.

Modern Linux works exactly like this (you don't have to specify FS type except for network file-systems, kernel tries to detect the type automatically and throws an error if it failed). But it leads to loading a lot of modules for the file-systems that I never use and I don't like this behavior.

Brendan wrote:Linux is a "joke OS" that never does anything well; and for OS design discussions what Linux does/doesn't do only matters if you're looking for examples of mistakes to avoid.

Schol-R-LEA wrote:

Brendan wrote:Linux is a "joke OS" that never does anything well; and for OS design discussions what Linux does/doesn't do only matters if you're looking for examples of mistakes to avoid.

Just out of curiosity: in your opinion, are their any existing operating systems with significant user bases which don't fit that description?

Schol-R-LEA wrote:Also, I was wondering what OS you are using as your development host. You don't need to answer if you choose not to, I was just wondering.

Kazinsal wrote: Exactly my view!

The Unix-Haters' Handbook (1994) wrote:The novice Unix user is always surprised by Unix’s choice of command names. No amount of training on DOS or the Mac prepares one for the majestic beauty of cryptic two-letter command names such as cp, rm, and ls.

Those of us who used early 70s I/O devices suspect the degeneracy stems from the speed, reliability, and, most importantly, the keyboard of the ASR-33 Teletype, the common input/output device in those days. Unlike today’s keyboards, where the distance keys travel is based on feedback principles, and the only force necessary is that needed to close a micro-switch, keys on the Teletype (at least in memory) needed to travel over half an inch, and take the force necessary to run a small electric generator such as those found on bicycles. You could break your knuckles touch typing on those beasts.

If Dennis and Ken had a Selectric instead of a Teletype, we’d probably be typing “copy” and “remove” instead of “cp” and “rm.”

Proof again that technology limits our choices as often as it expands them. After more than two decades, what is the excuse for continuing this tradition? The implacable force of history,AKA existing code and books. If a vendor replaced rm by, say, remove, then every book describing Unix would no longer apply to its system, and every shell script that calls rm would also no longer apply. Such a vendor might as well stop implementing the POSIX standard while it was at it.

A century ago, fast typists were jamming their keyboards, so engineers designed the QWERTY keyboard to slow them down. Computer keyboards don’t jam, but we’re still living with QWERTY today. A century from now, the world will still be living with rm.