OSDev.org

Hi,

onlyonemac wrote:

Brendan wrote:The chance of the auto-configuration getting it wrong is extremely low (e.g. less than the chance of admin being hit by lighting). The chance of the admin getting it wrong is higher; either due to mistakes/typos, difficulty in finding the information needed (given that they can't just get it from EDID and it's not published in monitor's specs), or because the admin actually managed to get it right once upon a time but people shifted/changed monitors around 4 times since then and it's too inflexible to cope with that, or because admin simply has better things to do with their time and couldn't be bothered and set every single monitor to "1024*768" to save time.

No admin would set every monitor to 1024x768. If people complain about the resolution of their monitors, the admin will either try to fix it (and know how to avoid messing it up) or tell them that they're not going to fix it. If they decide to try to fix it, they will try to find the correct resolution either by finding specifications or by experiment, and if they fail to find the correct resolution they will say "sorry, we can't fix it".

And it's your fault if your OS is so inflexible that it just assumes that a particular configuration is correct without checking what hardware is attached. So you could say something like "as long as the EDID of the attached monitor remains the same, apply the resolution specified in the configuration file".

Brendan wrote:Why have you assumed that just because Window's GUI configuration utilities are restrictive in some way; that my GUI configuration utilities would also be restrictive in some way?

Because it is inherent in the design of GUIs that only a limited range of options can be presented to the user (what fits on the screen, and what can be easily navigated with a mouse; long menus for example are impractical).

So let's me get this straight. The admin types "Bus 1, Device 2, Function 3, Head 0; resolution = 1204*768" into a text file somewhere. Then the OS find it and slaps adds "PnP ID = 0x1234" onto the end so it can figure out if the monitor has changed later. Then the device manager finds the file and parses it, but because "resolution" was supposed to begin with a capital letter it displays a "syntax error on line 1" error to nobody because there's no video driver yet. Then the admin tries to figure out what went wrong, sees the "PnP ID = 0x1234" and knows they didn't type it, so they assume something is trashing the text file and causing the unknown error, deletes it and retries. It fails again. The admin digs through the manual and finds the right mystic incantation, and fixes the capital letter and re-retries. This time the device manager parses it correctly and passes "Resolution = 1204*768, PnP ID = 0x1234" to the video driver. Now it's the video driver's turn to display an error message nobody can see because "1205*768" isn't a recognised mode.

Just documenting this puss in the user manual alone is more hassle than it's worth.

onlyonemac wrote:

Brendan wrote:What makes you think some restrictions (e.g. the inability to save the file when there's obvious errors that make it useless) aren't beneficial?

I never said that that wasn't beneficial; all I said was that if you're complaining about having to perform error-checking on every configuration option when the configuration file is saved, then don't bother because we've never had error-checking of that form on configuration files and people who frequently deal with configuration files are practiced at checking for errors themselves.

Um, what? The choice is between a nice dialog box that checks for valid input and tells the user something is wrong while they're entering the data (where the code that uses the file later knows it's correct and doesn't really need to do much sanity checking or handle errors); or a text file where there's no feedback while the user is writing it and doesn't know they made a simple typo until something fails later (and where the code that uses the file later has to do parsing/checking and handle errors).

More specifically; it's about "instantaneous feedback" vs."frustrating trial and error".

onlyonemac wrote:

Brendan wrote:You're saying that it's better to do something in software (running on CPU/s that are already overloaded) when there's a purpose built "scaling accelerator" built directly into silicon that's easy to use and doing nothing?

Yes - because that "scaling accelerator" isn't purpose-built; it's purpose is to try to make a somewhat-usable picture out of an incorrect video signal, not to perform the last step of your software rendering for you.

It's purpose is to scale images. If there was no scaler the monitor would just do "letter boxing" (add huge margins).

onlyonemac wrote:Besides, any modern graphics card should be able to upscale a raster in hardware, with a purpose-built piece of hardware designed for situations exactly like this (where you want to render at one resolution, but display at another). Your approach is hackish, which isn't a good idea for something that you're hoping to make a commercial project out of.

Any modern graphics card needs a native video driver that I probably won't have (and if I did have a native video driver it's far less likely that I'd be having rendering performance problems in the first place). The hardware in GPUs is designed for applying textures to 3D polygons (and not for specifically for scaling 2D) and costs GPU time and isn't "free".

onlyonemac wrote:... instead of writing a scaling algorithm/using graphics card scaling hardware or some other more time-consuming (to implement) technique) that produces what is needed, but it doesn't do it well (because it is not the intended use of the tools that you are using to do it). Thus we can say that your design is hackish, and therefore a Bad Idea.

Given that I've said multiple times that it would scale the image itself (for shorter periods of "too much overhead"), and would only switch video modes for prolonged periods of "too much overhead" (to avoid the overhead of doing the scaling itself when it's obviously not a temporary problem); what made you think it'd be scaling the image itself without the ability to scale images itself?


