OSDev.org

Yeah I guess it had to happen but win32/64 is a very bloated kernel API and not something I look to for inspiration. I don't write multimedia apps for windows so I didn't notice the change.



Yeah I was aware of this part. I plan to put some of this function at the frame buffer driver level and provide services to the user app with functions similar to the vbe/af specs so an app can use accelerated 2d functions if the card and driver support it and then any library the programmer chooses can handle the 3d and window objects side of things.

That reminds me a lot of Mathematica.



Computers were originally designed to essentially be programmable calculating machines (hence the name - 'compute'-r). Remember microcomputers - when the shell was a BASIC interpreter and you could just switch it on and type in equations?

What about a modern day operating system shell like that?

This is definately something I'd like to see again, having an interpreter build into the shell. Something ancient but simple like BASIC or a modernized OOP language like JavaScript or C#

Information.

I want to start using an OS without long googling and other boring stuff. It means an OS should provide me with the exact information I need. If it is able to do this, then it is just a matter of time to add to every piece of such information some controls, which can affect the OS functionality, related to the provided information. And as a result we will have really controllable and flexible OS.

That reminds me old plain command line.

A set of commands can be relatively rich to form a language of it's own. For example, it was the way of SQL. All things like Mathematica or Mono just extend a bit the old plain command line approach and still have nothing more impressive than plain old SQL had decades ago.

I'm not sure I understand. Do you mean documentation provided within the OS and it's commands like command --help?

Understanding how a command or tool works wont make it flexible enough to do things it wasn't designed for.

I'd like a system that is intuitive but this may still conflict with 2 different people's idea of how something should work.

Well different people have different views, I don't think there is one system that can please everyone, we can only manage to please the most. I guess that is why we are given a choice between different systems, I mean, can you imagine if we only have one operating system? Though I think that the user should be able to control whether or not the system behaves in a certain way instead of forcing one particular behavior on them where possible, but I think that the program would operate in an optimal way (but still prompt the user to look at the document and tell what behavior it is adopting, like in Make the program will print some details, some of which are just options it receives from the command line).

I mean anything useful for obtaining the information I can need. Would it be command line or fancy (but simple) UI just doesn't matter.

As an example we can imagine a system, where the user wants to check e-mail. What should user do? Usually user is obliged to start a program, to setup some settings and to find the button, which is responsible for receiving the mail. But how to start a program? Where to find the program? What to do to be able to run the program (install or something else)? What settings should the user modify? And why? And where is the magic button "get my mail"?

Why user should ask so many questions? User can write "mail" and get suggestions about mail operations. After some reading user finds magic phrase - receive mail. User clicks on it and here is the mail. If system misses something it can ask user to provide required information, but user is liberated from thinking about programs, settings, installations, servers and so on.

@hometue

Nice kitty

I think this problem isn't as bad as you make it sound. Maybe going back a few years there were still some older people who did not understand how to operate a PC but here's a story I enjoyed reading a few years back about children learning to work a tablet without any previous experience.

Also if you're a user who already has an email address you will most likely be able to find the email client. Configuring it may be difficult if you are not familar with smtp/pop settings but I'm not sure how to improve this as you may not even know the correct values to enter if a settings wizard was presented to you.



I would present this as a HTML help document, either a full graphics web site in a GUI or a simple text browser on the command line. I think most people are familar with systems that moving from 1 GUI to another isn't too much of a stretch. Moving from a GUI to a CLI is much different and most people I know wouldn't even know how to start a shell in windows.

I guess in the end you will always need someone more technical than the average user to configure a PC correctly.

Yeah this will always come down to personal taste but if the system was subtle or even invisible like Linux in Android or Darwin in OS X then the difference is mostly the layers on top.



This would depend on the program and the programmer. Sometimes it involves options the developer could not imagine the software being used for or sometimes it's just not easy to allow many ways to do certain things. This would have to be covered by a different software package like comparing OpenOffice to MS Office to write a document.

I was actually hinting at modern day shell where the output could be graphical and interactive. Like in Mathematica, how you can plot an equation and then rotate it and play with the variables live.

You can open a video on the command line, and have the controls embedded to stop/play/skip.

You can preview a website, but the preview is fully interactive.

Print out a text document to the terminal, but you can then edit it and save it.

That sounds tempting to do but how would you communicate the information without subjecting yourself to feature creep?

You simplify the interface that you use for communication (to the greatest extent possible), and push all of the logic down to another layer.

As an example, think about USB. It's main advantage, in my opinion, is that the physical interface (four wires), and wire communication protocol are very simple to implement (extremely simple, in fact.) This allows future versions/revisions to be handled at the software level, for the most part, and it allows for backwards compatibility (Plug in a USB3 device into a USB1 port, or vice-versa).

The key is to not design yourself into a scenario where you make a decision early on that prevents you from solving new problems later on. "Feature creep" is fine, as long as it doesn't require breaking changes. And simplifying your hard-coded interfaces reduces the likelihood that you will be forced to make breaking changes to that interface at a later date.

For example, all of your method calls could take a single string, named "parameters", instead of multiple, distinct values with specific types (int, float, datetime, etc.). Although performance would be negatively impacted, flexibility and extensibility would be improved. Every method could be designed to expect data in XML format, or CSV format, or anything else that made sense. Additional data could be added at any time, and could either be ignored by the method if it did not understand the data, or handled by the method if it was understood.

I'm not suggesting this as a solution... I'm just pointing out that the "traditional" C-style approach to passing arguments to methods is rigid, and does not allow for future expansion, just like the old Parallel DB-25 printer cables, or the IDE ribbon cable. They have all been replaced, over the years, by USB and SATA cables, because these cables have a simpler interface, and rely heavily on the controllers to handle the "logic" of sending and receiving complex data over a simple serial data stream.

Hopefully, this all makes sense, and answers your question, somewhat.

Most of the actual features wouldn't be part of the shell but applications. Just as in any other shell you can call "mplayer video.mpg" and mplayer is launched playing your window, you can call "mplayer video.mpg" and mplayer is launched inlined into your command line.



Let's say you want to grab a web page:


Maybe in shell script form it'll be something more like "wget http://maps.google.com | htmlrenderer".

Graphics - the same way window managers work. The window is just squeezed between two lines of text. As it scrolls off the screen it is frozen, above x-number of lines it's unloaded. You could even resize the window (increasing/decreasing the gap between the text above/below it), maybe 'drag' it out of the shell into it's own window.

You could stream data/parameters through 'manipulator' tools -
"loadimage face.jpg | imageadjust | imagerenderer"


You could keep the complexity of the scripting language simple (i.e. shell script-like) by adopt the UNIX mantra of "do one thing and do it well" of everything being small single-used programs that input and output streams.

Agreed. But I would take it a step further, and say that the UNIX approach of writing a whole (albeit small) application to do one thing is overkill. If you are passing "input" and receiving "output", then a single "function" should suffice. This would open up the possibility of the user writing their own functions, on the fly, and passing them as input to other functions.

For example, instead of writing a "ls" utility that accepts numerous arguments to control the output formatting (colors, rows, columns, attributes, security, etc.), you could just request a list of files, and then write your own format function that takes those files as an input, and returns a formatted string as output.

Note that this actually "simplifies" the ls utility, and provides the user with a nearly infinite ability to customize the output.

Again, I'm just thinking out loud. But this is what I would want from an OS.