Anyone want to collaborate on a OS? (via git)

So I was making an OS with Sewbacca, but he did not really have enough time. So instead I started making a new OS!
So far I am only 23kb or so in (as opposed to 400kb for the OS that was canceled Don't trust GitHub to calculate your file size.

[LINKS DELETED]
Though collaboration would be via git, as stated in the CONTRIBUTING.md file

Here's what we could collaborate on:

• The kernel
• Applications
• Packages
• The wiki (later on)
• Server (if applicable)
• The text that goes with the post

This OS is primarily for computercraft 1.74-1.8, though it would be cool to also have support for OC and lua5.3+windows (later on)

So just PM me or even post here if you are interested!

EDIT: BTW, github isn't using my github username for my commits, but instead my real name, which is weird, as on every other repo it does use my username. Also, it says 0 collaborators (even weirder), though I have uploaded files

Another edit: I think that githubs size folder repo size info is seriously off, because I thought that the os was greater than 23kb.

EveryOS, on 27 March 2018 - 05:53 PM said:

EDIT: BTW, github isn't using my github username for my commits, but instead my real name, which is weird, as on every other repo it does use my username. Also, it says 0 collaborators (even weirder), though I have uploaded files

It's not github's problem, you're making the commits locally, github doesn't know they're yours because you have your local git username set to jasongronn.

EveryOS, on 27 March 2018 - 05:53 PM said:

[snip] lua5.3+windows [snip]

…
…
…



Yet another developer that only cares about Windows users.

*Bump*
GitHub lied about the file size.
According to CC, the straight-off-git folder size is 245MB (Alot)
The only important folder in the repository is the QuantumCat folder. If you delete all of the other folders/files, it is 69.8MB (Not alot)

So there's several things I think when I see someone start a new OS (or any project) and, whilst you've clearly put some planning into this, none of them are answered here or on the repo. They all boil down into one big question:

What problem does this operating system solve?

The reality is that there are 350 odd CC OSes on this forum already and, whilst they vary from glorified startup screens to 600kb behemoths, few of them answer this question. People have gone "I want a GUI" or "I want a linux clone" without sitting down and thinking really hard about what that actually means. I love Linux as much as the next developer, but you've got to think about what's worth taking from there (i.e. shell syntax (technically separate program but w/e)) and what's not (drivers).

My advice is twofold: First read this grumpy rant, as it covers some of these thoughts in a little more details. Then, if you're still up to it, sit down with a piece of paper (and I do mean paper) and have a long hard think about the following questions:

• What about CraftOS is bad, and who does that impact? As a developer, I dislike how painful working in the shell and Lua REPL can be (hence MBS). Maybe you think it's not accessible to new users of the mod. Or maybe there's some tooling (such as a package manager) you're missing.
• Now you've established a target and problem, how are you going to solve it? Maybe this doesn't involve writing an OS, but a standalone utility (such as MBS or the various package managers).
• If it still involves writing an OS, what features are relevant to that problem, and how to they help solve it?

Because apparently I have too much time (why am I not in bed right now), I'm going to have a look at two CC OSes. Note it's been a while since I looked at either, so take my comments with a pinch of salt.

Firstly, PearOS: this was the precursor to OneOS, and I think the same points apply to that too. As the OP states, PearOS was designed for people who have no clue what they're doing with CC. It's not going to help someone who's a master of the mod, but acts as a useful introduction beyond just running adventure. There's a reason it's one of the most popular topics on the OS forum (OK, that reason might be because oeed is a literal and figurative wizard when it comes to GUIs).

Secondly, VorbaniOS: This aims to provide a more *nixy approach over ComputerCraft. Whilst the code is clean, and an architectural masterpiece, I'm really not sure what the point is. I've never really sat down and gone "hrmrm, I do wish I could index peripherals as devices". Maybe someone has found a use for that though - I'll happily retract my criticism if wrong.

My point isn't that one type of OS is better than another, it's that you've got to have a clear problem you're trying to solve, and a goal in mind before setting out. Otherwise you're almost doomed to failure. That being said, there's no harm in experimenting in these sorts of projects as anything outside one's comfort zone is going to make you a better developer. I know I've re-invented the wheel enough times myself, it's just when there's 350 other near-identical wheels out there already, one does have to raise eyebrows.

SquidDev, on 27 March 2018 - 11:28 PM said:

Secondly, VorbaniOS: This aims to provide a more *nixy approach over ComputerCraft. Whilst the code is clean, and an architectural masterpiece, I'm really not sure what the point is. I've never really sat down and gone "hrmrm, I do wish I could index peripherals as devices". Maybe someone has found a use for that though - I'll happily retract my criticism if wrong.

I'll make this statement on behalf of Scoopta and Myself: Vorbani itself wasn't really intended on solving an issue, it was just sort of a fun little project that we put a lot of time into (and are currently remodelling) and it has some neat features that don't exist in direct CC.

• It has the ability to redirect input/output streams (so you can hide output by pushing it to /dev/null, like in linux)
• A USFS (user creates filesystem) node sytem to allow you to make things like HTTP Filesystems, ramfs, etc
• Auto-library loading
• Init daemons which are easy to create
• Group/User management
• A basic package manager (which is easy to use and build packages for)

Among other small niceties that are just tedious to go into.

All of these things themselves may not have been things people "wanted," however, they were neat to make and have their usecases somewhere.

quote

SquidDev, on 27 March 2018 - 11:28 PM said:

So there's several things I think when I see someone start a new OS (or any project) and, whilst you've clearly put some planning into this, none of them are answered here or on the repo. They all boil down into one big question:

What problem does this operating system solve?

The reality is that there are 350 odd CC OSes on this forum already and, whilst they vary from glorified startup screens to 600kb behemoths, few of them answer this question. People have gone "I want a GUI" or "I want a linux clone" without sitting down and thinking really hard about what that actually means. I love Linux as much as the next developer, but you've got to think about what's worth taking from there (i.e. shell syntax (technically separate program but w/e)) and what's not (drivers).

My advice is twofold: First read this grumpy rant, as it covers some of these thoughts in a little more details. Then, if you're still up to it, sit down with a piece of paper (and I do mean paper) and have a long hard think about the following questions:

• What about CraftOS is bad, and who does that impact? As a developer, I dislike how painful working in the shell and Lua REPL can be (hence MBS). Maybe you think it's not accessible to new users of the mod. Or maybe there's some tooling (such as a package manager) you're missing.
• Now you've established a target and problem, how are you going to solve it? Maybe this doesn't involve writing an OS, but a standalone utility (such as MBS or the various package managers).
• If it still involves writing an OS, what features are relevant to that problem, and how to they help solve it?

Because apparently I have too much time (why am I not in bed right now), I'm going to have a look at two CC OSes. Note it's been a while since I looked at either, so take my comments with a pinch of salt.

Firstly, PearOS: this was the precursor to OneOS, and I think the same points apply to that too. As the OP states, PearOS was designed for people who have no clue what they're doing with CC. It's not going to help someone who's a master of the mod, but acts as a useful introduction beyond just running adventure. There's a reason it's one of the most popular topics on the OS forum (OK, that reason might be because oeed is a literal and figurative wizard when it comes to GUIs).

Secondly, VorbaniOS: This aims to provide a more *nixy approach over ComputerCraft. Whilst the code is clean, and an architectural masterpiece, I'm really not sure what the point is. I've never really sat down and gone "hrmrm, I do wish I could index peripherals as devices". Maybe someone has found a use for that though - I'll happily retract my criticism if wrong.

My point isn't that one type of OS is better than another, it's that you've got to have a clear problem you're trying to solve, and a goal in mind before setting out. Otherwise you're almost doomed to failure. That being said, there's no harm in experimenting in these sorts of projects as anything outside one's comfort zone is going to make you a better developer. I know I've re-invented the wheel enough times myself, it's just when there's 350 other near-identical wheels out there already, one does have to raise eyebrows.

SquidDev, on 27 March 2018 - 11:28 PM said:

So there's several things I think when I see someone start a new OS (or any project) and, whilst you've clearly put some planning into this, none of them are answered here or on the repo. They all boil down into one big question:

What problem does this operating system solve?

The reality is that there are 350 odd CC OSes on this forum already and, whilst they vary from glorified startup screens to 600kb behemoths, few of them answer this question. People have gone "I want a GUI" or "I want a linux clone" without sitting down and thinking really hard about what that actually means. I love Linux as much as the next developer, but you've got to think about what's worth taking from there (i.e. shell syntax (technically separate program but w/e)) and what's not (drivers).

My advice is twofold: First read this grumpy rant, as it covers some of these thoughts in a little more details. Then, if you're still up to it, sit down with a piece of paper (and I do mean paper) and have a long hard think about the following questions:

• What about CraftOS is bad, and who does that impact? As a developer, I dislike how painful working in the shell and Lua REPL can be (hence MBS). Maybe you think it's not accessible to new users of the mod. Or maybe there's some tooling (such as a package manager) you're missing.
• Now you've established a target and problem, how are you going to solve it? Maybe this doesn't involve writing an OS, but a standalone utility (such as MBS or the various package managers).
• If it still involves writing an OS, what features are relevant to that problem, and how to they help solve it?

Because apparently I have too much time (why am I not in bed right now), I'm going to have a look at two CC OSes. Note it's been a while since I looked at either, so take my comments with a pinch of salt.

Firstly, PearOS: this was the precursor to OneOS, and I think the same points apply to that too. As the OP states, PearOS was designed for people who have no clue what they're doing with CC. It's not going to help someone who's a master of the mod, but acts as a useful introduction beyond just running adventure. There's a reason it's one of the most popular topics on the OS forum (OK, that reason might be because oeed is a literal and figurative wizard when it comes to GUIs).

Secondly, VorbaniOS: This aims to provide a more *nixy approach over ComputerCraft. Whilst the code is clean, and an architectural masterpiece, I'm really not sure what the point is. I've never really sat down and gone "hrmrm, I do wish I could index peripherals as devices". Maybe someone has found a use for that though - I'll happily retract my criticism if wrong.

My point isn't that one type of OS is better than another, it's that you've got to have a clear problem you're trying to solve, and a goal in mind before setting out. Otherwise you're almost doomed to failure. That being said, there's no harm in experimenting in these sorts of projects as anything outside one's comfort zone is going to make you a better developer. I know I've re-invented the wheel enough times myself, it's just when there's 350 other near-identical wheels out there already, one does have to raise eyebrows.

SO as far as some plans go:
First off, you mention wanting to clone Linux. This OS takes much inspiration from those.

Here are some items
[html]
Enable advanced programs to run on grayscale monitors (via grayscale lookup)
Various things your usual GUI would have (Like extended display and mirroring)
Security alerts (like when a program wants to edit your startup scripts)
Backwards-CC compatibility (Via what I will call LateBIOs)
Texture pack compatibility (Again via LateBIOs)
Multiple TTYs (like linux)
Note that CraftOS cannot easily open multishell upon user request during a non-shell program usually
Enable/Disable click interface and many of the graphics libraries (like term.setCursorPos)
A package manager (Like linux), and a centralized area for those packages
A search option, as well as an api that allows for entering metadata for this option
I kinda want people to be able to use this OS and the craftos shell at the same time instead of a gui….
Easy customization
A centralized area for storing APIs, which craftos does not have
MultiUser support, which craftos does not have
file encoding
Cache-ing
Mutated versions of Lua I call architects
Piping - Launch background processes and get id, or get id of running process by looking up filepath
I've already programmed in stack-trace, but it does not work to well, just needs fine-tuning

More stuff I forgot…
[/html]

If you are looking for a Package Manager use Packman. If you want a GUI, use Mynaptic. There a a lot of programs who are already in Packman.

I'm still going to write it, even if I have to do it myself (:

LoganDark2, on 27 March 2018 - 08:33 PM said:

EveryOS, on 27 March 2018 - 05:53 PM said:

EDIT: BTW, github isn't using my github username for my commits, but instead my real name, which is weird, as on every other repo it does use my username. Also, it says 0 collaborators (even weirder), though I have uploaded files

It's not github's problem, you're making the commits locally, github doesn't know they're yours because you have your local git username set to jasongronn.

Wait, git has local usernames? How do I change it?
Also, it has me type my github username whenever I do commits

EveryOS, on 28 March 2018 - 01:29 PM said:

-snip-
Wait, git has local usernames? How do I change it?
Also, it has me type my github username whenever I do commits

From the command line:

git config --global user.name <your name>
git config --global user.email <your email>

IIRC if you want github to assign these commits to you the email configured in git needs to match the email that GitHub has.

Luca_S, on 28 March 2018 - 01:58 PM said:

EveryOS, on 28 March 2018 - 01:29 PM said:

-snip-
Wait, git has local usernames? How do I change it?
Also, it has me type my github username whenever I do commits

From the command line:

git config --global user.name <your name>
git config --global user.email <your email>

IIRC if you want github to assign these commits to you the email configured in git needs to match the email that GitHub has.

OK

BTW, when I first went into these forums my goal was to create OS's, hence my username. My first program (a template for an installer) was something I created while working on my second program (NyanOS, the only OS I ever released). After that, the only program I really made was getOpts, because I was more focused on NyanOS2 (now cancelled).

ALSO, though I do not know C or x86_64, ever since I first learned programming (3 years ago with JS), my dream has been to write an OS.

Some problems with CraftOS include:
[html]The load bug I've reported
Native thread requesting
Some programs entirely crash it
Cannot open multishell while another program is running
Lack of macros[/html]

• Enable advanced programs to run on grayscale monitors (via grayscale lookup) - already been done
• Various things your usual GUI would have (Like extended display and mirroring) - already been done
• Security alerts (like when a program wants to edit your startup scripts) - already been done in various ways (vfs, custom env, etc)
• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists (CCBox, carbon, etc)
• Texture pack compatibility (Again via LateBIOs) - already exists (see above)
• Multiple TTYs (like linux) - multishell
• Note that CraftOS cannot easily open multishell upon user request during a non-shell program usually - would be better as a separate program wrapping multishell (would be about 3 lines too)
• Enable/Disable click interface and many of the graphics libraries (like term.setCursorPos) - what?
• A package manager (Like linux), and a centralized area for those packages - already been done, not going to list them all
• A search option, as well as an api that allows for entering metadata for this option - fs.find, would be better as a separate program
• I kinda want people to be able to use this OS and the craftos shell at the same time instead of a gui…. - so… multishell?
• Easy customization - there's tons of customization programs already, between editors, package managers, shells, palette editors, etc
• A centralized area for storing APIs, which craftos does not have - already been done (any package manager, not going to list them all)
• MultiUser support, which craftos does not have - not really useful considering how easily you can just slap down another computer
• file encoding - what?
• Cache-ing - better as an api
• Mutated versions of Lua I call architects - what? already been done?
• Piping - Launch background processes and get id, or get id of running process by looking up filepath - that's not what piping is, and real piping has already been done (clamshell)
• I've already programmed in stack-trace, but it does not work to well, just needs fine-tuning - already been done (trace, mbs)
• The load bug I've reported - doesn't really change anything
• Native thread requesting - what?
• Some programs entirely crash it - those programs are known as "broken", and you might want to read this
• Cannot open multishell while another program is running - better as a separate program, already been done
• Lack of macros - if you mean compile-time macros then that's DEFINITELY better as a separate program, not to mention it's already been done

Seriously, you'd be much better off releasing a few well-made programs or APIs than trying to build an "os"

Stealing from ape to say things that Vorbani did/is doing:

• Security alerts (like when a program wants to edit your startup scripts) - This is called user management and is done just by having user management
• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists I wrote a vorbani exclusive program that runs inside vorbani to do this
• Multiple TTYs (like linux) - Vorbani did this
• Enable/Disable click interface and many of the graphics libraries (like term.setCursorPos) - As ape said: Why would you need this? Just have programs not take click events lmao
• A package manager (Like linux), and a centralized area for those packages - already been done, not going to list them all (Vorbani)
• Easy customization - there's tons of customization programs already, between editors, package managers, shells, palette editors, etc
• A centralized area for storing APIs, which craftos does not have - You can literally make a folder called "APIS" on the root of your drive, and do

for k,v in pairs("/APIS") do
	 os.loadAPI("/APIS/"..v)
end

• MultiUser support, which craftos does not have - not really useful considering how easily you can just slap down another computer <- This, and been done in virtually every slightly decent os.
• Piping - Launch background processes and get id, or get id of running process by looking up filepath - that's not what piping is, and real piping has already been done (clamshell) Vorbani is doing this

apemanzilla, on 28 March 2018 - 07:44 PM said:

• I kinda want people to be able to use this OS and the craftos shell at the same time instead of a gui…. - so… multishell?

No, I mean without multi-shell. Perhaps I should say "Run the CraftOS shell on top of my OS, which may or may not be running on-top of another installation of CraftOS or on a resource pack without CraftOS"

EveryOS, on 28 March 2018 - 08:16 PM said:

apemanzilla, on 28 March 2018 - 07:44 PM said:

• I kinda want people to be able to use this OS and the craftos shell at the same time instead of a gui…. - so… multishell?

No, I mean without multi-shell. Perhaps I should say "Run the CraftOS shell on top of my OS, which may or may not be running on-top of another installation of CraftOS or on a resource pack without CraftOS"

…so CCBox.

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Piping - Launch background processes and get id, or get id of running process by looking up filepath - that's not what piping is

I thought piping was when programs sent messages to eachother. If I'm getting the process ID (Oops, forgot to mention sub-processes, kinda like multishell), and using it to send a message to just that process, how is that not piping?

EveryOS, on 28 March 2018 - 08:21 PM said:

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Piping - Launch background processes and get id, or get id of running process by looking up filepath - that's not what piping is

I thought piping was when programs sent messages to eachother. If I'm getting the process ID (Oops, forgot to mention sub-processes, kinda like multishell), and using it to send a message to just that process, how is that not piping?

That's called inter process communication, and getting the ID of a process isn't part of IPC anyways, it's part of the kernel. Not to mention you can already use events to emulate IPC without anything else.

All the hate for OS thingys beside, I think you can still learn much through collaboration on a topic this complex. Even if the product will be not useful at all. (+1 toSquidDev for explaining)

You are going to want to start reading this, the section called Making a Big Project, and Preparing for Collaboration Through GitHub may be particularly helpful to you.

Step 4: Work and Wait
Keeping yourself motivated is quite possibly the most difficult part. Having other people working with you can be a motivator, but those same people will not be interested in helping the project if its leader, you, are not doing anything. Remember to tick things off the to-do list as you complete them, seeing the number of things to do shrink and the list of done things grow can also be a source of motivation. You may find that once you have a working version of your project that people will be more willing to help.

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists (CCBox, carbon, etc)

Though's look more like "virtualbox" than "Backwards CC compatibility". I'll see if they can, for example, emulate term.setPalleteColor (obviously as a dummy function) on CC1.75, but it looks like you thought I was saying multiple versions of shell on one version of CC.

EveryOS, on 29 March 2018 - 08:22 PM said:

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists (CCBox, carbon, etc)

Though's look more like "virtualbox" than "Backwards CC compatibility". I'll see if they can, for example, emulate term.setPalleteColor (obviously as a dummy function) on CC1.75, but it looks like you thought I was saying multiple versions of shell on one version of CC.

No, I interpreted it properly. Both of the programs I listed allow you to, among many other features, easily emulate old versions of CC.

apemanzilla, on 29 March 2018 - 09:51 PM said:

EveryOS, on 29 March 2018 - 08:22 PM said:

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists (CCBox, carbon, etc)

Though's look more like "virtualbox" than "Backwards CC compatibility". I'll see if they can, for example, emulate term.setPalleteColor (obviously as a dummy function) on CC1.75, but it looks like you thought I was saying multiple versions of shell on one version of CC.

No, I interpreted it properly. Both of the programs I listed allow you to, among many other features, easily emulate old versions of CC.

Not emulate, run on them!
They emulate features of newer versions of CC

EveryOS, on 30 March 2018 - 12:13 AM said:

apemanzilla, on 29 March 2018 - 09:51 PM said:

EveryOS, on 29 March 2018 - 08:22 PM said:

apemanzilla, on 28 March 2018 - 07:44 PM said:

• Backwards-CC compatibility (Via what I will call LateBIOs) - already exists (CCBox, carbon, etc)

Though's look more like "virtualbox" than "Backwards CC compatibility". I'll see if they can, for example, emulate term.setPalleteColor (obviously as a dummy function) on CC1.75, but it looks like you thought I was saying multiple versions of shell on one version of CC.

No, I interpreted it properly. Both of the programs I listed allow you to, among many other features, easily emulate old versions of CC.

Not emulate, run on them!
They emulate features of newer versions of CC

They can do both. Point is, it's already been done, and would be better off as a separate program than an "os".

Moved to Operating Systems.

I've deleted the links for now, the OS is not even close too done, can you just delete this so that I can start out a fresh thread after the many months/years it will take to write this?