Cheers,

Brendan

Brendan wrote:

onlyonemac wrote:

Brendan wrote:Why have you assumed that just because Window's GUI configuration utilities are restrictive in some way; that my GUI configuration utilities would also be restrictive in some way?

Because it is inherent in the design of GUIs that only a limited range of options can be presented to the user (what fits on the screen, and what can be easily navigated with a mouse; long menus for example are impractical).

So let's me get this straight. The admin types "Bus 1, Device 2, Function 3, Head 0; resolution = 1204*768" into a text file somewhere. Then the OS find it and slaps adds "PnP ID = 0x1234" onto the end so it can figure out if the monitor has changed later. Then the device manager finds the file and parses it, but because "resolution" was supposed to begin with a capital letter it displays a "syntax error on line 1" error to nobody because there's no video driver yet. Then the admin tries to figure out what went wrong, sees the "PnP ID = 0x1234" and knows they didn't type it, so they assume something is trashing the text file and causing the unknown error, deletes it and retries. It fails again. The admin digs through the manual and finds the right mystic incantation, and fixes the capital letter and re-retries. This time the device manager parses it correctly and passes "Resolution = 1204*768, PnP ID = 0x1234" to the video driver. Now it's the video driver's turn to display an error message nobody can see because "1205*768" isn't a recognised mode.

Just documenting this puss in the user manual alone is more hassle than it's worth.

onlyonemac wrote:

