44 replies to this topic

[oeed]

The other day I was thinkering around with the old Mac OS in an emulator and was inspired to make my own real OS. After about an hour I'd given up and decided to brush of my Lua skill and write a new OS. So, if there was some 'perfect CC OS' what features would have,what would the interface be etc. I had a look over the PearOS forum again and I've made a short list.

• Useful - PearOS was pretty and all, but if I'm honest it was completely useless.
  
• Shell emulation - This is what I've been working on over the past few days.
  
• Look nice

It's a pretty short list. But surely there some dream features that other OSs haven't done or got right.

Thoughts?

[distantcam]

An OS with some sort of package tool that could grab apps from some sort of Computercraft App Store would be nice...

[Mackan90096]

Syntax highlighter, a web browser, multitasking.

Like windows 7 but for CC

[Zambonie]

Hm. Maybe a IRL Weather/Time feature. That would be nice.
Also You could add a taskbar which can store apps so there right there for you and like Mack said, multitask. And maybe some type of 'Really Advanced' File system.

[GravityScore]

Something really minimal that just goes away when you don't want it, yet still has a tonne of almost hidden away functionality and features. Something like a little pull down tab in the top or bottom (configurable) corner of every running app, a simple desktop (no fancy icons), and a simple colour scheme - something like just 2 or 3 colours in it (grey, dark grey, and cyan for example). Something highly configurable, like you can chose between a shell or graphical file browser, and a package manager, but simple, like apt-get with a few downloadable packages, no upload of packages. Damn I'm giving myself ideas now...

This is why I really really liked Kingdaro's Craftbang, and why I really really dislike windowed OSes for CC - there's just not enough screen space to make one effectively.

The easiest way (IMO) to make something look good is have a simple consistent colour scheme.

Edited by GravityScore, 29 November 2013 - 01:57 AM.

[oeed]

GravityScore, on 29 November 2013 - 01:55 AM, said:

Something really minimal that just goes away when you don't want it, yet still has a tonne of almost hidden away functionality and features. Something like a little pull down tab in the top or bottom (configurable) corner of every running app, a simple desktop (no fancy icons), and a simple colour scheme - something like just 2 or 3 colours in it (grey, dark grey, and cyan for example). Something highly configurable, like you can chose between a shell or graphical file browser, and a package manager, but simple, like apt-get with a few downloadable packages, no upload of packages. Damn I'm giving myself ideas now...

This is why I really really liked Kingdaro's Craftbang, and why I really really dislike windowed OSes for CC - there's just not enough screen space to make one effectively.

The easiest way (IMO) to make something look good is have a simple consistent colour scheme.

Thanks for the very valuable feedback.

Simple colour scheme is a must. However, I've been thinking about what makes current computers and software complicated to non-techsavy people. I believe one of the main reasons is customisation. While customisation is good to a point, having tons of options makes it confusing. As a result, especially with such a basic computer and uses, I'd like to avoid customisation where possible.
A few months back I was thinking about doing something similar to the Windows 8 Metro full screen app thing but never got around to it. I agree, there's very little screen space so windows, now I think about it, aren't really the best option.

[ElvishJerricco]

oeed, on 29 November 2013 - 05:19 AM, said:

Thanks for the very valuable feedback.

Simple colour scheme is a must. However, I've been thinking about what makes current computers and software complicated to non-techsavy people. I believe one of the main reasons is customisation. While customisation is good to a point, having tons of options makes it confusing. As a result, especially with such a basic computer and uses, I'd like to avoid customisation where possible.
A few months back I was thinking about doing something similar to the Windows 8 Metro full screen app thing but never got around to it. I agree, there's very little screen space so windows, now I think about it, aren't really the best option.

There's a subtle difference between customizability and modularity. Modules can be simple, but interchanged. If someone doesn't like the simple module you pack in by default, they can change it to their own module. Of course here "module" is an abstract term so you'd have to build a system for that, but the idea is a nice one.

[GravityScore]

ElvishJerricco, on 29 November 2013 - 05:38 AM, said:

