AS OF 11TH JULY 2022, ALL SUPPORT AND MAINTENANCE ON THIS REPOSITORY HAS BEEN DROPPED.
Microsoft finally turned off whatever mechanism PolyMC was using to let people play multiplayer on Mojang accounts.
Use UltimMC. Use something like https://modrinth.com/mod/easyauth . Host your servers this way.
Microsoft have proven they are willing to remove a bought product off your hands if you don't agree to their new rules about it.
They have proven that "buying" something off of them means nothing and anything you've "bought" from Mojang means nothing.
They have stolen what they have been paid money for. Therefore they don't deserve to have anything bought off them at all.
And before any of you go "just migrate", look at the warning signs as to the ban systems.
Maybe watch FitMC's video: https://www.youtube.com/watch?v=rdoFUhd0EkI
Or maybe read the migration horror stories:
- https://www.reddit.com/r/xbox/comments/sscoa7/does_anyone_have_an_idea_why_was_i_locked_out_of/
- https://news.ycombinator.com/item?id=31551846
- https://answers.microsoft.com/en-us/xbox/forum/all/im-locked-out-of-minecraft-after-migrating-my/9f1f64cb-6a2d-4cd2-abb8-0010a6bc6f31
- https://www.reddit.com/r/Minecraft/comments/we8asn/why_microsoft_ever_since_i_was_forced_to_migrate/
- even rekrap1 got bitten by this: https://www.youtube.com/watch?v=rzPYH98TTMM
.
.
.
.
.
.
.
.
.
.
. OLD README BELOW
As per usual, no warranty, not my responsibility if this breaks, or if you somehow try to run it on an actual (non-OpenComputers) computer.
At least in theory: "efficient. multi-tasking. clean. security-oriented".
KittenOS NEO is an OpenComputers operating system designed for Tier 1 hardware.
This means, among other things, it has an operating overhead limit of 192KiB in os.totalMemory() units, on 32-bit or 64-bit runtimes (given the default scale value).
Unlike the original KittenOS (now in the "legacy" branch), it is also designed with some attempt at cleanliness.
It is recommended that you take out your OpenComputers CPU, and shift-right-click until it says "Architecture: Lua 5.3", if possible.
Then simply download the installer from inst.lua here, rename it to "init.lua" and put it on a blank disk.
Finally, remove all other disks and reboot.
KittenOS NEO will install itself.
(This does not account for custom EEPROMs.)
NOTE: Attempting to run the KittenOS NEO installer as a program in an OS will fail, giving you instructions as shown here.
Disclaimer: I Am Not A Lawyer. I probably screwed something up in this.
It would be really nice if, if I have screwed up, that you tell me how.
Preferably with a solution that fits the technological constraints.
Licensing in this project is rather fluid,
but everything that is not in repository/ is unconditionally under the following license:
Copyright (C) 2018-2021 by KittenOS NEO contributors
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
THIS SOFTWARE.
This will be referred to as "BSD0".
It should be considered equivalent to CC0, and this is the intent, but it is smaller, which is somewhat important when optimizing for size.
At this time, the majority of the code/ folder is by 20kdc, but exceptions may occur.
These exceptions will be documented below, and must be for a PR affecting code/ to be accepted:
No exceptions exist at this time.
The repository folder is much more complex, as the structure represents places in a running system, so licensing information cannot be directly bundled with the files that require it.
The contents of the repository/docs/licensing files represent a "full text" for a given license, used in order to ensure legal compliance with a given license's "distribute with the program" clauses.
It is assumed that this is sufficient.
A separate package is used for each license such that the user must go out of their way to not download the license.
The limitations of OpenComputers affect the available choices here, and having separate license copies for each package is not an available choice.
Nor is having a separate license package for each individual license, unless you would prefer an unbrowsable repository.
The contents of the repository/docs/repoauthors folder is a human-readable per-package manifest of all files and their licenses.
If you find this uncompliant with the license of a package, please request the removal of the affected packages.
It exists because it needs to exist. It does not represent the opinions of those who have contributed to the repository, only those of the person who digitally signed it (20kdc).
Touch calibration could be off if the setPrecise support mess didn't work properly.
Wide character support may encounter issues due to performance-saving tricks (?) in some old OC versions.
The 1.12.2 version being used at LimboCon doesn't have the issue, so it's been dealt with. Point is, not a KittenOS NEO bug if it happens.
Having a window around that uses the palette-setting interface can cause funky graphical issues on a window that does not receive or lose focus when the palette changes. The alternative is rerendering all windows on palette change, or attempting to detect this particular case. This isn't very fast, so the graphics corruption is considered worth it. Critical UI gets protected from this by having a set of 4 reserved colours, but this can't be expanded without hurting Tier 2 systems.
If you move a window over another window, that window has to rerender. The alternative is buffering the window. Since memory is a concern, that is not going to happen. Some windows are more expensive to render than others (klogo tries to use less RAM if the system is 192K, at the expense of disk access) - move the most expensive window out of the way, since once a window is top-most, moving it around is usually "free".
If the system runs out of memory, the kernel could crash, or alternatively the system goes into a limbo state. You're more or less doomed. Given that almost everything in Lua causes a memory allocation, I'm not exactly sure how I'd be supposed to fix this properly.
Any situation where the system fails to boot may be fixable with Safe Mode. This includes if you copied a sufficiently large bit of text into the persistent clipboard, and now Icecap or Everest won't start. The catch is, it wipes your settings. As the settings are always in RAM, and contain just about every fixable thing that can break your boot, nuking them should bring you to defaults.
And finally, just because a system can multitask somewhat on 192K doesn't mean it can do the impossible regarding memory usage. Lesson learned: Cleaner design -> Higher memory usage. So anyone who wants the design to be made even cleaner should probably reread this paragraph. (In R0, editing the kernel causes 192K systems to fail to open filedialogs. I've fixed this in R1. I don't know if I've screwed this up in R2, because all this focus on usability improvements has probably gone back a step regarding memory use.)
KittenOS NEO's installer, including the full KittenOS NEO base operating system, is 65536 bytes or below.
As the installer must be loaded in full into RAM, this is not negotiable.
If it can't be kept this way with the current compressor, then a better compressor will have to be made.
Frankly I don't even know what policy after that ought to be.
The tools are meant for internal use, so are thus designed to run on some generic Unix.
The tools that I haven't gotten rid of are the ones that still work properly.
Firstly, for an uncompressed installer (just to test installer basecode), you use mkucinst.lua.
Secondly, for a compressed installer, you use package.sh.
That rebuilds code.tar and inst.lua, and also prepares the final structure of the repository to upload.