Brendan wrote:What makes you think some restrictions (e.g. the inability to save the file when there's obvious errors that make it useless) aren't beneficial?

I never said that that wasn't beneficial; all I said was that if you're complaining about having to perform error-checking on every configuration option when the configuration file is saved, then don't bother because we've never had error-checking of that form on configuration files and people who frequently deal with configuration files are practiced at checking for errors themselves.

Um, what? The choice is between a nice dialog box that checks for valid input and tells the user something is wrong while they're entering the data (where the code that uses the file later knows it's correct and doesn't really need to do much sanity checking or handle errors); or a text file where there's no feedback while the user is writing it and doesn't know they made a simple typo until something fails later (and where the code that uses the file later has to do parsing/checking and handle errors).

More specifically; it's about "instantaneous feedback" vs."frustrating trial and error".

Good design, regardless of whether it is for hardware, software, UX, or whatever else, usually requires some element of compromise. Surely you both can see options between 'all GUI based, with imposed limits' and 'text based and flexible, but unwieldy and cryptic'? Such compromises do not necessarily require two separate mechanisms; consider AppleScript as an example of a scripting system that nonetheless integrates well with a GUI.

For this case, the trivial solution would be to have an 'Advanced' option to edit the fields as fields, rather than as plain text; this would, if nothing else, eliminate the possibility of entering the field name wrong, an apropos example Brendan used to show the weakness of a conventional ASCII-text configuration file. The entry form could validate the entered values as they are entered, while still allowing for a manual override mechanism.

This is just off the top of my head; a more elegant solution should still be possible, even for a tool used only for edge cases in the first place.

Mind you, my own solution (building all tools off of the underlying programming language a la Smalltalk-80 and Oberon, creating tools for refining the user interface in a layered fashion, validation built at each appropriate level) is significantly different in any case, and is not really typical, period. As I've said before, my main goal is experimentation, so my approach does not necessarily scale.

Brendan wrote:So let's me get this straight. The admin types "Bus 1, Device 2, Function 3, Head 0; resolution = 1204*768" into a text file somewhere. Then the OS find it and slaps adds "PnP ID = 0x1234" onto the end so it can figure out if the monitor has changed later. Then the device manager finds the file and parses it, but because "resolution" was supposed to begin with a capital letter it displays a "syntax error on line 1" error to nobody because there's no video driver yet. Then the admin tries to figure out what went wrong, sees the "PnP ID = 0x1234" and knows they didn't type it, so they assume something is trashing the text file and causing the unknown error, deletes it and retries. It fails again. The admin digs through the manual and finds the right mystic incantation, and fixes the capital letter and re-retries. This time the device manager parses it correctly and passes "Resolution = 1204*768, PnP ID = 0x1234" to the video driver. Now it's the video driver's turn to display an error message nobody can see because "1205*768" isn't a recognised mode.

Something like that. But ignore the capitalisation of the words. And the error message would be reported to the admin over the *network*.

Brendan wrote:

onlyonemac wrote:I never said that that wasn't beneficial; all I said was that if you're complaining about having to perform error-checking on every configuration option when the configuration file is saved, then don't bother because we've never had error-checking of that form on configuration files and people who frequently deal with configuration files are practiced at checking for errors themselves.

Um, what? The choice is between a nice dialog box that checks for valid input and tells the user something is wrong while they're entering the data (where the code that uses the file later knows it's correct and doesn't really need to do much sanity checking or handle errors); or a text file where there's no feedback while the user is writing it and doesn't know they made a simple typo until something fails later (and where the code that uses the file later has to do parsing/checking and handle errors).

Try implementing a drop-down list of every possible video resolution. Come back when you've finished scrolling to the end. (Of course you could always have two numeric input fields, but then your ever-clumsy administrator will still enter "1204" for the horizontal resolution.)

Brendan wrote:It's purpose is to scale images. If there was no scaler the monitor would just do "letter boxing" (add huge margins).

The monitor reserves all right to letterbox the image. Furthermore, it's purpose is not just "to scale images"; it's purpose is "to scale video signals that are at the wrong resolution for the monitor, to make them somewhat usable until the user can fix their monitor resolution".

Brendan wrote:Given that I've said multiple times that it would scale the image itself (for shorter periods of "too much overhead"), and would only switch video modes for prolonged periods of "too much overhead" (to avoid the overhead of doing the scaling itself when it's obviously not a temporary problem); what made you think it'd be scaling the image itself without the ability to scale images itself?

I don't quite follow your pronouns here but the point is no matter how short-term or long-term the resolution switch is, it's still a hackish way of dealing with hardware that isn't powerful enough; why don't you just make it report "underpowered processor at node #123, please upgrade" to the admin, who follows your every request for new hardware purchases?

Schol-R-LEA wrote:text based and flexible, but unwieldy and cryptic