There's a subtle difference between customizability and modularity. Modules can be simple, but interchanged. If someone doesn't like the simple module you pack in by default, they can change it to their own module. Of course here "module" is an abstract term so you'd have to build a system for that, but the idea is a nice one.

Module and modularity is probably a much better term for what I meant. Having different types and styles of modules that perform the same function so you can chose the one best suited to you. Of course, this is a lot of work due to having to build the system, then all the different types of modules individually. I think this is achieved well by real OSes such as Windows by having massive amounts of downloadable applications that all perform the same function (eg Chrome or Firefox or IE for web browsing, or providing a terminal or a graphical file system).

I agree with oeed in saying that too much customisation is confusing and pointless - being able to change almost meaningless things like the text colour is useless, clutters the screen, and I think should be avoided, partially why I'm a fan of having different themes the user can chose from, or not being able to change the colour scheme.

Edited by GravityScore, 29 November 2013 - 09:28 AM.

[distantcam]

Would abstraction be a better term for what you're describing?

Modern OSes provide a higher level abstraction over the hardware layer. That abstraction then allows programs, which are just the top level of abstraction, to run.

Abstractions become more numerous as you go higher too. For example at the bottom level you have drivers, and so for any given piece of hardware you'll usually only have 1 driver, maybe 2 (a generic one and a specific one). At the top level of abstraction there are countless implementations of a browser for example.

I'd like to see an abstraction for the display, so that you don't have to worry about whether the display is colour, can handle mouse clicks, etc. You would write your code and the abstraction framework would take care of the details.

Another area worth abstracting would be the peripheral system. So many programs require you to modify the code to select the "side" the appropriate peripheral is on, or the more advanced ones ask you which side. If there was a decent abstraction then you'd simply have to ask the OS for a peripheral and it's found automatically. This is fairly easy to write but because it's not in the base OS people keep rewriting it, or not bothering.

[ElvishJerricco]

GravityScore, on 29 November 2013 - 09:28 AM, said:

Module and modularity is probably a much better term for what I meant. Having different types and styles of modules that perform the same function so you can chose the one best suited to you. Of course, this is a lot of work due to having to build the system, then all the different types of modules individually. I think this is achieved well by real OSes such as Windows by having massive amounts of downloadable applications that all perform the same function (eg Chrome or Firefox or IE for web browsing, or providing a terminal or a graphical file system).

The easiest way to do modularity is to make the modules you want to make, then allow other people to make alternative modules that can be used instead. This way you don't need to build more than your module and people still have the option. It's like how on most linux distros, it comes with one desktop interface, but it's easy to change to another one.

[GravityScore]

The only problem with building levels of abstraction on top of the base CC hardware is that people probably don't want to build applications specifically for a particular OS with its particular abstractions on CC - they want to be able to release their program standalone. So if you were to build abstractions into the OS, have some sort of "Add abstraction code into program" button which adds a bunch of code into the file so that the program can be released standalone.

This is the reason I think making an OS with a developer API is a silly idea - people don't want to make programs for one particular OS, they want to be able to run the program standalone so they can release it for others to use.

Edited by GravityScore, 29 November 2013 - 10:52 PM.

[awsmazinggenius]

GravityScore, on 29 November 2013 - 10:51 PM, said:

The only problem with building levels of abstraction on top of the base CC hardware is that people probably don't want to build applications specifically for a particular OS with its particular abstractions on CC - they want to be able to release their program standalone. So if you were to build abstractions into the OS, have some sort of "Add abstraction code into program" button which adds a bunch of code into the file so that the program can be released standalone.

This is the reason I think making an OS with a developer API is a silly idea - people don't want to make programs for one particular OS, they want to be able to run the program standalone so they can release it for others to use.

My planned OS, awsmazingOS (under heavy development, not coming out anytime soon) has function calls such as awsmazingOS.setAppIcon(params subject to change) to change an icon, but the developer can use os.getVersion()to get the OS name, so they could use something like this:

