Jump to content




LuaGRUB - a GRand Unified Bootloader for CC

computer utility api

15 replies to this topic

#1 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 18 March 2014 - 01:24 AM

Ever wanted to test multiple OSes at once? Changed your configs so you have an unreasonable amount of space on your computer? This is for you!

LuaGRUB is a bootloader based off GNU GRUB. It's purpose is to allow you to have multiple operating systems on one machine, and choose one at boot. If the OS supports it, you can even tell one OS to reboot directly into another (even into CraftOS). It features a simple color GUI that resembles as closely as possible the build of GNU GRUB I use every day. This is a very early version (I started a week ago), so many OSes will not be compatible, especially if they use absolute paths. There is a fix planned for 2.0, so stay tuned.

Update: I just added documentation!
It'll get better over time!

Screenshots:
Spoiler

To install:
> pastebin get Ri2ZSxVF launcher
> launcher
The launcher will rename itself to 'launcher' if that's not its name, so make sure you don't have anything else named launcher in the root folder.
The pastebin might be out-of-date; for the latest stable version, check here: https://github.com/s...an/LGRUB-stable

Found a bug? Have a suggestion? If you already have a GitHub account, please use the issue tracker at https://github.com/s.../LuaGRUB/issues
If you'd rather not make one, you can always post here, but I don't check the forums as frequently as GitHub, so I might take a while to respond.

Have a GitHub? Want to help? PM me!

APIs used:
Drawing.lua from OneOS by oeed used with permission.

Edited by skwerlman, 19 March 2014 - 05:25 AM.


#2 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 18 March 2014 - 09:17 AM

Looks pretty good, but the Pastebin code isn't working. It says the paste has been removed.

I've copied it off GitHub though.

How do I 'install' an OS in to the bootloader?

Edited by oeed, 18 March 2014 - 09:23 AM.


#3 TheOddByte

    Lazy Coder

  • Members
  • 1,607 posts
  • LocationSweden

Posted 18 March 2014 - 10:32 AM

You should fix the pastebin link or a moderator will lock the topic.
But as oeed says it looks pretty good.

#4 apemanzilla

  • Members
  • 1,421 posts

Posted 18 March 2014 - 01:16 PM

I had an idea for something like this a while ago, but I like the way this one looks :)

Is there documentation on how to add it and stuff?

#5 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 19 March 2014 - 04:06 AM

 oeed, on 18 March 2014 - 09:17 AM, said:

Looks pretty good, but the Pastebin code isn't working. It says the paste has been removed.

I've copied it off GitHub though.

How do I 'install' an OS in to the bootloader?

Oops, I'll fix that now.
You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D )

 Apemanzilla, on 18 March 2014 - 01:16 PM, said:

I had an idea for something like this a while ago, but I like the way this one looks :)

Is there documentation on how to add it and stuff?
Documentation is coming, I just have to write it...

Pastebin link fixed.
Documentation should be done by tomorrow. DONE!

Edited by skwerlman, 19 March 2014 - 05:19 AM.


#6 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 19 March 2014 - 05:48 AM

 skwerlman, on 19 March 2014 - 04:06 AM, said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D )
Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

#7 apemanzilla

  • Members
  • 1,421 posts

Posted 19 March 2014 - 05:52 AM

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

#8 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 19 March 2014 - 05:57 AM

 oeed, on 19 March 2014 - 05:48 AM, said:

 skwerlman, on 19 March 2014 - 04:06 AM, said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D )
Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

 Apemanzilla, on 19 March 2014 - 05:52 AM, said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?

#9 apemanzilla

  • Members
  • 1,421 posts

Posted 19 March 2014 - 11:22 AM

 skwerlman, on 19 March 2014 - 05:57 AM, said:

 oeed, on 19 March 2014 - 05:48 AM, said:

 skwerlman, on 19 March 2014 - 04:06 AM, said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/> )
Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

 Apemanzilla, on 19 March 2014 - 05:52 AM, said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?
