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

Zen1th

Members
  • Content Count

    68
  • Joined

  • Last visited

  • Days Won

    10

Reputation Activity

  1. Upvote
    Zen1th got a reaction from hohserg in Minecraft server on OC   
    Last demo video:
     
    No, it does not currently run modded minecraft (albeit it runs plugins made for this server), but one experiment i want to do for later is recreating a bit of OC mod in Lua, to make it run in this server, so that you can run Minecraft server in Minecraft server in Minecraft server in Minecraft server in ... until it crashes your PC lol.
  2. Like
    Zen1th got a reaction from Fingercomp in Minecraft server on OC   
    Not a Minecraft server about OC, but a Minecraft server running on OC. More specifically an 1.15.2 Minecraft server. (btw sorry for low video quality, but 2 Minecraft instances with one modded is CPU-intensive, so..)
     
    Installing
    Just look at the github: https://github.com/zenith391/OCMCS
  3. Upvote
    Zen1th got a reaction from Nexarius in Minecraft server on OC   
    Last demo video:
     
    No, it does not currently run modded minecraft (albeit it runs plugins made for this server), but one experiment i want to do for later is recreating a bit of OC mod in Lua, to make it run in this server, so that you can run Minecraft server in Minecraft server in Minecraft server in Minecraft server in ... until it crashes your PC lol.
  4. Upvote
    Zen1th got a reaction from hohserg in Lukyt - Java on OpenComputers (without mod)   
    A while ago i made a JVM in Lua with the first goal of running Java on OC, just because i like Java and we all know it's a good programming language.
    So here's the JVM running a program that fills GPU:

    Oops, made a typo.

    Ok at first this might not seem impressive at all, but now you can interact with components using Java! That's an awesome thing for Java-ers like me!
    Race to first Java OS in OC? Anyone?
    Here's the (simple) code i used above
    import lukyt.oc.Component; public class ComponentTest { public static void main(String[] args) { String gpu = Component.getPrimary("gpu"); Component.invoke(gpu, "setBackground", new Object[] {0x2D2D2D}); Component.invoke(gpu, "fill", new Object[] {1, 1, 160, 50, " "}); System.out.println("Filled screen with RGB 0x2D2D2D"); } } Here's GitHub page (to download and use on your favourite OC computer): https://github.com/zenith391/lukyt
  5. Upvote
    Zen1th got a reaction from hohserg in Lukyt - Java on OpenComputers (without mod)   
    If you ported Minecraft graphics system (tho rest is prob good) to OpenComputers it could run Minecraft
    Oh and i would also need to make Lukyt run Java 8, shouldn't be that hard, no?
     
  6. Upvote
    Zen1th reacted to BrightYC in Cyan BIOS   
    The world as I knew it had a problem.
    A plenty of bootloaders had already existed, and they'd all shared the same flaw: it wasn't me who made them.
    I've decided to put an end to that.


    Cyan is a multi-bootloader and a replacement for the plain Lua BIOS. The features it encompasses include:
    a whitelist to prevent random strangers from tampering with the computer a Lua interpreter to test your sudden ideas support for hot-plugging filesystems if you've forgot to insert a floppy the ability to format or label a filesystem, while we're at it loading the boot payload from the internet when you can't afford an HDD and a gorgeous, minimalistic design Pictures:


    To install on OpenOS, run the following:
    wget -fq https://raw.githubusercontent.com/BrightYC/Cyan/master/installer.lua && installer.lua Or, if you're a MineOS user, look for the program (bearing the same name) at your local AppMarket.
    Here's how the whitelist works. You add trusted users to the list when the installer asks you. Then the bootloader will ignore any signals from other people. That's it.
    Oh, and you can also choose a less restrictive option: the Cyan BIOS can wait for input from a trusted user. Before that an authorized person can't access the bootloader.
    Lastly, a couple of words about the Lua interpreter. It doesn't wrap the output, and the input command must be less than the screen width. The last restriction can be circumvented by copy-pasting the command.
    In addition to that, the bootloader defines the following functions:
    os.sleep([timeout: number]) proxy(componentName: string): table or nil — returns a component proxy by its name (cf. component.proxy, which takes an address) read(lastInput: string or nil): string or nil — a primitive io.read() print(...) The source code for the curious: https://github.com/BrightYC/Cyan
    P. S. Big thanks to @Fingercomp for his lecture about string escapes and writing this text.
     
  7. Like
    Zen1th got a reaction from Fingercomp in Lukyt - Java on OpenComputers (without mod)   
    A while ago i made a JVM in Lua with the first goal of running Java on OC, just because i like Java and we all know it's a good programming language.
    So here's the JVM running a program that fills GPU:

    Oops, made a typo.

    Ok at first this might not seem impressive at all, but now you can interact with components using Java! That's an awesome thing for Java-ers like me!
    Race to first Java OS in OC? Anyone?
    Here's the (simple) code i used above
    import lukyt.oc.Component; public class ComponentTest { public static void main(String[] args) { String gpu = Component.getPrimary("gpu"); Component.invoke(gpu, "setBackground", new Object[] {0x2D2D2D}); Component.invoke(gpu, "fill", new Object[] {1, 1, 160, 50, " "}); System.out.println("Filled screen with RGB 0x2D2D2D"); } } Here's GitHub page (to download and use on your favourite OC computer): https://github.com/zenith391/lukyt
  8. Upvote
    Zen1th reacted to Arcoverde in Scientific approach to Geolyzer   
    Due to quarantine, I got a bunch of time in my hands, I remember that since I first used this mod, back in MC 1.7 we had this phrase on Geolyzer description
     "It is theoretically possible to eliminate this noise by scanning repeatedly and finding an average. (Unconfirmed, needs further testing.)"
    Now, many years later, i do know quite some about statistics and got plenty of time
    So, lets begin
     
    We begin our dive in Statistics with an hypothesis, Does this number measured relate to an ore or stone, putting it in hardness terms, does the true number of hardness equal to 3(ores) or 1.5(stone), now we estabilish our null hypothesis. The null hypothesis is which one of them I want to minimize the most(it will make more sense in a bit), I prefer to avoid losing ores, therefore my null hypothesis is that the true hardness of the number measured=3 unless proven with enough evidence the contrary(again, more sense later)
    In statistic we have two kind of erros given in the table below, we want to minimize error type 1 even if type 2 grows, not so much as for example, mark every where as ore, 0 type 1 error and 100% of type 2. Or be it random where both errors are 50%,  so we have to have a small type 1 error without gigantic type 2 error ,let's try. I will from now on ommit "error" in type1 error.

     
    Let's first analyze on what I believe is the most traditional way, checking if a number is bigger than a threshold , I made a code to help me with that(DataCollector), given a line of 32 blocks, it will go through each one of them, measure 1000 times, and separate in intervals of 0,25. The result is given as every number smaller than the first column 

    It's quite hard to see it all, comparing it with a stone would be disastrous, but we can clearly see a pattern of every 4th increasing in one more row, so make it goes from 0 to 4, to 8 to... to 56, when possible I tried to use an exact distance, for example 40=sqrt(12^2+32^2) when not possible a very close number 56=sqrt(32^2+32^2+32^2), compare stones and ores side by side and we get this:

    based on this we can see the strengths and weakness of a single or multiple threshold, in my code I tried to give a general approach, so if you want to detect any other pair it's possible. 
    In my code, I used 2 variables, one to know the value when they meet, the distance where they meet, given by (Hhard-Lhard)*8, the second one is Havg, (Hhard+Lhard)/2, it gives the number when they meet. If the distance is smaller than "meet", the value will be bigger or lower than Havg but I will be sure after this check
    If we use a single threshold of >2.25 we would be fine up to 12, after our errors would be:
    16: type1=10.9% ; type2=11.4% | 20: type1=21.7% type2=19.2% | 24:type1=24.7% type2=23.9% | 28: type1=29.8% type2=26.7% | 32:type1=29.6% type2=32.7%
    As we can see, not good, not terrible
     if we want to be sure that its a stone or an ore, we must know what is the distance, find this new threshold, it could be done for each one of them but I dont see a particular distribution, but every 4 distance we have a good approximation of a uniform distribution( where every value is as likely to happen), but between  them it wont affect that much the chance of being wrong, type1 and type2 errors are equal to:
    16: 24% | 20: 42% | 24: 50.4% | 28: 58.1% | 32: 61.8% | 36: 65.8% | 40: 70.5% | 44:73.9% | 48: 75.4% | 56: 78.5%
    it seems bad to do it that way, we said earlier that our objective is to minimize type1 error, but we can use multiple measurements to decrease the error, we were already going to do that anyway for our second kind of analysis, I chose to do 6 but you can pick another number, I tried to make it easy to change in the code, butt keep in mind that every measurement takes a lot of time and energy, using the geolyzer is time consuming, for each time you add 55 seconds to scan, default(6) is about 5min 30s. The new errors after six times are, (error)^6:
    16: 0.1% | 20: 0.5%  | 24: 1.6%  | 28: 3.8% | 32: 5.6% | 36: 8,1% | 40: 12.2% | 44: 16% | 48: 18% | 56: 23.4%
    This is already much better, lower error compared to previus test, but this is still very high, we always have 32 distance, the height, with each command and with this test we would have a high chance missing anything, the robot would have to go around or increase the number of tests that adds up for a lot of time and energy, for such a poor result
    Now we begin using statistical theory, for that we need to know how the variance behaves given a distance, using Variance.lua code changing x and y and Variance1.lua to Z axis. This code gives Standard Deviation this represents how much from the mean it can be.

    plotting it in a graph we get that the standard deviation is given by approximately 0.35*distance. https://www.khanacademy.org/math/statistics-probability/sampling-distributions-library#what-is-a-sampling-distribution as this free class explains, the distribution of samples is a normal distribution, doesn't matter the original distribution. to visualize it, using DataCollector.lua code add ore nSamples to your code, default is 1, therefore it shows the original distribution now I am doing it with 6 samples

    the threshold for the average to given the Z value on the Ztable below is given by -Z*StandardDeviation(0.035*distance)/sqrt(nSamples(6)) + oreHardness(3)=OreT, Z is my type 1 error, my type2 error is given by StoneHardness*sqrt(nSamples)/(Z{positive now}*SD)=OreT. This is all a mess I know, lets give it some numbers, let's get a Z value equivalent of 5% wich is about 1.64 or 1.65, I will go with 1.64, distance of 56, we get -1.64*1.96/2.44+3=1,68, to find our type2 error we have Z=1.5*2.44/(1.96*1.68)=1.116 which is equal to 13.1%
    16: type1=5% type2=0.6% | 20: type2=1.9% | 24: 3.6% | 28: 5.3% | 32: 7.2% | 36: 8.8% | 40: 10% | 44:  11% | 48: 12% | 52: 13% | 56: 13,5%

    We can see that this is the best analysis until now overall, mainly on bigger distances, also even though its hard to understand, its super easy to implement it on code, but this analisys and the last one can be thought as independent events if we do both analysis we significantly lower the chance of any error for 56 distance we have type1=1.1% type2= 3.5%, wich is super low, but for my code I chose to do it until 40 of distance or 32^2+32^2+16^2=40^2, for me 1.1% is huge yet and 16*32*32 is enough volume but you can tune it to whatever you like
    I want to bring to attention that the code of both analysis was done with the ability of taking any pair in mind, be it dirt and stone or stone and ore, or ore and diamond block, it must have a decent enough interval tho. also it checks for anything lower than stone or bigger than ore, must do another analysis to remove the ones you want from it.
    https://github.com/gabiiel/GeolyzerOreFinder
    PS: I am not a professional coder or anything like that, I just wanted to burn some quarantine time, any questions or improvements or features, I am willing to help. I hope everyone could understand. Also I am leaving up to you guys how to get to the ores, this is a very low end program that can run on any machine, the ores are stored in a string there is a function to help write and read from it
    DataCollector.lua variance.lua variance1.lua
  9. Downvote
    Zen1th reacted to OC Best fan ever in Get Started With Lua!   
    Hello guys i am Symbo i know this is a simple tutorial but the fact that idk programming well let's talk about it! Now the programming language as named LUA is a programming language that is very easy to learn! Let's get start with an explication of what you sould start with.

    Now whos like me that dosen't know programming well your here to learn some. You sould go ahead and get ComputerCraft and learn CC's lua because it's the same but some apis are modified because OC uses direct lua. This is the most inpersive concept of learning lua without learning the apis.

    First of all i am not a programmer i will not teach you lua, it's your opinion if you want to learn lua or not. Now the fact that lua is easy to learn you sould first learn ComputerCraft... well heres some apis that will actualy help you programming some programs

    term.clear()
    term.setCursorPos(X, Y)
    print("STRING")

    Now those are some basic stuff. CC has basic lua so you will learn much much basics from CC, If you do that then you can learn OC because if you know CC already then it wil lbe 5x more easier to learn because only some apis are changed from the basic lua. The stuff you don't need at CC is components, components are the basic stuff you start with and they are optional for OC (Open Computers) Now you sould learn CC first and then OC because it will be very very easy to learn DIRECT LUA

    I recommend lua 5.3 because lua 5.2 is not even doing good anymore.
    Now if you wanna change the cpu to lua 5.3 then just brick right click in air and you will see in chat what type of lua you changed.

    Now replay if you want i will try replaying to the replay you did so if this makes no sense then i will call your replays comments.

    Now let's start with some basic stuff that people are very lazy to do
    Well the first stuff is learning, people whos lazy dosen't even have time to learn but they have to make thier programs. But what if programming languages was about explaining what the program does

    Like

    While the program is open then
        Open the other program.
    end

    Well this is not how it works.
    People stop being lazy reading and start learning!

    - Post end -
  10. Upvote
    Zen1th got a reaction from EveryOS in OETF #17 - Open HyperText Protocol   
    You can use the port that is not 80. since i said "SHOULD" and not "MUST". But i'll try to change this for better clarity
  11. Upvote
    Zen1th got a reaction from bad at vijya in OETF #16 - Open Extensible Firmware Interface   
    Open Extensible Firmware Interface v2.2
    DISCLAIMER: FOR LUA ARCHITECTURE, OEFI PRESENTS LITTLE TO NO ADVANTAGES!
    Lua BIOSes that implements OEFI must allow using conventional booting.
    Note that OEFI has been made to be more architecture-independent and will support ANY architecture able to read files and CPIO (basically any architecture with basic access to component and bitwise operations).
    Concepts
    Application: Executable code booting using OEFI in the EFI1 or EFI2 format. Conventional Booting: OpenComputers default booting method. Often called "BIOS" Operating System (OS) : Complex Application with user interaction and/or providing an environment for programs. Concept only used in this document for Conventional Booting OC: Shortcut for "Open Computers" Rationale
    Due to the limitation of current OC booting method which basically searches for an init.lua file, the most big problem is that this only work for Lua architecture, and what should other architectures use, init.asm? init.test? init.o? What happens if we want one drive to contains multiple inits for multiple architectures? Well that's where Open Extensible Firmware Interface comes handy. Using . The limitations OEFI fix in Conventional Booting in OC are:
    In Conventional Booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem. Conventional Booting doesn't have any native support for multiple applications. An OS that want to boot another one need to manually check for init.lua files in all filesystems, OEFI has oefi.getApplications() method for it, this is even worse for Applications booting on unmanaged drives Conventional Booting isn't made for any other architecture than Lua. And with it, like addressed below, it's impossible to have multiple applications for multiple architectures, while OEFI allows in theory to have one same drive to boot on all architectures it support, without tweaks needed from the user! OEFI is basically a much more extensible version of OETF #1 « Standardized booting of nonstandard architectures »
    Changelog
    2.2
    Removed OEFI configuration data, EEPROM data is now entirely up to the implementation. The specification now goes deeper into some problems (like C struct ordering, non-Lua architecture integration, or even how API version works in an architecture without FPU) 2.1
    Changed EFI2 format into a properties file for easier parsing Using CPIO instdead of URF for same reason: easier parsing Added OEFI Extensions, oefi.loadInternalFile(path) and oefi.setApplications(appTable) Fixed having put AwesomeCatgirl instdead of AdorableCatgirl as username for CAP conntribution Application Array
    The application array must contains tables (on Lua) as entries, if not on Lua those must be arrays (described below).
    If using tables, it must contains the drive address with as « drive » entry and the path (from drive) as « path » entry
    Example:
    { { drive = "af58dbe2-ff8c-433a-a871-c08723e01f25", path = ".efi/sampleos.efi" }, { drive = "af58dbe2-ff8c-433a-a871-c08723e01f25", path = ".efi/osOnSameDrive.efi2" }, { drive = "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", path = ".efi/another_os.efi" } } On non-Lua architectures, "drive" is index 0 and "path" is index 1
    Example:
    [ ["af58dbe2-ff8c-433a-a871-c08723e01f25", ".efi/sampleos.efi"], ["af58dbe2-ff8c-433a-a871-c08723e01f25", ".efi/osOnSameDrive.efi2"], ["015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", ".efi/another_os.efi"] ] As a 2D array, the entries should be appended in such a way it look like that: drive, path, drive, path, drive, path, ... . This is the default standard used by C for multi-dimensional arrays. If the language supports multi-dimensional arrays then the arrays of the language must be used.
    Finding Applications
    OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory.
    The OEFI should search files in ".efi" directory:
    If the file ends with .efi, then check if it contains CPIO signature, if no, boot in compatibility mode (OEFI1, which is not described anymore on this document).
    However if the same file contains that signature, then boot as normal.
    .efi2 will ALWAYS be in standard EFI2 format, unlike .efi which can be EFI or EFI2.
    .efi can be EFI1 or EFI2 to keep compatibility with old OEFI Applications, and to allow 8.3 filesystems to still support OEFI (would be problematic otherwise)
    API Methods
    Methods are same as in Version 1, of course API version is now 2 (logic), and some new methods are being added, so an implementation of OEFI must implement those methods (ignore oefi prefix),
    functions that can always be relied on (that are not optional) are in italic:
    oefi.loadInternalFile(path) - Loads file from current archive - new in OEFI 2.1 oefi.getAPIVersion() - Returns API version number. Unless an FPU is present in the architecture, version is represented as an 8.8 fixed point number, otherwise it is a 32-bit floating point number. This is 2.1 for this version. oefi.getImplementationName() - Returns implementation name oefi.getImplementationVersion() - Returns implementation version. Same number rules as for oefi.getAPIVersion(). oefi.getBootAddress() - replaces computer.getBootAddress() oefi.getApplications() - Optional, return an application table as described above oefi.setApplications(appTable) - Optional, set the application table (as described above) to appTable. - new in OEFI 2.1 oefi.loadfile(path) - Deprecated and optional, loads file from boot drive. (New Applications are expected to create their own loadfile, which is very simple to do) oefi.returnToOEFI() - Optional, recalls the OEFI program, the expected behavior is that the implementation will try to recover boot environment the most as possible, and then re-execute itself. oefi.execOEFIApp(drive, path) - Optional, boot another OEFI app by using the implementation's routine. oefi.getExtensions() - Optional, OEFI EXTensions is for non-standard features from implementation. This should always be used for implementation methods. The way this work is described below - new in OEFI 2.1 In Lua, API must be available in Global as the "oefi" table
    Else, API must be available as a pointer to a struct/class/anything like that available as argument to the code.
    Note: Optional functions are nil in Lua when not present, and are NULL in C (or any other language) when not present.
    For structs, their pointer must be passed as argument to boot function, not their content! Official C struct (not really easy to read for C beginners, mostly due to function pointers, but they are just basically pointers to a function: function pointers):
    struct application_entry { char* drive; char* path; } struct extension_entry { char* name; void* function; // pointer to any function } #ifdef NO_FPU // if the architecture doesn't have an FPU typedef float uint16_t; // define float as an 8.8 fixed point number #endif struct oefi_struct { char* (*loadfile)(char*); char* (*loadInternalFile)(char*); char* (*getBootAddress); application_entry* (*getApplications)(); // returns an array of application entries void (*setApplications)(application_entry*); float (*getAPIVersion)(); char* (*getImplementationName)(); float (*getImplementationVersion)(); void (*returnToOEFI)(); void (*execOEFIApp)(char*, char*); extension_entry* (*getExtensions)(); // returns an array of extension entries } Implements must have the same order as that C struct to preserve compatibility.
    OEFI Extensions work in the following way: If the architecture supports entries with keys, then a entry should be created containing the function (or its pointer), and the key should be equals to ImplementationName_MethodName_MethodVersion, ImplementationName should be same as in oefi.getImplementationName(), MethodVersion should be the revision number of a method, starts at 1. And MethodName is the name of the method. Example: SuperOEFI_DrawHandSpinner_2, which could be called (in Lua) via oefi.getExtensions().SuperOEFI_DrawHandSpinner_2()
    If tables are not supported, then the array (returned by oefi.getExtensions()) should contain all the methods as other arrays. So oefi_ext will be a 2D array. Each array (or struct) should contain the name (see above) at the first index (0 or 1, depends on architecture),  and a pointer to the function (or the function itself, if possible) at second index.
    Please also note that computer.setBootAddress(addr) should be REMOVED or throw an error, as due to how OEFI works, it is impossible for that function to work correctly! This is due to that Applications supporting OEFI doesn't need any compatibility methods as thoses conventional booting methods are only kept when booting a OS that only support conventional booting.
    Implementations can create their own methods, however it should ALWAYS BE INSIDE oefi.getExtensions(). (see above)
    EFI2
    EFI2 is the format for Applications, it replaces EFI(1) in , it is a CPIO archive. All files in that archive must be placed at root and are listed here:
    app.cfg app.exe app.exe is only the Application, it contains the code designed for target architecture, and will be launched by the OEFI .
    app.cfg is a configuration file using "key=value" scheme. The file should look like this:
    name=Application Name version=1.0 oefiVersion=2.1 arch=Lua archMinVer=5.2 archMaxVer=5.3 Space after key or before name is parsed as it and aren't ignored, be careful!
    "name" is equals to the name of the Application. Will always be a text
    "version" is equals to the version of the Application, if you don't want to fill it, just make it stay to 1.0. Will always be a decimal
    "arch" is a string with the name of supported architecture, "archMinVer" and "archMaxVer" are self-explanatory and will always be a decimal.
    Note that for archMinVer and archMaxVer, -1 can be used if a version doesn't make sense to the architecture to have a version. (example: a 6502 architecture)
    "oefiVersion" is equals to the OEFI version the Application has been designed to run with, if the "oefiVersion" field have a version incompatible with the current API version or if it's higher than the current one (ex. it's equals to 3 but we're on API v2.1, or it's equals to 1 but we're on API v2). This will also always be a decimal
    And finally, new lines are Unix-style: \n (line feed)
    With all thoses fields in mind, the EFI2 was designed to be durable, with only changes being to app.lon
    Configuration Data
    What's in EEPROM's data is up to the Implementation.
     

  12. Like
    Zen1th reacted to Log in GPS on microcontrollers   
    Program and library for building GPS network.
    https://github.com/DOOBW/OC-GPS
    Download:
    wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/bin/gps.lua /bin/gps.lua
    wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/lib/gps.lua /lib/gps.lua
    The functionality is the same as in the ComputerCraft.
    Additional command "flash" allows to upload firmware to EEPROM.
    When the coordinates are precisely determined, when flashing the position of the microcontroller can be omitted - at the first start it will determine its position from neighboring satellites and save on EEPROM.
    GPS network startup example.
     
  13. Upvote
    Zen1th got a reaction from bad at vijya in Fuchas - An OS with focus on security   
    Fuchas 0.4.0 is almost done 
    The new features are:
    MineOS installer: AVAILABLE Multi-user: AVAILABLE Dualboot (arleady used for 0.3.0): AVAILABLE CPIO-based installer (very very stable installation and allow updates): AVAILABLE Security! (permissions): AVAILABLE Default unicode support: AVAILABLE Virtual components: AVAILABLE (updated 06/30/2019)
  14. Like
    Zen1th got a reaction from bad at vijya in Fuchas - An OS with focus on security   
    Say hello to liburf's 2nd URF!

  15. Upvote
    Zen1th got a reaction from bad at vijya in OETF #16 - Open Extensible Firmware Interface   
    Thanks for the review. I will make a version 2 (on same post) to add the changes you suggested and some others changes. I will also soon make a more presentable form of the specification.
  16. Like
    Zen1th got a reaction from bad at vijya 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
  17. Upvote
    Zen1th got a reaction from Elektron72 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
  18. Like
    Zen1th got a reaction from TChapman500 in Plans for 1.14   
    As far as i know, no, i'm not a OpenComputers developer, however i have some knowledge in Forge modding, one problem they will have to encounter is that making OC compatible with 1.13.x would need changing most of the code (mostly because it makes usage of metadata, and some other things). So it will probably be hard and long to do, since it will be long, i think it will probably be in beta (or something like that) for 1.13, and finished when 1.14
     
    However, this is only what i'm saying, it isn't approved by any of OpenComputers active developers, so considerate what i said as a possible option
  19. Upvote
    Zen1th reacted to bad at vijya 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.
  20. Upvote
    Zen1th reacted to ZefTheFox in [Replaced][Release] Custom Cases For OC   
    THIS MOD IS NO LONGER SERVICED, PLEASE DOWNLOAD THIS INSTEAD!!!
     
     
    A while ago there was a post on here about someone making custom cases, I am not that person but I do have a release.  This may be improved upon in the future but as of right now it is in a completely usable state.
    This is a client side replacement for opencomputers. Do not use with normal opencomputers. This will be updated to release versions of OC and will not be for 1.7.10
    Theoretically this should be usable as a client connecting to a server with normal opencomputers, this was not tested.
    To use this install this modified version of opencomputers, it includes a custom case with it. If you want a different case you can choose to install a resource pack, I have made 2 so far. If a resource pack says it is incompatible for any reason ignore it, it's a single number in the pack.mcmeta that has to be different for certain minecraft versions, it will not effect the pack.
    The default case that comes with the mod:

    1.10, OC version 1.7.3
    1.11, OC version 1.7.3
    1.12, OC version 1.7.3
    NZXT Case: download

    IBM 5150 Case: download

     
    Let me know of any issues, or any suggestions for future cases.
     
     
  21. Like
    Zen1th got a reaction from Molinko in OETF #14 - Open Hypertext Markup Language   
    OHML v1.0.3
    OHML is a markup language based on the eXtensible Markup Language (XML), it is a simpler and OC-graphics adapted version of HTML.
    Why OHML?
    It all started when i noticed that most network programs/libraries were either DNS system, or Website system.
    However it is very important to maintain an universal language for webpages. It is the first step of having
    a stable and universal "OCranet", which will follow with server and client implementations. Protocols, etc..
    Concepts
    HRef: Shortcut for Hyperlink Reference Document Versions
    OHML patch versions (1.0.1, 1.0.5, etc.) minor changes (more understandable descriptions, new optional arguments) can be asked in comments section, might get accepted, and when features are froze, set as a new minor version of OHML specifications.
    OHML minor versions (1.2, 1.1, 1.42) OHML major versions (2, 4, 5) are to be proposed in comments sections and feature froze. Once released they will replace the outdated data in this post.
    Tags
    Table about all tags and their (XML) arguments is available in png format, attached to this topic.
    h1-h5
    6-2 sized OC character font title, each letter must be made from the number of character both in width and height. The font can be any font, as long as it respects the size rule. This would usually be made using a big font library.
    text
    This tag allows to display a text line. If putting the text in the plain document, due to the XML nature line breaks wouldn't be counted. In the text tag they aren't counted neither, but at each tag end, a line is skipped.
    script
    This contains any script made for any scripting language supported by the Browser. The attribute "lang" defines the scripting language, it defaults to "application/lua" for LuaWeb, however it remains an XML tag and will not work well with multi lines, the solution is CDATA, simply add a comment and add <![[CDATA, then at the end of script do another command and put ]]> , this will effectively allow the use of multi-line scripts.
    link
    Displays inline text, it haves, by default, a blue color. When it is clicked the page jumps to the hyperlink reference defined by "href" attribute.
    image
    Contains one attribute: "file". This is the path of the image treated as an Hyperlink reference.
    br
    Breaks a line, which mean that a text line is skipped, this act the same as <text></text> but cannot contains any text.
    button
    Clickable button with text being inside the tag. The text doesn't support OHML but will still be parsed as XML (a CDATA section is then recommended).
    Any <script> tag can set a listener on the button.
    "onclick" listener
    Arguments: mouseButton
    mouseButton is "left" for left button, "middle" for middle button and "right" for right button.
    box
    Container. It can contains any possible tags in OHML. It can be used for styling the element's bounds are fully customizable using Positioning, and while by default it is transparent, using Styling this can be used as a resizable background color.
    Tags Attributes
    Positioning
    Introduced in OHML v1.0.2, Positioning allows to position tags in an absolute or relative way.
    Tags have optional arguments "x", "y", "width", "height" and "relative"
    The "relative" argument is for using relative positions, vertical at first, and horizontal at last, we can use "up" (default) or "bottom", put a ";" for splitting, and add the horizontal value that can be "left" or "right".
    Relative positions works that if for example the value is "bottom;right", and if x = -5 and y = -5, the element Y will be at the most bottom point of the page (meaning that bottom for a page with elements not going after 10 for y, the bottom would be 10), added -5, which is equivalent of minus 5, and the element X will be at most-right point (generally viewport width) and will have minus 5.
    Meaning that for a page sizing 80;25, it would go at 75;20
    Styling
    Introduced in OHML v1.0.3, this allows elements to be stylized in little ways. This should eventually be superseded by a dedicated styling language.
    The styling addition introduces many attributes, these attributes are also by default transmitted to the element's childs
    bgcolor
    This attribute takes an hexadecimal RGB value and sets the background color of an element. The background is effective on the bounds of the element, which are its absolute x, y, width and height.
    color
    This attribute takes an hexadecimal RGB value and sets the foreground color of an element. Like bgcolor, the background is effective on the bounds of the element.
    Hyperlink Reference
    An hyperlink reference can be relative or absolute.
    If a HRef starts with any supported protocol name followed by "://" (ex: ohtp://), the link is fully absolute and will replace the current address. It must be an URI.
    Otherwise, if an HRef starts with "/", it is relative to the website host (e.g: ohtp://test.com), so, the full path is: {WEBSITE HOST} + {HREF}
    Finally, starts with nothing above, it is relative and should be appended to the actual URL
    URI are in the same format than real ones which is "protocol://host(/page)"
    OHML, being a markup language, will not support any kind of dynamic coding like <if> statements, <print> statements, etc., dynamic coding is handled by <script> tags and scripts languages supported by the browser. (Currently no script language has been made, it's coming).
    For now one implementation has been made and it is the reference one called Minescape.
     
     
  22. Upvote
    Zen1th got a reaction from ZefTheFox in [Replaced][Release] Custom Cases For OC   
    Oh my god! The cases are so much amazing, way better than the ugly and blocky ones that had 2 textures. I can't wait for more cases. Good job!
  23. Upvote
    Zen1th reacted to ZefTheFox in More Cases for OC   
    I am working on something similar, it will only be available for 1.8+ and I'm doing this in my free time so it may never get released. However it's almost ready, I will make a post once I get finished!
     
×
×
  • Create New...

Important Information

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