if string.find(os.getVersion(), "awsmazingOS") then[/font]
  awsmazingOS.setAppIcon(params)[/font]
  --# other awsmazingOS stuff
end

however awsmazingOS has a hidden CraftOS layer to run standard programs. What do you believe is best? As well as the fact that awsmazingOS does have a planned store - that is also planned to have some requirements and moderation, some of those requirements being a requirement of awsmazingOS features, such as Icons and Home tiles,

Edited by awsmazinggenius, 29 November 2013 - 11:08 PM.

[oeed]

distantcam, on 29 November 2013 - 10:01 AM, said:

Would abstraction be a better term for what you're describing?

Modern OSes provide a higher level abstraction over the hardware layer. That abstraction then allows programs, which are just the top level of abstraction, to run.

Abstractions become more numerous as you go higher too. For example at the bottom level you have drivers, and so for any given piece of hardware you'll usually only have 1 driver, maybe 2 (a generic one and a specific one). At the top level of abstraction there are countless implementations of a browser for example.

I'd like to see an abstraction for the display, so that you don't have to worry about whether the display is colour, can handle mouse clicks, etc. You would write your code and the abstraction framework would take care of the details.

Another area worth abstracting would be the peripheral system. So many programs require you to modify the code to select the "side" the appropriate peripheral is on, or the more advanced ones ask you which side. If there was a decent abstraction then you'd simply have to ask the OS for a peripheral and it's found automatically. This is fairly easy to write but because it's not in the base OS people keep rewriting it, or not bothering.

I see what you are getting at, sort of like helper libraries? As GravityScore mentioned, however, while this would be easier people don't want to have to make specific programs for different OSs. This is why I make my own APIs, I use them everywhere and it makes everything easier.

GravityScore, on 29 November 2013 - 10:51 PM, said:

The only problem with building levels of abstraction on top of the base CC hardware is that people probably don't want to build applications specifically for a particular OS with its particular abstractions on CC - they want to be able to release their program standalone. So if you were to build abstractions into the OS, have some sort of "Add abstraction code into program" button which adds a bunch of code into the file so that the program can be released standalone.

This is the reason I think making an OS with a developer API is a silly idea - people don't want to make programs for one particular OS, they want to be able to run the program standalone so they can release it for others to use.

Yes, this is one of the main reasons why I've spent most of the time so far getting shell apps running. One of the biggest problems with PearOS is that making an application is completely different to making a normal program. I often have people PM me who don't know where to begin, it's just so different. I've been thinking, however, that we should make some kind of standards to follow for making programs. For example, resizing and a way to prevent program close if there's something not saved.

awsmazinggenius, on 29 November 2013 - 11:07 PM, said:

GravityScore, on 29 November 2013 - 10:51 PM, said:

-snip-

My planned OS, awsmazingOS (under heavy development, not coming out anytime soon) has function calls such as awsmazingOS.setAppIcon(params subject to change) to change an icon, but the developer can use os.getVersion()to get the OS name, so they could use something like this:

if string.find(os.getVersion(), "awsmazingOS") then[/font]
  awsmazingOS.setAppIcon(params)[/font]
  --# other awsmazingOS stuff
end

however awsmazingOS has a hidden CraftOS layer to run standard programs. What do you believe is best? As well as the fact that awsmazingOS does have a planned store - that is also planned to have some requirements and moderation, some of those requirements being a requirement of awsmazingOS features, such as Icons and Home tiles,

This is the sort of thing that would be very useful for OSs. I was thinking of adding something which when you add an app to the desktop it checks it for an icon, similar to how you've done it. However, as I mentioned above we need to have a uniform standard so all programs support it and you don't need to have special versions. Thoughts?

Edited by oeed, 29 November 2013 - 11:13 PM.

[GravityScore]

oeed, on 29 November 2013 - 11:12 PM, said:

Thoughts?

Relevant XKCD

I don't think standards would be the way to do it - many different OSes and programs would require quite different functionality, or people may want to go their own way about making something, rather than following guidelines, so in a way this could discourage creativity and new ideas.

awsmazinggenius: I do like that, probably easier than my "add code into program" button idea