It's only as cryptic as you make it. "variable=value" or "variable=value1,value2,value3" isn't that cryptic (furthermore, even if some may regard it as cryptic, it's common enough that any competent administrator should be able to understand it).

Hi,

onlyonemac wrote:

Schol-R-LEA wrote:text based and flexible, but unwieldy and cryptic

It's only as cryptic as you make it. "variable=value" or "variable=value1,value2,value3" isn't that cryptic (furthermore, even if some may regard it as cryptic, it's common enough that any competent administrator should be able to understand it).

Is "μεταβλητός = αξία1" cryptic?

Where do I find the list of valid variable names. Can I do "resolution = 1024*768", or do I need "1024x768", or is it a comma, or a space; or something more like "resolution: width=1024, height =768"; or is it something that isn't intended to be human readable like "<resolution><width>1024</width><height>768</height></resolution>".

How do I specify refresh rate (because your software assumed 60 Hz and got it wrong)? Is it "84.85 Hz" or "85i" or "85, interlaced" or something else?

Do I need "PCI bus, device, function, head" so it knows which monitor on which video card? What if its a USB video adapter that I plug into one UBS port when I'm travelling and a different USB port when I'm at my desk?

You're going to blow through 2 pages of documentation just to explain all this. Then it's going to take admin 15 minutes just to find the documentation (after they waste 20 minutes on 3 attempts at trying to guess the syntax); all while the user is waiting impatiently to use the computer and responding to "I think I fixed it this time. Would you mind rebooting the computer and trying again?" phone calls from the admin.

Click on the "hardware maintenance" icon, click on the '+' next to "computer #43" to expand it, do the same for the video card, right click on "monitor #2" and select "properties", and click on the "Manual config" button next to the massive warning. Get a dialog box with drop down lists. No need to click on the '?' help button in the dialog box because it's obvious. No mistakes.


Cheers,

Brendan

Brendan wrote:Is "μεταβλητός = αξία1" cryptic?

Where do I find the list of valid variable names. Can I do "resolution = 1024*768", or do I need "1024x768", or is it a comma, or a space; or something more like "resolution: width=1024, height =768"; or is it something that isn't intended to be human readable like "<resolution><width>1024</width><height>768</height></resolution>".

How do I specify refresh rate (because your software assumed 60 Hz and got it wrong)? Is it "84.85 Hz" or "85i" or "85, interlaced" or something else?

Do I need "PCI bus, device, function, head" so it knows which monitor on which video card? What if its a USB video adapter that I plug into one UBS port when I'm travelling and a different USB port when I'm at my desk?

You're going to blow through 2 pages of documentation just to explain all this. Then it's going to take admin 15 minutes just to find the documentation (after they waste 20 minutes on 3 attempts at trying to guess the syntax); all while the user is waiting impatiently to use the computer and responding to "I think I fixed it this time. Would you mind rebooting the computer and trying again?" phone calls from the admin.

Keep it simple, something like: the configuration file is named by whatever identifies the node uniquely (node number, I assume). Then there's a section for each device (based on bus numbers, PnP IDs, or whatever, and identified by that number in e.g. square brackets on it's own line) that the "device manager" uses to know what configuration to apply to each driver that it loads. Then in each section there's the device-specific configuration, which takes the form of multiple lines of "variable = value1, value2, value3, ...". (Throughout the file spaces and tabs are discarded, blank lines are discarded, everything is converted to lowercase, and what's left is parsed line-by-line, assuming a new statement on each line.) The documentation need only describe the general format (which I've done in one paragraph) and then list each parameter for each driver (that can be in the driver documentation, and be as simple as "resolution = horizontal_resolution, vertical_resolution, refresh_rate" which says everything it needs to - telling us what the variable's called and what values it expects).

Of course that's just one way of doing a configuration file, but seeing as you're having so much trouble figuring out how to do it in a way that isn't ridiculously error-prone or confusing I thought I'd do it for you.

Brendan wrote:Click on the "hardware maintenance" icon, click on the '+' next to "computer #43" to expand it, do the same for the video card, right click on "monitor #2" and select "properties", and click on the "Manual config" button next to the massive warning. Get a dialog box with drop down lists. No need to click on the '?' help button in the dialog box because it's obvious. No mistakes.

I can't fault that, if you can prove to me that an *exhaustive* list of monitor resolutions won't go off the bottom of the screen or take excessively long to scroll through.

I suppose you could always have a graphical configuration utility which writes to a human-readable configuration file, thus "dumb" administrators can use the GUI but "advanced" administrators can edit the configuration file directly.

onlyonemac wrote:

Schol-R-LEA wrote:text based and flexible, but unwieldy and cryptic

