For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | belliash's commentsregister

To whom it may concern,

I understand that there have been concerns raised regarding the uniqueness of the code in my project. I want to clarify that I have a broad exposure to various open-source projects, including Boron, Carbon, Minoca, Palladium, and NeptuneOS, among others. My interaction with these projects is purely for educational purposes and to stay informed about different coding practices within the open-source community. This does not equate to copying their code for my own projects.

I utilize a programming tool called Codeium, which is equipped with AI capabilities based on the GPT-4 model. This sophisticated tool assists in generating code suggestions and snippets to aid in the development process. It is important to note that while Codeium's AI provides recommendations, it does so from an expansive dataset of open-source, properly licensed public code. However, as a developer, I exercise discretion over which suggestions I implement into my codebase. The AI's suggestions are merely a starting point, and I often enhance or modify them significantly in the context of my work.

In light of the concerns raised, I am committed to conducting a thorough review of the code in question. Should I find any similarities with the Minoca project, I am prepared to take the necessary steps. This may include rewriting or removing the code entirely, or appropriately crediting the original authors as per the licensing agreements and norms of the open-source community.

I take the originality and integrity of my work seriously and appreciate the opportunity to address any issues that may arise. Thank you for bringing this to my attention.


I am writing to address the concerns that have been raised regarding the code I contributed to enhance the Local Procedure Call (LPC) mechanism in ReactOS. I want to categorically deny these allegations and provide an explanation of my development process to clear any misunderstandings.

Firstly, I must emphasize that I have never accessed or reviewed the source code of WRK. My work on ReactOS's LPC improvements was conducted through legitimate reverse engineering practices. Reverse engineering is a recognized method for understanding system behaviors and is protected within the European Union under certain conditions as outlined in Directive 91/250/EEC and the Trade Secrets Directive 2016/943.

The system from which I reverse engineered had reached its End-Of-Life (EOL), and under the original licensing terms, reverse engineering for compatibility purposes is permissible. My intent was to ensure interoperability and enhance the functionality of ReactOS, which is a legally acceptable and common practice.

In the process of enhancing the LPC mechanism, I integrated the improvements with pre-existing code to form a coherent and functional system. The new function that I implemented, despite being short and the subject of criticism, was composed of calls to existing functions and references to global variables that are part of the ReactOS project. This function was necessary for the improved LPC mechanism to operate correctly within the system's context.


Hello,

I am excited to introduce ExectOS, a new open-source operating system built on the powerful XT architecture, a direct descendant of the time-tested NT architecture. With ExectOS, you will get full NT compatibility.

As a free, community-driven project, ExectOS not only incorporates clever ideas from other open-source initiatives but also stands out with our own unique innovations that set it apart. We've designed it to support both i686 and x86_64 architectures. It should be also easily portable to other architectures.

Dive into the world of ExectOS and join us in shaping its future. Learn more on our website at https://exectos.eu.org/, where you can explore our vision. If you are ready to be part of the conversation, our Discord server at https://discord.com/invite/zBzJ5qMGX7 is the perfect place to connect, collaborate, and contribute.


If I were going through the trouble of writing an adaptable, minimal μkernel, I would start with a capabilities-secure, efficient IPC, formally-verified one like seL4 and then build an NT-compatibility layer. This has a potential advantage of preventing entire classes of vulnerabilities. Finally, if going through such an exercise, might as well write 99.98% of it in Rust to also eliminate numerous traditional categories of frequently-encountered programming errors that oft repeat themselves.


GitHub.com/cl91/NeptuneOS

Source: I wrote this.


Please tell me you're working on this.


Not him, but multiple such efforts (not necessarily matching your exact description) exist.

LionsOS[0] is an effort by the seL4 foundation itself.

Makatea[1] is trying to implement a Qubes-equivalent on a safer seL4 base.

Genode[2] is an OS framework built around capabilities that supports several microkernels including seL4 itself.

0. https://lionsos.org/

1. https://trustworthy.systems/projects/makatea/

2. https://genode.org/


DOPE

Thanks for sharing!



What are the XT and NT architectures in this context? I couldn't find clear reaults when searching.


Saw this on their page:

"Unlike the NT™, system does not feature a separate Hardware Abstraction Layer (HAL) between the physical hardware and the rest of the OS. Instead, XT architecture integrates a hardware specific code with the kernel. The user mode is made up of subsystems and it has been designed to run applications written for many different types of operating systems. This allows us to implement any environment subsystem to support applications that are strictly written to the corresponding standard (eg. DOS, or POSIX)."


Modern NT builds haven't really been using the HAL the same way either. It's been a pain because windows on arm kernels have been pretty tied to Qualcomm hardware so far.


This is an ARM issue, not a Windows one. Same reason Linux needs device tree overlays.


HAL.dll was intended to solve the exact same problem as device trees. That's why there's custom HAL.dlls for weird x86 but not PC platforms like some of the SGI boxes. Stuff like sure, it's the same processor arch, but the interrupt controllers, system bus, etc are completely different and not introspectable via normal PC mechanisms.

The issue is that WoA kernels have moved away from heavily embracing hal.dll, instead inlining a lot of functions into the kernel that used to be hal.dll functions for perf reasons. If they kept the original architecture it would have been easy, but they've changed it fairly recently to be less portable.


"Instead, XT architecture integrates a hardware specific code with the kernel."

Isn't this a bad idea?


I'm not taking with authority here, but isn't Linux doing it like that, too?

When you're compiling the kernel you're able to toggle various hardware flags to add to the compilation.

And AMD graphics cards generally work better then NVIDIA (on Linux) because the official drivers have been upstreamed vs Nvidias that haven't


Sounds like you know more about it than I do!


It's a little hard to follow, but I'm thinking more monolithic kernel than "hybrid"?


You might want to change the title to a Show HN post: https://news.ycombinator.com/show


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You