Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Search the Community

Showing results for tags 'operatingsystem'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL








Fediverse ID



Found 4 results

  1. PlotOS is restarting, from the ground up! So, i am rebuilding the os from the ground up, and i would be happy to see some people to help me Here is the github link: https://github.com/BomberPlayz/PlotOSReloaded
  2. Fuchas Fuchas in a Nutshell Fuchas uses drivers instdead of component access and support UAC (with new OS separate permissions!) ! Programs don't need to maintain integration with different components, the OS now does it! The driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs adapt to components with no effort (e.g. Computronics cards) Notice about security: Fuchas is currently alpha and "security" (if we can even call that security) isn't done at all, however the UAC is functional. Fuchas also has a permission system. Feared of viruses or foreign access? Control permissions! Each account can have its own set of permissions! Allow one to have free access on a specific drive? You can do that!. This is useful for computers on big servers with competivity. Fuchas doesn’t hide files starting with ".", it uses attributes, filesystem’s one if supported on unmanaged drives, or with a .dir file at file’s parent directory on managed drives. Attributes are currently being revamped to support groups and better permissions. Fuchas is also fast at startup, around 2x faster than OpenOS down like memory usage. And graphical features are optional, so you can use command-line on your T1 computer, and a graphical interface on T3, all on the same OS! And since the UI is compatible with 40x16 and doesn't uses a lot of memory, you can use both on a T1 computer!hey, i'm having a problem in some UAC system, i wouldn't be able to proof an administrator is an admin without some authority (which i can't have), how could i do it without a central authority ?hey, i'm having a problem in some UAC system, i wouldn't be able to proof an administrator is an admin without some authority (which i can't have), how could i do it without a central authority ? Extra Features A little list of feature is better than a thousand words: Driver system One network API to rule them all Included CPIO and VELX writer and parser. IPC UAC with SHA3-512 passwords Permission system OCX (drawing and UI library), already compatible with GPU buffers! Built-in documentation (not complete yet) Extensions to Lua API, like string.startsWith, string.split or string.toByteArray More compatibility with Lua specification's API (like availability of io.popen) Stardust: Imagine Wine, but for OpenOS. This allows to run OpenOS programs on Fuchas, like ShEdit Protected component system, unless a process has corresponding permissions, it must use drivers SJF (uses an average to predict next burst time) process scheduler One feature also being planned is disk encryption (will also work on managed filesystems), since you can't make a really secure way to manage permissions when the root authority and the client is both the same computer, disks will be able to be encrypted for maximum security. Interfaces Albeit Fuchas feels (and is) DOS-y, there are aliases to not upset Unix-ers, so you can still use "ls", "ps", "rm", etc. Install It OpenOS: Just type the following: pastebin run EbHYvEE8 MineOS: Search for the application 'Fuchas Installer'. Install it, launch it, and press Install. (Note that all comments about broken installation below are outdated, and installers has been fixed!) Links: GitHub, Wiki, Progress to next version
  3. First post here, hi. For the past few months, I’ve been working on an operating system for OpenComputers. It’s a monolithic, UNIX-like operating system. Note that Monolith will not currently work in OCEmu due to the lack of support for`computer.getDeviceInfo`. First, the advantages over OpenOS: - Monolith supports dynamically adding and removing screens, GPUs, and keyboards - it’ll automatically spawn a shell on an available combo and will try to match by tier. - Monolith’s userspace is properly sandboxed - there’s no way to completely crash the kernel from userland. - Monolith includes a fairly complete set of documentation, in the form of manual pages, for many system and user-level APIs. They are also available for online viewing here. - Monolith’s terminal is entirely VT100 - the `term` API is a wrapper around this and included only for compatibility. - The scheduler will automatically collect garbage if memory gets low, and includes a facility that avoids dropping signals. Your system may freeze for half a second or so, but all input will be registered and you’re less likely to OOM. - Monolith ships with the Minitel, and soon GERTi, network stacks out-of-the-box. - Monolith’s package manager, while admittedly somewhat basic, is faster than OPPM. - The provided `readline` implementation is ridiculously featured and the best I’ve written - and it’s even its own API. `io.stdin:read` is by default simply a wrapper around `readline`. - The recommended and default editor, `vled`, has support for optional syntax highlighting through a command-line flag. So far, only Lua is supported. Now, the disadvantages. - Shell redirects are not implemented. - Monolith requires a minimum of 256 kilobytes of RAM, or a single tier 1.5 stick, due to the userspace sandboxing. - Monolith does not *quiiiiiiite* have full OpenOS compatibility, though most programs should theoretically run out of the box - see `wget`, `pastebin`, `components`, and `lshw`, which are pretty much direct copies of the OpenOS implementations. The `event`, `internet`, and `buffer` libraries are also taken from OpenOS. - `vled` is slower (due to use of VT100) and slightly less featured than OpenOS’s `edit`. It’s also a little more obtuse thanks to the fact that it draws heavily from `vim`. - There are a few small and rather strange bugs in my `readline` implementation. They shouldn’t affect normal use too much, though, as they aren’t terribly noticeable except on tier 1 screens. The source code is available here if you want to try it out!
  4. KestrelOS GUI-based, Windows-alike, highly customizable, and safe Operating System for common pourposes What's the major GUI-based OS currently available? The amazing system created by Igor, called MineOS (I'm sure everyone by now knows about it). Igor's system is based on OpenOS, that looks like MacOS and is by itself the most amazing system released yet, with all sorts of programs and even 3D libraries which is mind blowing. So why create yet another GUI-based system? There are several reasons why I decided to take on this journey. First of all, the majority of OS's out there, including MineOS is based upon OpenOS, which makes it a bit streamline and boring, but also unsafe. KestrelOS is made entirely from scratch with it's own libraries, services and style. I wanted to create something new, that would give less freedom than OpenOS (which is KestrelOS's main disadvantage), over a much more secure way to process applications. I also wanted to make KestrelOS as simple as possible, so anyone that is familiar to Windows will recognize most of it's content. How exactly KestrelOS works? KestrelOS implements safety policy, where only so called "managers" have absolute control over the system's event management. The "heart" of the system is a manager called "taskman" (Task Manager). Every other manager is registered to taskman and is a read-only table with functions that cannot be altered once the system has booted up. This restrains a lot of freedom for the user, but also prevents malicious software of changing core functions of the system in order to spy or corrupt data. There is few core managers that will "steer" every process in the system, taskman being the most important one as it is the only library in the entire system that has access to a now unavailable command: computer.pullSignal This forces every application to register itself into taskman in order to be able to hook itself under the heartbeat. What is this weird "heartbeat" you're talking about? Taskman has a loop, in which it listens for any signal. I called it the heartbeat, because it waits only 0.25 of a second to update any tasks hooked under specific processes even if nothing happens. This allows multitasking, or for example updating the clock on the bottom-right of the screen What are the so-called "managers" doing? Those so-called managers are here to serve programs with several system services. For example, there's a manager called "driverman", which loads system drivers, which are usually a single library that communicates with a specified type of component. There's a driver for graphics, which is communicating with the GPU, but uses Igor's amazing double-buffering technique (although I made my own version of it from scratch, but it is very primitive right now) to draw into the screen. Drivers are basically bridges between gpu's, datacards etc. that make sure such a given component is available and return optimized methods to use those components better. Of course, every driver has it's own version, name, description, and can be retrieved manually from driverman using the driver id or name, in case you'd like to implement your own driver and use it. What other features it has? Well, most of the system features are actually the managers which act as the main "pillars" of the system. Here's few of main managers that I remember as of now (as I'm not on my home PC right now, I'm writing from my work PC): driverman - manages drivers fileman - manages mounts for different filesystems and resolves path using mounts taskman - heartbeat of the system, manages processes and tasks assigned to those processes regman - manages system's registry guiman - uses kgraphics driver from driverman to draw complex GUI elements on the screen ... (there's a few more that I can't remember now or that are under development) ... Any concerns/disadvantages? Well, like stated before, it actually restrains quite some core functions to prevent malicious application of accessing those in order to prevent system spying or corruption. This removes quite a lot of freedom, but once you log in and unlock everything, you should be able to edit that manually in the system files if you so desire. Any pictures? Well I'm on my work PC not at home so I can't do any pictures, what I can say is that most of the baseline managers are implement and that I'm working on the GUI now, so don't say hurray yet as I'm working on it. Sorry Release date? Undefined.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.