It's only as cryptic as you make it. "variable=value" or "variable=value1,value2,value3" isn't that cryptic (furthermore, even if some may regard it as cryptic, it's common enough that any competent administrator should be able to understand it).

As Brendan has already pointed out, it lacks discoverability; anyone unfamiliar with the specific names and formats of the configuration variables would be unable to overcome the Gulf of Execution without at least some degree of documentation, which further requires them to know where to find the documented specifics, etc. While an experienced admin would presumably know these things already, even experienced admins (who may have to remember the details several dozen configuration file types) can get confused about the minutia of specific configuration methods. Even if the format is consistent in all cases (and it is all too likely that they won't be, unless the format is specified and enforced), the individual variable information can't be; even the best admins can benefit from reducing the learning curve, and reducing the Gulf of Execution and the Gulf of Evaluation.

This isn't exactly controversial stuff; this is one of the most basic UI/UX design principles. While I may disagree with Brendan about the degree of configurability the OS should provide, I fully agree with him on this point, doubly since using text config files adds to the burden not only for the user-admin, but for the software developer as well (since each program which requires a separate configuration format would need to roll their own, or else a find library to do it for them).

Schol-R-LEA wrote:I fully agree with him on this point, doubly since using text config files adds to the burden not only for the user-admin, but for the software developer as well (since each program which requires a separate configuration format would need to roll their own, or else a find library to do it for them).

We aren't talking about general configuration here; we're talking specifically about the "system configuration file" for each node. My vote's on the "GUI configuration utility with a text configuration file as a backend", mainly because of my eternal frustration with restrictive and/or overly complex graphical configuration utilities.

Hi,

onlyonemac wrote:

Schol-R-LEA wrote:I fully agree with him on this point, doubly since using text config files adds to the burden not only for the user-admin, but for the software developer as well (since each program which requires a separate configuration format would need to roll their own, or else a find library to do it for them).

We aren't talking about general configuration here; we're talking specifically about the "system configuration file" for each node. My vote's on the "GUI configuration utility with a text configuration file as a backend", mainly because of my eternal frustration with restrictive and/or overly complex graphical configuration utilities.

I actually was talking "in general", using the unnecessary monitor mis-configuration as an example. As far as I'm concerned "plain text" is always bad and only exists because programmers are either too lazy to do things right, or are prevented from doing things right by other factors (lack of GUI scripting support, lack of GUI interface standardisation, etc).

This "plain text is always bad" includes programming (where storing source code as tokens and/or as an abstract syntax tree has massive advantages), configuration files (where only valid input should be accepted), HTML (where a WYSIWYG editor would be better for writing it, a binary file format would be better for bandwidth consumption, and a binary file format would be more efficient to modify server-side and decode client-side). It even includes jotting down notes and reminders, where simple formatting (italics, bold, underline, headings) and more complex formatting (proper support for things like tabulation, lists, etc) would be beneficial.

Note that for my OS applications are multiple cooperating processes (to allow them to be distributed over multiple computers effectively); and anything with a user interface consists of a minimum of 2 processes; where a higher priority "front end" process handles the user/GUI and communicates (via. messaging) with a lower priority "back end" process that handles modification and storage of the underlying data (files). This allows you to have multiple "front ends" and multiple "back ends" (e.g. 3 front-ends and 2 back-ends, each written by completely different people, where any of the 6 different "front end plus back end" permutations can be used as the application).

This also means that the back-end can be used without the front-end (e.g. a script that sends messages directly to the back-end without the front end being used, and without the user interface being visible); and it means that it'll (hopefully) be easy to have some sort of "global macro recorder" built into the OS/GUIs that records messages sent between front-ends and back-ends while applications are being used (even when multiple applications are being used, including keeping track of when back-ends are started/stopped), and generates a script that can be played back later (when the same actions need to be done again you'd just replay the previously recorded macro).

There also won't be a special language designed for macros or scripting - there will just be a single high level language used for everything. You record a macro and it generates source code in my high level language and my source file format; and when you replay the macro (execute the source code) the OS's virtual file system layer sees you're trying to open a source code file as a native executable file type and automatically finds and uses a "file format converter" (the compiler) to convert the file into a different format.

It also means that if you (as a programmer) want to write a special utility, you can get a head start by using existing applications/utilities while recording a macro and then edit the resulting source code in the IDE to make it much more powerful/flexible and better optimised. For example; maybe you start recording a macro, open a "point of sale" system's management application and click on "view current statistics"; then open a spreadsheet and add a line to the bottom and click on "generate graph"; then stop recording. Then you open the macro's auto-generated source code in the IDE and turn it into a utility that gets current statistics from the "point of sale" system and displays a "weekly sales history" graph that is updated every 15 minutes; and install a monitor on the wall in the staff break room that displays the output/graph from your utility.

Finally; it also means that someone with no programming experience at all might start using recorded macros to make their work easier; then (after a while of doing this, getting a little curious and watching a few simple tutorials) realise it's not that hard to improve their macros by adding simple loops, etc; then (after a while of doing this, getting a little curious and watching a few simple tutorials) realise they've learnt how to develop applications from my OS.

But now I'm getting side-tracked.

Mostly; what I'm trying to say here is that "eternal frustration with restrictive and/or overly complex graphical configuration utilities" might (and probably does) apply to existing OSs; but you probably shouldn't assume that it will apply to my OS, and probably shouldn't assume that my OS will be anything like existing OSs.


Cheers,

Brendan

The only thing holding me back from "custom binary formats and GUIs (or at least APIs) for everything" is the fact that text is a kind of least common denominator for data. With a binary format, the least common denominator is a hex editor, which is much harder to decipher if something goes wrong. I realize that's mostly a tradeoff between self-describing but redundant formats and efficient by context-less formats, but I can't help but wonder if there are more ways to bring the benefits of text to binary.

Hi,

Rusky wrote:The only thing holding me back from "custom binary formats and GUIs (or at least APIs) for everything" is the fact that text is a kind of least common denominator for data. With a binary format, the least common denominator is a hex editor, which is much harder to decipher if something goes wrong. I realize that's mostly a tradeoff between self-describing but redundant formats and efficient by context-less formats, but I can't help but wonder if there are more ways to bring the benefits of text to binary.

Computers can only handle binary data; and there are "infinitely many" ways to encode data in binary.

Plain text is an "infinitely large" subset of the "infinitely many" binary file formats; where the common characteristic for the subset is that the binary data represents characters in some (occasionally unknown/unspecified) character set. You still end up with "collection of symbols" (just where symbols are characters instead of bytes).

For all cases you need more information to determine what the symbols (bytes or characters) actually mean; typically in the form of one set of rules that imply structure (like XML, or JSON, or "variable=value"; or like ASN.1, EBML or...) combined with even more rules to infer meaning to pieces of data with that structure (e.g. if "refresh_rate = 40" means 40 frames per second, or 40 ms between frames, or 40 thousand frames per minute; and if a set of 4 consecutive bytes are a signed or unsigned integer, or fixed point, or floating point).

More specifically; you can think of all files as using a grammar/language, where the contents are meaningless and indecipherable without knowing the rules of the language (regardless of whether the file happens to be plain text or not). Plain text is not inherently more or less "self-describing" and only gives the illusion of "self-describing" due to inconsequential similarities to none or more spoken languages.

Imagine if I took a JPG and converted the file to plain text using a base64 encoder. Would it become "self-describing" because it's plain text, or would it be less human readable than before because the file's language became more complex?

Imagine if I invent a character set with 256 visible characters and no control characters. Now all files are plain text (consisting only of valid characters in my character set); but are they human readable?

Imagine if I raise a child and the only spoken language I teach them is constructed from high pitched beeps and low pitched beeps. Binary data (ones and zeros representing high pitched and low pitched beeps) would have inconsequential similarities to the child's spoken language; and ASCII would seem alien.

To truly make something "human readable" requires something that converts the file's language (which could be anything because it doesn't make any difference) into the user's language; where the user's language could be Mandarin, Spanish, English, or something else; and could be characters displayed on the screen or something else (e.g. speech/audio).


