@brynet: Seriously, it's not a problem. There aren't any device drivers on the system (beyond the console), so the only variables are the processor and, potentially, the BIOS. Knowing that it works on an AMD K7 (the presario) is very useful, because I don't have any AMD boxes.
Although, if that first box is really old/obscure, it would be nice to know what processor it has.
Flux OS - test request, looking for devs
-
NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS - test request, looking for devs
Not really old or obscure. It has an AMD Ahtlon CPU. Windows tells me:NickJohnson wrote:Although, if that first box is really old/obscure, it would be nice to know what processor it has.
ACPI\AUTHENTICAMD_-_X86_FAMILY_6_MODEL_8\_0
I am currently building my test farm and documenting the machines. Part of this will ofcourse be detailed CPUID info. When I get further I will put everything online but I have very little time the next 3 weeks. If you need more info just ask and I wills see what I can do
clange
-
NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: Flux OS
Just an update for any of you who are interested.
I got executable loading working a few months ago, which has allowed a huge development speed increase (userspace code is easy). The C library is mostly complete, save for some higher level stdio routines, documentation, and standards-compliant-ness; the native API is also mostly stable. Message passing is more advanced, with the option to either queue messages or handle them as events (you win, clange: for now...) The virtual filesystem (a daemon) has basic functionality, enough to be navigable and host multiple mounted filesystems, but the device manager and permissions daemon are still effectively nonexistent.
There are already drivers for the keyboard, screen, ATA controller, and initrd (which is two drivers: one for the whole initrd, one for the filesystem in it, which is a tape archive), as well as a simple but usable shell. As an artifact of the microkernel design and the unix-like handling of devices, tape archives within the initrd can already be loopback mounted as their own filesystems.
I think the project has recently reached 6000 SLOC total, but the kernel is still under 2000. However, it now has, along with the extra message passing features, the ability to have 128 threads per process, with dynamic allocation for stack pages and more copious in-code documentation.
I don't really need help right now (a personal friend has volunteered recently), but any of you are obviously welcome to check out the source or download the CD image from the GitHub download page. I know that it now breaks on some of my real hardware, but it should work with any virtual machine at the very least. I posted a screenshot a few days ago, although now many of the bugs in it are fixed.
I got executable loading working a few months ago, which has allowed a huge development speed increase (userspace code is easy). The C library is mostly complete, save for some higher level stdio routines, documentation, and standards-compliant-ness; the native API is also mostly stable. Message passing is more advanced, with the option to either queue messages or handle them as events (you win, clange: for now...) The virtual filesystem (a daemon) has basic functionality, enough to be navigable and host multiple mounted filesystems, but the device manager and permissions daemon are still effectively nonexistent.
There are already drivers for the keyboard, screen, ATA controller, and initrd (which is two drivers: one for the whole initrd, one for the filesystem in it, which is a tape archive), as well as a simple but usable shell. As an artifact of the microkernel design and the unix-like handling of devices, tape archives within the initrd can already be loopback mounted as their own filesystems.
I think the project has recently reached 6000 SLOC total, but the kernel is still under 2000. However, it now has, along with the extra message passing features, the ability to have 128 threads per process, with dynamic allocation for stack pages and more copious in-code documentation.
I don't really need help right now (a personal friend has volunteered recently), but any of you are obviously welcome to check out the source or download the CD image from the GitHub download page. I know that it now breaks on some of my real hardware, but it should work with any virtual machine at the very least. I posted a screenshot a few days ago, although now many of the bugs in it are fixed.