I'm not recoding my entire OS to use relative paths, for multiple reasons.

#10 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 19 March 2014 - 11:26 AM

 Apemanzilla, on 19 March 2014 - 11:22 AM, said:

 skwerlman, on 19 March 2014 - 05:57 AM, said:

 oeed, on 19 March 2014 - 05:48 AM, said:

 skwerlman, on 19 March 2014 - 04:06 AM, said:

You have to install the OS to the '/os' folder, inside of its own folder (i.e. '/os/OneOS/'). If you want the OS to have a display name instead of a path on the launcher, you should have a file named 'name.grub' containing the OS's name on the first line.
Oh, and I just want to note that I don't think I'll be compatible with OneOS or PearOS until 2.0. (Unless you want to change all of your paths to relative :D/> )
Ah ok.

The absolute path issue is something you should try to fix asap, it's a make or break feature.

That's my #1 priority right now.

 Apemanzilla, on 19 March 2014 - 05:52 AM, said:

Relative paths are annoying to keep in order. If you could just make it search through the folder structure for files named "info.grub" which would contain the name, program to run, etc, I think it would be a lot more useful.

What advantages would it have over changing how paths are resolved?
I'm not recoding my entire OS to use relative paths, for multiple reasons.

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.

Edited by skwerlman, 19 March 2014 - 11:28 AM.


#11 apemanzilla

  • Members
  • 1,421 posts

Posted 19 March 2014 - 11:36 AM

 skwerlman, on 19 March 2014 - 11:26 AM, said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.
If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.

Edited by Apemanzilla, 19 March 2014 - 11:41 AM.


#12 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 19 March 2014 - 01:04 PM

 Apemanzilla, on 19 March 2014 - 11:36 AM, said:

 skwerlman, on 19 March 2014 - 11:26 AM, said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.
If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.
How? I'm replacing fs and os in _G

#13 apemanzilla

  • Members
  • 1,421 posts

Posted 19 March 2014 - 03:17 PM

 skwerlman, on 19 March 2014 - 01:04 PM, said:

 Apemanzilla, on 19 March 2014 - 11:36 AM, said:

 skwerlman, on 19 March 2014 - 11:26 AM, said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.
If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.
How? I'm replacing fs and os in _G
In that case, it should work but just make sure not to crash it or you lose access to those entirely.

#14 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 19 March 2014 - 07:23 PM

 Apemanzilla, on 19 March 2014 - 03:17 PM, said:

 skwerlman, on 19 March 2014 - 01:04 PM, said:

 Apemanzilla, on 19 March 2014 - 11:36 AM, said:

 skwerlman, on 19 March 2014 - 11:26 AM, said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.
If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.
How? I'm replacing fs and os in _G
In that case, it should work but just make sure not to crash it or you lose access to those entirely.
I figured that one out, lol:
Spoiler


#15 apemanzilla

  • Members
  • 1,421 posts

Posted 20 March 2014 - 03:31 AM

 skwerlman, on 19 March 2014 - 07:23 PM, said:

 Apemanzilla, on 19 March 2014 - 03:17 PM, said:

 skwerlman, on 19 March 2014 - 01:04 PM, said:

 Apemanzilla, on 19 March 2014 - 11:36 AM, said:

 skwerlman, on 19 March 2014 - 11:26 AM, said:

My plan is to actually alter how paths are interpreted by the computer (i.e. sandboxing), with the express purpose of not requiring authors to recode their OSes.
Also, most OSes have a file named startup, so if they were all at root, then there would be conflicts. This way, each OS gets its own space that it thinks is root, no matter how it's written.
If the OS uses something like setfenv, os.run, or setmetatable they could unknowingly end up in the root folder again.
How? I'm replacing fs and os in _G
In that case, it should work but just make sure not to crash it or you lose access to those entirely.
I figured that one out, lol:
Spoiler
Welcome to the world of sandboxing XD

#16 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 22 March 2014 - 10:27 AM

Just want to say, not dead; work is just going slowly....





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users