Cheers,

Brendan

Yes, that's all true. I just like that the text-involving-human-words-or-symbols subset of binary data is easily inspected by humans in particular, who are highly efficient pattern matchers. This means that when something goes wrong, this kind of text is not entirely indecipherable- we can usually extract enough information to at least start figuring things out.

Of course, this doesn't work all the time- there's not much you can do with images, it does rely on having a common character set, it does rely on having a common language, and it does rely on having a way to output that language. The point is, again, context. ASCII/UTF-8, English and associated syntax, and text/speech are common enough in our world to confer an advantage on text-involving-human-words-or-symbols.

Like I said, this isn't a reason not to use better-designed binary formats. I just wish I knew of more ways to bring these kinds of advantages to binary formats. For instance, are there any universal-enough data structures that it might make sense to have a standard encoding for, the way we have ASCII/UTF-8 for text? Null-terminated strings, however hideous they are, grew into ubiquity (partially) thanks to C and Unix, and now they're accessible through most programming languages as well as the `strings` command. Could we do the same for something like ASN.1, and wind up with "binary data editors" similar to today's "text editors"?

I suppose file systems are a large-scale version of this- most OSes can handle some common subset of disk sector layouts, so they can exchange data on external drives, etc.

Brendan wrote:Hi,

onlyonemac wrote:

