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

bad at vijya

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Like
    bad at vijya reacted to Zen1th in Fuchas - An OS with focus on security   
    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
  2. Upvote
    bad at vijya got a reaction from Zen1th in OETF #15 - Universal Archive Format (URF)   
    this is just a draft, feel free to suggest whatever.
    URF v1.1
    Abstract
    This document describes the URF, intended to make mass file exchange easier.
    Rationale
    There are many competing methods of exchanging large amounts of files, and many are incomplete, such as TAR implementations, or proprietary, such as NeoPAKv1. With this in mind, a standard format will make file exchange less error prone.
    Conventions
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
    All strings are encoded with UTF-8, prepended with an ALI corresponding to the length of the string in bytes.
    Character specifications such as NULL and DC1 are part of US ASCII, unless otherwise specified.
    Concepts
    Signature: Data at the beginning of the File, marking the File as a URF format archive, and specifying the version. File Table: Data structure containing all file information. Entry: Any data sub-structure in the File Table. Entry Specifier byte: A byte describing how to decode the data contained in an Entry. Object: A filesystem structure, i.e.. "file" or "directory". Attributes: Data describing the size, offset, parent Object, and Object ID of an Object. Extended Attributes: Data describing non-core attributes such as Permissions, Owner, Security, etc. Producer: A program or process that generates data in this format. Consumer: A program or process that consumes data in this format. Arbitrary length integers
    Arbitrary length integers (ALIs) MAY be over 64-bits in precision. ALIs are little endian. For each byte, add the value of the first seven bits, shifted by 7 times the number of characters currently read bits, to the the read value and repeat until the 8th bit is 0.
    Signature
    The Signature MUST be URF (US-ASCII) followed by a DC1 character, or an unsigned 32-bit little endian integer equal to 1431455249. The next two bytes MUST be the version number, the first being the major version, the second being the minor version. The next two bytes MUST be DC2 followed by a NULL character.
    File Table
    The File Table MUST start after the Signature. This MUST contain all Entries, and MUST end with an EOH Entry. See EOH Entry.
    Entry
    An Entry MUST start with an Entry Specifier byte. The Entry Specifier byte MUST be followed with an ALI specifying the length. Data contained SHOULD be skipped if the Entry Specifier byte allows and the Entry Type is not understood.
    Entry Specifier byte
    An Entry Specifier byte MUST have the 7th bit set to 1. If the Consumer comes across an entry with the 7th bit not set to 1, the Consumer MUST stop reading the file and raise a fatal error. The 6th byte specifies if the entry is critical. The entry is critical if the 6th bit is set to 0. If the entry is critical and not understood, the Consumer should raise a fatal error; if the entry is non-critical, the Consumer SHOULD skip the entry and continue reading the file. If the 8th byte is set to 1, the Entry is a non-standard extension. Vendors MAY use this range for vendor-specific data.
    Filesystem Structure
    Any Object MUST have a Parent ID and an Object ID. Object ID 0 is reserved for the root directory.
    File naming conventions
    Object names MUST NOT contain any type of slash. Object names must also be of the 8.3 format, though the full name MAY be specified with Extended Attributes. Full names in Attributes MUST NOT contain any type of slash.
    File offsets
    File offsets are relative to the end of the File Table.
    Entry Type: File
    The Entry Specifier byte MUST be F, and the data contained MUST be the name as a string, followed by the file offset and file size represented as an ALI, then followed by the Object ID, then Parent ID.
    Entry type: Directory
    The Entry Specifier byte MUST be D, and the data contained MUST be the name as a string, followed by the Object ID, then Parent ID.
    Entry type: Extended Attributes
    The Entry Specifier byte MUST be x, and the data contained MUST be the Object ID of the Entry the Entry is describing, followed by a four byte Attribute and the value.
    Currently recognized attributes include, names in US-ASCII:
    NAME: The long name of the Object (String) PERM: The POSIX-compatible permissions of the Object (Unsigned 16-bit integer) W32P: Win32-compatible permissions of the Object, which override POSIX permissions (Unsigned 8-bit Integer, Read-Only [0x01], Hidden [0x02], System [0x04]) OTIM: Creation time of the Object (Unsigned 64-bit Integer) MTIM: Modification time of the Object (Unsigned 64-bit Integer) CTIM: Metadata update time of the Object (Unsigned 64-bit Integer ATIM: Access time of the Object (Unsigned 64-bit Integer) SCOS: Source OS of the Object (String) Entry type: EOH
    The Entry Specifier byte MUST be Z, and the data contained MUST be the offset required to reach the end of the file.
    Compressed URF naming convention
    In an environment with long names, the file extension SHOULD be urf followed by a period (.) and the compression method (i.e. gz, lzma, xz, deflate) In an environment with 8.3 names, the file extension MUST be one of the following:
    UMA for LZMA UXZ for XZ UGZ for Gzip UL4 for LZ4 UB2 for BZip2 TODO
    Document is incomplete. Document should outline how to build the Filesystem structure, etc. Document should be checked for clarity and rewritten if needed.
  3. Like
    bad at vijya reacted to MeltingBrain in KestrelOS - Safe and powerful Windows-alike OS   
    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.
  4. Like
    bad at vijya got a reaction from MeltingBrain in Zorya BIOS and Bootloader   
    Yea, no problem. I'll also probably add the option to make the zorya-modules and zorya-config folders part of the normal filesystem. Might change how Zorya stores options to specify if it should download the modules or load them from the github repo. But I'll have to test that on my PC since OCEmu locks up when I try to fetch things from HTTPS  
  5. Upvote
    bad at vijya reacted to MeltingBrain in Zorya BIOS and Bootloader   
    Just make two copies, one bios.lua being the original one with a very clear and user-friendly code, and a second one compressed using this site.
    That's how I could make a coloured user interface BIOS with of course ability to choose which file on what filesystem will be booted up, ability to flash bios from the bios menu itself and ability to get bios data into a file from the bios itself too, with the options to shutdown and reboot if necessary. Trust me, compressing the file will give you a lot more space for expansion.
  6. Upvote
    bad at vijya got a reaction from MeltingBrain in Zorya BIOS and Bootloader   
    Zorya BIOS
    Zorya BIOS is an extendable and configurable BIOS and bootloader, capable of booting any OS with the right extensions. It's similar to GRUB.
    (sorry in advance for bios.lua)
    All you need to install the BIOS is to flash bios.lua to a blank EEPROM, insert a blank floppy, then reboot. Note: This has only been tested on Tier 3 hardware and Lua 5.3. requires an Internet card.
    Github repo
    PRs are welcome!
     
    Future plans:
    Ability to load from non-managed disks (like disks formatted with msdosfs, etc) Make it easier to extend Clean up code! Ability to edit options from bootloader Automatically load an OS after n seconds
  7. Upvote
    bad at vijya got a reaction from Lizzian in Zorya BIOS and Bootloader   
    Zorya BIOS
    Zorya BIOS is an extendable and configurable BIOS and bootloader, capable of booting any OS with the right extensions. It's similar to GRUB.
    (sorry in advance for bios.lua)
    All you need to install the BIOS is to flash bios.lua to a blank EEPROM, insert a blank floppy, then reboot. Note: This has only been tested on Tier 3 hardware and Lua 5.3. requires an Internet card.
    Github repo
    PRs are welcome!
     
    Future plans:
    Ability to load from non-managed disks (like disks formatted with msdosfs, etc) Make it easier to extend Clean up code! Ability to edit options from bootloader Automatically load an OS after n seconds
×
×
  • Create New...

Important Information

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