[oeed]

Troll., on 28 November 2013 - 09:01 AM, said:

Hm. Maybe a IRL Weather/Time feature. That would be nice.
Also You could add a taskbar which can store apps so there right there for you and like Mack said, multitask. And maybe some type of 'Really Advanced' File system.

Out of curiosity, what do you mean by 'Really Advanced' system? Do you mean an advanced file browser?

GravityScore, on 29 November 2013 - 11:33 PM, said:

oeed, on 29 November 2013 - 11:12 PM, said:

Thoughts?

Relevant XKCD

I don't think standards would be the way to do it - many different OSes and programs would require quite different functionality, or people may want to go their own way about making something, rather than following guidelines, so in a way this could discourage creativity and new ideas.

awsmazinggenius: I do like that, probably easier than my "add code into program" button idea

Actually, that's a very good point.

There really is no better way to prove your case than an xkcd comic.


So, what's the solution then? Other than just not having this functionality what can you do?

Edited by oeed, 30 November 2013 - 12:07 AM.

[Lyqyd]

There isn't really any way around it. If you want a standardized interface that OSs could implement, it won't meet everyone's needs. If you don't have a standardized interface, everyone will roll their own, so programs would need huge amounts of code for compatibility with multiple OS-specific APIs. If everything just uses the standard arrangements of things to allow usual CraftOS programs can run, the programs can't influence any special OS features.

I generally go for the strategy wherein a standard CraftOS program can be run completely normally, where it sees no differences between running in CraftOS and running in LyqydOS (aside from available screen space), but I provide (currently slightly anemic) API calls to allow developers interested in taking advantage of LyqydOS features a way to do so simply and with minimal extra coding in their programs.

Several of the "features" discussed above would be better as well-written CraftOS programs, to be honest. Good programs that people like to use can be combined with an OS they enjoy using if everything is written properly. Extensive compatibility is the "best" way to go, in my opinion.

[oeed]

Lyqyd, on 30 November 2013 - 12:20 AM, said:

There isn't really any way around it. If you want a standardized interface that OSs could implement, it won't meet everyone's needs. If you don't have a standardized interface, everyone will roll their own, so programs would need huge amounts of code for compatibility with multiple OS-specific APIs. If everything just uses the standard arrangements of things to allow usual CraftOS programs can run, the programs can't influence any special OS features.

I generally go for the strategy wherein a standard CraftOS program can be run completely normally, where it sees no differences between running in CraftOS and running in LyqydOS (aside from available screen space), but I provide (currently slightly anemic) API calls to allow developers interested in taking advantage of LyqydOS features a way to do so simply and with minimal extra coding in their programs.

Several of the "features" discussed above would be better as well-written CraftOS programs, to be honest. Good programs that people like to use can be combined with an OS they enjoy using if everything is written properly. Extensive compatibility is the "best" way to go, in my opinion.

Yes, I'm just thinking if there was some practice we could all agree on that provides API calls for OSs it would be good. But yea, I can't see people using it. The only way really would have icons, etc part of CraftOS/CC and that's not going to happen.

[BillyTheCodingKid]

Also add documentation on how to use the interfaces and apis so we can make our own apps.

[Sora Firestorm]

I've thought for the longest time that the community should get just together and make a whole bunch of standards (ie for Rednet transmissions, our own version of X, etc, etc) It honestly surprises me a little that it hasn't happened.

Something that would help maintain compatibility with standard CraftOS is trying to create hooks into the current APIs. Using the fs API as an example, you can implement symbolic links and file permissions, and by hooking into the fs API, every program is now automagically aware of permissions and symlinks. It eventually gets difficult trying to hook new functionality into the existing API and still have it make sense, though.

Perhaps we should try for a 'community OS'? I know that there have been ones in the past, but I believe they've all died.

Edited by Sora the Hedgehog, 30 November 2013 - 02:05 AM.

[basdxz]

I have seen a lot of OS'es but pretty much all of them have severe crash bugs, if you could avoid them then I think more people would use it.