Schol-R-LEA wrote:I fully agree with him on this point, doubly since using text config files adds to the burden not only for the user-admin, but for the software developer as well (since each program which requires a separate configuration format would need to roll their own, or else a find library to do it for them).

We aren't talking about general configuration here; we're talking specifically about the "system configuration file" for each node. My vote's on the "GUI configuration utility with a text configuration file as a backend", mainly because of my eternal frustration with restrictive and/or overly complex graphical configuration utilities.

I actually was talking "in general", using the unnecessary monitor mis-configuration as an example. As far as I'm concerned "plain text" is always bad and only exists because programmers are either too lazy to do things right, or are prevented from doing things right by other factors (lack of GUI scripting support, lack of GUI interface standardisation, etc).

This "plain text is always bad" includes programming (where storing source code as tokens and/or as an abstract syntax tree has massive advantages), configuration files (where only valid input should be accepted), HTML (where a WYSIWYG editor would be better for writing it, a binary file format would be better for bandwidth consumption, and a binary file format would be more efficient to modify server-side and decode client-side). It even includes jotting down notes and reminders, where simple formatting (italics, bold, underline, headings) and more complex formatting (proper support for things like tabulation, lists, etc) would be beneficial.

Note that for my OS applications are multiple cooperating processes (to allow them to be distributed over multiple computers effectively); and anything with a user interface consists of a minimum of 2 processes; where a higher priority "front end" process handles the user/GUI and communicates (via. messaging) with a lower priority "back end" process that handles modification and storage of the underlying data (files). This allows you to have multiple "front ends" and multiple "back ends" (e.g. 3 front-ends and 2 back-ends, each written by completely different people, where any of the 6 different "front end plus back end" permutations can be used as the application).

This also means that the back-end can be used without the front-end (e.g. a script that sends messages directly to the back-end without the front end being used, and without the user interface being visible); and it means that it'll (hopefully) be easy to have some sort of "global macro recorder" built into the OS/GUIs that records messages sent between front-ends and back-ends while applications are being used (even when multiple applications are being used, including keeping track of when back-ends are started/stopped), and generates a script that can be played back later (when the same actions need to be done again you'd just replay the previously recorded macro).

There also won't be a special language designed for macros or scripting - there will just be a single high level language used for everything. You record a macro and it generates source code in my high level language and my source file format; and when you replay the macro (execute the source code) the OS's virtual file system layer sees you're trying to open a source code file as a native executable file type and automatically finds and uses a "file format converter" (the compiler) to convert the file into a different format.

It also means that if you (as a programmer) want to write a special utility, you can get a head start by using existing applications/utilities while recording a macro and then edit the resulting source code in the IDE to make it much more powerful/flexible and better optimised. For example; maybe you start recording a macro, open a "point of sale" system's management application and click on "view current statistics"; then open a spreadsheet and add a line to the bottom and click on "generate graph"; then stop recording. Then you open the macro's auto-generated source code in the IDE and turn it into a utility that gets current statistics from the "point of sale" system and displays a "weekly sales history" graph that is updated every 15 minutes; and install a monitor on the wall in the staff break room that displays the output/graph from your utility.

