auroraOS
auroraOS was an OS in your browser. Completely written from scratch over two fifteen months before discontinuation, it featured a beautiful GUI, a fast window manager, package loading, application APIs, and more.
It’s also remixable and open-source on Github, please excuse the spaghetti code!
The demo filesystem is persistent and all files are visible to everyone. Please do not write any personal information to the filesystem.
FAQ
- How does auroraOS work?
- auroraOS is a combination of Node.js on the back-end and pure JavaScript on the front-end. Every single thing on the front-end is written in pure HTML, CSS, and JavaScript; no preprocessors or Webpack here!
- auroraOS revolves around packages, somewhat like Linux. When a package is started, auroraOS fetches the script from the server and executes it while exposing many package APIs like
package.resource, which allows a package to retrieve files in its directory, andpackage.createWindow, which creates a window under the designated window manager. Even the window manager is a package!
- What am I allowed to do with auroraOS?
- View our Terms of Service for more info.
- Why was auroraOS created?
- It’s a long story, but it basically started out as a side-project and a chance to improve my JavaScript.
- How are passwords encrypted?
- Passwords are encrypted using Bcrypt, a library that automatically salts and scales strength to keep up with modern technology.
- When will a documentation be made?
- Soon.
- How do I update auroraOS versions?
- For now, there is no auto-update system planned, unless I somehow integrate it with the Market. You must currently remix the demo and transfer your files, or pull from Github.
-
How do I login?
-
Username:
demo -
Password:
demo
-
Username:
-
Why was auroraOS discontinued?
- First and foremost: because I no longer agree with Glitch’s values. Private projects becoming a paid-only feature was the final straw, and the boosted plan isn’t exactly a good deal for what you get. Also, this happened.
- auroraOS was discontinued because I didn’t have much time on my hands to manage it, and because it was based on aging code that, when written, didn’t meet any security or performance standards nor did it even remotely follow good JavaScript, HTML, and CSS practices.
- File permissions were implemented absolutely horribly; for example, read-locked files could even be accessed through the readStatic path even if you didn’t have the proper permissions.
- The filesystem itself was implemented poorly; every action constituted a new HTTPS request. While this isn’t necessarily bad, if auroraOS were rewritten today, I would’ve used socket.io or something similar.
- Apps were not sandboxed. Not a big reason as this is something that’s hard to do in any web app, but if auroraOS were rewritten today, I would either put every app in an iframe, or use a custom GUI drawing system that auroraOS can 100% control, and run each app’s process in its own JavaScript VM (JS in JS)
- I always used the newest web platform features as soon as they came out, whether they were supported on the majority of browsers or not. This is why auroraOS doesn’t run on iOS <14 or most versions of Safari.
- Around auroraOS 5, I decided to absolutely replace the completely functional window manager with something a bit more modular and a whole lot broken. It’s a mess. I ended up somewhat reverting this change but it’s still not as good as it used to be.
- With the default themes, I used blur everywhere. Smh
- Settings app: since auroraOS 6 (?), became some weird half-broken app that was just…bad
- Terminal app: all commands were part of the Terminal app itself. Not easily extensible, and the text rendering itself was implemented horribly. If auroraOS were rewritten, I would rewrite this to act like the Windows Console Window Host, which listens to a process’s stdout, forwards stdin, etc.
- Files app: barely had any features.
- Write app: what even was this? Didn’t even have filesystem functionality lol
- auroraOS System:
- When launching an app and then closing it, the app’s JS heap usage would not be cleaned due to my horrible attempt at JS processes in a highly-constrained platform (the web, am I right?)
- Non-fs data storage: used quick.js. Probably the worst module you could use for the types of things that auroraOS stored out of the filesystem.
- Aging code: at first, auroraOS started out as simply a concept with no backend code at all. This was a problem.
- Bad code: I learned JS through auroraOS. As such, some code is bad.
- CSS: used a lot of hacks, was just not maintainable; changing one thing would probably completely annihilate another.
- I understand that some of these issues could be fixed with another feature update, but…it was simply too much. It was time for auroraOS to go.