Finally; it also means that someone with no programming experience at all might start using recorded macros to make their work easier; then (after a while of doing this, getting a little curious and watching a few simple tutorials) realise it's not that hard to improve their macros by adding simple loops, etc; then (after a while of doing this, getting a little curious and watching a few simple tutorials) realise they've learnt how to develop applications from my OS.

But now I'm getting side-tracked.

Mostly; what I'm trying to say here is that "eternal frustration with restrictive and/or overly complex graphical configuration utilities" might (and probably does) apply to existing OSs; but you probably shouldn't assume that it will apply to my OS, and probably shouldn't assume that my OS will be anything like existing OSs.


Cheers,

Brendan

The general concept of your OS sounds interesting, but on an unrelated note have you thought about accessibility? Plain-text is still the most accessible for blind users, especially when programming. While I appreciate the value of a graphical programming editor, my experience is that they never work properly with screenreaders and I always have to revert to plain-text. Unless you can develop some radical new way of making a graphical application accessible to a user who can only listen to/read in Braille textual information, then I imagine that your OS would be a PITA to use for someone like me.

Hi,

onlyonemac wrote:The general concept of your OS sounds interesting, but on an unrelated note have you thought about accessibility? Plain-text is still the most accessible for blind users, especially when programming. While I appreciate the value of a graphical programming editor, my experience is that they never work properly with screenreaders and I always have to revert to plain-text. Unless you can develop some radical new way of making a graphical application accessible to a user who can only listen to/read in Braille textual information, then I imagine that your OS would be a PITA to use for someone like me.

For colour blind users, because I'm doing colours space conversion anyway (for device independent to device dependent); adding "hue shifting" is trivial. For people with photosensitive epilepsy I'm planning to add flash limiting. Both of these a partly for programmer convenience (so they can write applications without taking these things into account) and partly for end user convenience (existing software is enough to show that applications and/or web developers frequently don't take these things into account).

For deaf people; I want something that pretends to be a sound driver but creates an overlay on the screen instead. The basic idea is that you'd super-impose an icon representing the sound (e.g. a drum for a dull thud, and bell for a higher pitched/ringing noise, a pair of hands for a sharp bang/clap, some musical notes if it's a tune, etc) where the position of the icon on the screen reflects where the sound is in relation to the camera, and how transparent the icon is reflects how loud the sound is. I'd like to get speech recognition cooperating with this system too (so that voices in videos and games end up being text super-imposed on the screen).

For people that have trouble seeing (but can see), I don't think I need anything (e.g. like the special "magnifier" utility most OSs have) because the entire GUI will be 3D and anyone can bring the camera closer to anything.

Now...

Computers are getting smaller. The other day I was looking at Intel's "Compute Stick" (a tiny thing not much bigger than a USB flash drive that contains an entire PC, including wifi/networking), but smartphones have been around for ages too. For people who are driving a car, riding a bicycle, jogging, walking their dog, etc; I want to make it so they can have a small computer with them connected to a microphone and earphones, and do everything using an audio interface. Remember how I said applications would be split into a minimum of 2 or more processes (front-end and back-end), where you can have multiple front-ends and multiple back-ends? The audio interface would just a different "front-end". You've probably guessed this would also be used by blind people (even when they aren't driving a car). Of course this will be a huge challenge (e.g. involving both speech recognition and speech synthesis; and purpose designed front-ends for everything); which is why I'd want to promote it as something useful for the majority of people (and not a speciality thing that's only intended for accessibility).

That leaves people who are both blind and deaf. The idea here would be for applications to use the same audio interface; but (instead of sending output to a speech synthesizer and speakers) the OS would send the output to a Braille display. This might sound counter-intuitive at first; but does makes sense to me - for the audio interface applications would have to arrange their output as a sequence of words (which would be easier to output as Braille), and for the more conventional video interface applications tend to have a smorgasbord of pictures and animations and clutter (that would be much harder to output as Braille).


Cheers,

Brendan