If this becomes available, EROS and other persistent OS'es would be easier to develop and/or better fitting to available hardware?
If these things were in 10-100GB class, maybe we could unify random access memory and traditional more-or-less persistent storage (read: hard disks). Especially considering 32bit addressing is being left behind, so you could simply have it mapped to memory.
On the other hand, that annoying javascript scroller on their front page seriously damaged their credibility in my eyes. Also, keeping in mind, most of these 'revolutionary storage technologies' never see day of light.
I wonder if this is the future of NASA...:) On the other hand, if commercialization helps future missions, like putting three interferometers orbiting the sun, which effectively yields to a very high powered "telescope", helping to find those nearby planets.
Isn't CORBA pretty slow? If the request goes thru ORB (as opposed to be in-process), you get only magnitude of 1,000 requests per second (which is really low, IMHO). Is this true or am I severely misguided?
I think one would be better off using something completely different than calculators! What makes this interesting is exactly about how creative you can be when there's severe *lack* of resources (RAM, CPU power, etc). I think the point in this case is to figure out what is possible. When you have 2MB Flash, it's not so interesting anymore, because the limits are so much higher. If I simply wanted a portable (web)server, I'd rather take something like Yopy. By the way, the "weird thing that looks like a headphone jack" (two +5 TTL data lines + ground) is quite simple and elegant, although you're not going to get very high transfer rates at all with it. There is no UART, but the data is transmitted in a program loop...
Ise DCOP (and MCOP) easily portable and without any serious bloat *or* is it tied to KDE? Is there support for über fast SANs, can I invoke a remote object method using some SAN-hardware like Tandem in a matter of microseconds? Fast in-process calls are nice, but they don't solve all of the speed problems!
How open COM is, is there any open source implementation of it? Does it really support those fancy SANs with <10 microsecond latency? Hmm... so does MS's COM fulfill the requirements in this case? If so, where is Linux/*BSD/AtheOS/whatever port of it?
Re:AtheOS FAQ and mirrored screenshots
on
AtheOS
·
· Score: 1
I agree. It's also interesting to see multiple paths being taken in OS design. Some might be processor specific, some not, some might be more modular, some less. Effectively we're enumerating many possible OS solutions; remember, when there are million monkeys all writing their own OS, some of those might be a true pearl! And maybe the design decisions UNIX-like system designers have done aren't the only right ones.
I'd like to see a component interface in AtheOS like COM/CORBA, so that you can use components from dynamically loadable libraries, other systems in network and local servers with minimum overhead. Make it fast, something like 100 - 10,000 requests per second when on network, 1,000 - 100,000 rps when on local server and 10,000 - 1 000,000+ rps when component is being used as a dll. And support for some exotic SANs (system area network) with a *fast* request marshalling system would be pretty sweet for some fancy clustering solutions.:)
Oh and please create it so I can just throw some component binary at it, I can find out the interfaces, methods and properties of modules easily and dynamically, without having any IDLs or such beforehand.
Some day AtheOS might be really stable, fast and enjoyable to use. Or maybe not. We'll see. Anyways I'm truly happy to see a newcomer in this field.
Disclaimer: My knowledge about component object systems is still fairly superficial, feel free to point out my errors...:)
AtheOS is not ment to be a new UNIX, and I don't want AtheOS to be tied on hands and feets to fit within the boundaries of UNIX and POSIX. Nevertheless AtheOS does support large part's of the POSIX standard, and are therefor capable of running a wide range of the command line tools you normaly finds on a UNIX system. Some functionality is not there cause I have not have any need for it yet, or I have not had the time to implement it. Yet some other features are ommitted cause they are to incompatible with other features in AtheOS.
I also might mention that I do not have the POSIX standard, so most of it is implemented after linux/irix MAN pages:) Consequently not all the POSIX like function's are 100% conforming, but again they work well enough to make most utils I have attacked to compile.
AtheOS FAQ and mirrored screenshots
on
AtheOS
·
· Score: 5
AtheOS is a free operating system for the Intel architecture released under the GPL license. I have seen quite a few anouncements of "promising" OSes with "great potential" during the development of AtheOS. The problem is that when I follow the links I normally find a description of the concept, a floppy-bootloader written in assembly, and not much else. AtheOS is a bit more mature, and is already running quite a lot of software. As a "proof" I can tell that the server you currently are browsing is running the AtheOS operating system. AtheOS is not ment to be a new Unix clone (like Linux and *BSD) but a new clean desktop OS. It does not run X-windows, but has it's own heavy multithreaded GUI system. Not using X has its ups and downs. The big down is ofcourse the lack of application's that can be easily ported to the OS. Another down is that the current GUI does not support remote display, even though implementing it should not be hard at all. The up's is that the GUI interface is much more high-level, and is much better at defining how a GUI should work. This leads to better consistency between applications. Drag and drop, clippboard, and other forms of high-level communucation between apps are defined by the OS. This will hopefully lead to applications that work well together and that give the user an impression of a compleat system with consistency between applications. I belive this consistency is important so the user dosen't have to start from scratch each time she learns a new program to know.
The AtheOS GUI consists of two main components: An application server and a dll providing a C++ interface between the server and the application. The GUI is therfore programmed through a C++ API providing windows containing a hierarchy of widgets that all have their own graphical environment.
The kernel was written from scratch. It supports SMP (Symmetric Multi Processing), has a built-in network TCP/IP stack. It supports loadable device-drivers and file-systems. It provides threads and processes with several powerful communication systems that makes it easy, efficient and safe to create server/client implementations where both the server and the client run on the same machine. Threads can communicate through message ports (most common), shared memory, posix signals, semaphores, pipes, pty's, TCP/IP, and propably a few other method's as well.
If you have any questions or comments you can reach me at kurt@atheos.cx
Frequently Asked Questions
Q: When trying to boot AtheOS the screen flicker for a while and then everything is dead. Why?
A: It might be due to missing fonts in the atheos/sys/fonts directory (see INSTALL). If that is not the case check the boot.ini. Make sure the memory and boot-device settings ar ok. You might also try to disable some features by uncommenting any of the DISABLE_* entries in boot.ini If possible, taking a look at the kernel output from the seraial port as configured in boot.ini can often geve a clue to what when wrong.
Q: Why does my serial-mouse dont work?
A: Propably cause it is in COM2, currently only COM1 is scanned for a mouse. If you use a serial-mouse you MUST set the DEBUG_PORT to 2 (in boot.ini) even if you dont have a serial cable attached for the kernel-debugger.
Q: I have run AtheOS from the native FS for a while, and now I installed a new kernel, but it seems like it still boot with the old one. Why?
A: Since the bootloader don't know how to load the kernel from AFS you must also install it on your FAT partition (in atheos/sys).
Q: AtheOS boots, and the GUI seems to be working, but there is a problem with the mouse-pointer, it leaves a trail of pixels when moved, what's up?
A: The problem is most likely that you have selected a 15-bit screen-mode. Both the Matrox driver and the Vesa20 driver is broken in that they list's more screen-modes than the render-module supports. Only 16 and 32 bit are fully supported by now.
Q: What kind of architecture is the kernel built around? Monolitic, micro-kernel, nano-kernel?
A: I often ask myself that question to:) The kernel is very modular and the it have a well defined interface between the kernel and it's device-drivers and file-systems. So given that each component comunicate through a thin defined interface, and don't know much else about each other, it ressembles a micro-kernel. I am not sure if this is the right term though, since all kernel-components lives in kernel-space and is not protected from each other, this is all properties from a monolitic-kernel. I am a bit confused:)
Q: The GUI look very Amigaish, is it an AmigaOS clone?
A: No. In the beginning it was actualy ment to be one, but this days there is nothing resembling the AmigaOS in AtheOS other than the window-borders. This seems to be rather hard for the Amiga-community to grasp though. They still think AtheOS is an Amiga clone:) Hey the Window borders look like on my Amiga! It must be an Amiga clone Right? I find it rather amusing to see that the Amiga-hord think that the single-most important property of an OS is the window-borders:) BTW: You can replace the border-look by writing a plugin to the appserver so I guess the Amiga look will go away quite soon.
Q: Is it a BeOS clone?
A: No, AtheOS is not meant to be a BeOS clone. I have never run BeOS myself, but I have read a lot about it, and I realy like the high-level API's and the GUI. The AtheOS GUI is very inspired by BeOS, but it is not meant to be a clone. Even though many of the general concepts is similar, there is also many differences in the API details.
Someone go out, profile, find the critical path in x86 Mesa code and optimize it by handwritten assembly (using MMX, 3DNow! and SSE). See if you can decrease branching factor, make better use of modern L1 and L2 caches or reduce memory loads altogether and preload data from memory before actually using it.
Granted, portability is gone after that, but it's performance that matters, eh?
WORM.Slashdot is a worm that will work under most nerdy minds. Once the worm is launched, it uses person involved to waste valuable working time on daily basis reading Slashdot. It can also a number of ways to propagate: other web pages, by word of mouth, IRC and email by masquareding as something interesting.
Also known as:/.bomb
Category: WORM
Infection length: 100-400 posts, 1-100 slashdot.org loads per day
Virus definitions: May 23th, 2000
Threat assesment:
Damage: HIGH - Distribution: HIGH - Wild: HIGH
Wild
Number of infections: More than 1000000
Number of sites: 1 (slashdot.org)
Geographic distribution: HIGH
Threat containment: HIGH
Removal: HIGH
Damage
Payload
Large scale loading of web pages: mostly slashdot.org
Slashdot effect: More dangerous side effect when slashdot.org links to some external page
Lost sanity: Might make you write posts on subjects like "First Post!", "Beowulf cluster" and "Natalie Portman". That happens mostly only before total system breakdown.
Modified files:/dev/brain
Distribution
Word of mouth: Check this
Target of infection: Nerds
Technical description
Similar to the freshmeat virus, this worm uses nerd() calls to make users reading slashdot.org (and wasting valuable working time). The contents of worm is "Slashdot.org News for Nerds: Stuff that matters".
Removal:
Destroy all modems, network cards and other devices capable with TCP-IP networking.
It's quite possible to write a primitive TCP-IP stack on TI-85 and serve web pages from it. It has 32kB RAM (minus the screen area 128x64, 1kB) + 128kB ROM (hmm... maybe it would be possible to replace this with EPROM?). Lower 32kB is mapped for ROM with bank switching and upper 32kB for RAM. It's running ~6MHz Z-80. You can pretty easily turbocharge it by just modifying one capacitor on the circuit board, but of course it eats a lot more batteries up then. Z80 is able to execute about one instruction every 4-8 cycles, so it's not that fast, but some guys programmed a Wolfenstein clone, Daedalus framerates being like 5 frames per second on so on unmodified TI-85! Ricochet + Daedalus + some extra programming = deathmatch on TI-85?:)
There's also a 512kB memory expansion for it, although it's more like a RAM-disk.
TI-85 a neat system if you're such person who wants to play with gadgetry (and modify it too). And it's pretty cheap too.
AFAIK, Athlons *do* support SMP, it's just the motherboards are missing... Athlon is using Alpha EV6, which supports per processor bus in contrast of Intels shared bus between all processors. Intel has some major problems with >4-way systems just because of this. Athlons should be able to do better when we finally get those MBs.:)
Mozilla's user interface isn't all that speedy yet; but it's important that the main feature of a web browser, page rendering works and works really fast. That's what matters, right? Please remember current Mozilla is still pre-beta. They still have all the debugging code bloat in it! There are versions of Mozilla that don't use it's own widget set (controls in Windows speak, gadgets in Amiga speak) for UI, which have *much* faster response for user interface events. IE is going to get run for it's money from Mozilla project.
Windows *does* anti-alias correctly over non-uniform background (ie. it really blends the pixels properly). Please do your research first.:) The screenshot demonstrated alpha transparency, not anti-aliasing (or if it did, it's really horrible kind of!)
Sorry, but Windows doesn't certainly do Gaussian blur or any other simple trick. It correctly renders anti-aliased fonts with TrueType hints. As much as we love to bash Windows, give credit where it's due.
Slashdot Mirror
If this becomes available, EROS and other persistent OS'es would be easier to develop and/or better fitting to available hardware?
If these things were in 10-100GB class, maybe we could unify random access memory and traditional more-or-less persistent storage (read: hard disks). Especially considering 32bit addressing is being left behind, so you could simply have it mapped to memory.
On the other hand, that annoying javascript scroller on their front page seriously damaged their credibility in my eyes. Also, keeping in mind, most of these 'revolutionary storage technologies' never see day of light.
I wonder if this is the future of NASA... :) On the other hand, if commercialization helps future missions, like putting three interferometers orbiting the sun, which effectively yields to a very high powered "telescope", helping to find those nearby planets.
Isn't CORBA pretty slow? If the request goes thru ORB (as opposed to be in-process), you get only magnitude of 1,000 requests per second (which is really low, IMHO). Is this true or am I severely misguided?
I think one would be better off using something completely different than calculators! What makes this interesting is exactly about how creative you can be when there's severe *lack* of resources (RAM, CPU power, etc). I think the point in this case is to figure out what is possible. When you have 2MB Flash, it's not so interesting anymore, because the limits are so much higher. If I simply wanted a portable (web)server, I'd rather take something like Yopy. By the way, the "weird thing that looks like a headphone jack" (two +5 TTL data lines + ground) is quite simple and elegant, although you're not going to get very high transfer rates at all with it. There is no UART, but the data is transmitted in a program loop...
Ise DCOP (and MCOP) easily portable and without any serious bloat *or* is it tied to KDE? Is there support for über fast SANs, can I invoke a remote object method using some SAN-hardware like Tandem in a matter of microseconds? Fast in-process calls are nice, but they don't solve all of the speed problems!
How open COM is, is there any open source implementation of it? Does it really support those fancy SANs with <10 microsecond latency? Hmm... so does MS's COM fulfill the requirements in this case? If so, where is Linux/*BSD/AtheOS/whatever port of it?
From Atheos screenshots page (http://www.atheos.cx/screenshots.php3)
More mirrored screenshots:
mutated.png and tabview.png
All screenshots as crappy jpegs
mutated.jpg, tabview.jpg, shot1.jpg, shot2.jpg, shot3.jpg and shot4.jpg
I agree. It's also interesting to see multiple paths being taken in OS design. Some might be processor specific, some not, some might be more modular, some less. Effectively we're enumerating many possible OS solutions; remember, when there are million monkeys all writing their own OS, some of those might be a true pearl! And maybe the design decisions UNIX-like system designers have done aren't the only right ones.
I'd like to see a component interface in AtheOS like COM/CORBA, so that you can use components from dynamically loadable libraries, other systems in network and local servers with minimum overhead. Make it fast, something like 100 - 10,000 requests per second when on network, 1,000 - 100,000 rps when on local server and 10,000 - 1 000,000+ rps when component is being used as a dll. And support for some exotic SANs (system area network) with a *fast* request marshalling system would be pretty sweet for some fancy clustering solutions. :)
Oh and please create it so I can just throw some component binary at it, I can find out the interfaces, methods and properties of modules easily and dynamically, without having any IDLs or such beforehand.
Some day AtheOS might be really stable, fast and enjoyable to use. Or maybe not. We'll see. Anyways I'm truly happy to see a newcomer in this field.
Disclaimer: My knowledge about component object systems is still fairly superficial, feel free to point out my errors... :)
Is AtheOS POSIX compliant?
AtheOS is not ment to be a new UNIX, and I don't want AtheOS to be tied on hands and feets to fit within the boundaries of UNIX and POSIX. Nevertheless AtheOS does support large part's of the POSIX standard, and are therefor capable of running a wide range of the command line tools you normaly finds on a UNIX system. Some functionality is not there cause I have not have any need for it yet, or I have not had the time to implement it. Yet some other features are ommitted cause they are to incompatible with other features in AtheOS.
I also might mention that I do not have the POSIX standard, so most of it is implemented after linux/irix MAN pages :) Consequently not all the POSIX like function's are 100% conforming, but again they work well enough to make most utils I have attacked to compile.
From Atheos page (http://www.atheos.cx)
Mirrored screenshots:
Shot 1, Shot 2, Shot 3 and Shot 4
What is AtheOS?
AtheOS is a free operating system for the Intel architecture released under the GPL license. I have seen quite a few anouncements of "promising" OSes with "great potential" during the development of AtheOS. The problem is that when I follow the links I normally find a description of the concept, a floppy-bootloader written in assembly, and not much else. AtheOS is a bit more mature, and is already running quite a lot of software. As a "proof" I can tell that the server you currently are browsing is running the AtheOS operating system. AtheOS is not ment to be a new Unix clone (like Linux and *BSD) but a new clean desktop OS. It does not run X-windows, but has it's own heavy multithreaded GUI system. Not using X has its ups and downs. The big down is ofcourse the lack of application's that can be easily ported to the OS. Another down is that the current GUI does not support remote display, even though implementing it should not be hard at all. The up's is that the GUI interface is much more high-level, and is much better at defining how a GUI should work. This leads to better consistency between applications. Drag and drop, clippboard, and other forms of high-level communucation between apps are defined by the OS. This will hopefully lead to applications that work well together and that give the user an impression of a compleat system with consistency between applications. I belive this consistency is important so the user dosen't have to start from scratch each time she learns a new program to know.
The AtheOS GUI consists of two main components: An application server and a dll providing a C++ interface between the server and the application. The GUI is therfore programmed through a C++ API providing windows containing a hierarchy of widgets that all have their own graphical environment.
The kernel was written from scratch. It supports SMP (Symmetric Multi Processing), has a built-in network TCP/IP stack. It supports loadable device-drivers and file-systems. It provides threads and processes with several powerful communication systems that makes it easy, efficient and safe to create server/client implementations where both the server and the client run on the same machine. Threads can communicate through message ports (most common), shared memory, posix signals, semaphores, pipes, pty's, TCP/IP, and propably a few other method's as well.
If you have any questions or comments you can reach me at kurt@atheos.cx
Frequently Asked Questions
Q: When trying to boot AtheOS the screen flicker for a while and then everything is dead. Why?
A: It might be due to missing fonts in the atheos/sys/fonts directory (see INSTALL). If that is not the case check the boot.ini. Make sure the memory and boot-device settings ar ok. You might also try to disable some features by uncommenting any of the DISABLE_* entries in boot.ini If possible, taking a look at the kernel output from the seraial port as configured in boot.ini can often geve a clue to what when wrong.
Q: Why does my serial-mouse dont work?
A: Propably cause it is in COM2, currently only COM1 is scanned for a mouse. If you use a serial-mouse you MUST set the DEBUG_PORT to 2 (in boot.ini) even if you dont have a serial cable attached for the kernel-debugger.
Q: I have run AtheOS from the native FS for a while, and now I installed a new kernel, but it seems like it still boot with the old one. Why?
A: Since the bootloader don't know how to load the kernel from AFS you must also install it on your FAT partition (in atheos/sys).
Q: AtheOS boots, and the GUI seems to be working, but there is a problem with the mouse-pointer, it leaves a trail of pixels when moved, what's up?
A: The problem is most likely that you have selected a 15-bit screen-mode. Both the Matrox driver and the Vesa20 driver is broken in that they list's more screen-modes than the render-module supports. Only 16 and 32 bit are fully supported by now.
Q: What kind of architecture is the kernel built around? Monolitic, micro-kernel, nano-kernel?
A: I often ask myself that question to :) The kernel is very modular and the it have a well defined interface between the kernel and it's device-drivers and file-systems. So given that each component comunicate through a thin defined interface, and don't know much else about each other, it ressembles a micro-kernel. I am not sure if this is the right term though, since all kernel-components lives in kernel-space and is not protected from each other, this is all properties from a monolitic-kernel. I am a bit confused :)
Q: The GUI look very Amigaish, is it an AmigaOS clone?
A: No. In the beginning it was actualy ment to be one, but this days there is nothing resembling the AmigaOS in AtheOS other than the window-borders. This seems to be rather hard for the Amiga-community to grasp though. They still think AtheOS is an Amiga clone :) Hey the Window borders look like on my Amiga! It must be an Amiga clone Right? I find it rather amusing to see that the Amiga-hord think that the single-most important property of an OS is the window-borders :) BTW: You can replace the border-look by writing a plugin to the appserver so I guess the Amiga look will go away quite soon.
Q: Is it a BeOS clone?
A: No, AtheOS is not meant to be a BeOS clone. I have never run BeOS myself, but I have read a lot about it, and I realy like the high-level API's and the GUI. The AtheOS GUI is very inspired by BeOS, but it is not meant to be a clone. Even though many of the general concepts is similar, there is also many differences in the API details.
Someone go out, profile, find the critical path in x86 Mesa code and optimize it by handwritten assembly (using MMX, 3DNow! and SSE). See if you can decrease branching factor, make better use of modern L1 and L2 caches or reduce memory loads altogether and preload data from memory before actually using it.
Granted, portability is gone after that, but it's performance that matters, eh?
Hey, don't look at me! :)
WORM.Slashdot is a worm that will work under most nerdy minds. Once the worm is launched, it uses person involved to waste valuable working time on daily basis reading Slashdot. It can also a number of ways to propagate: other web pages, by word of mouth, IRC and email by masquareding as something interesting.
Also known as: /.bomb
Category: WORM
Infection length: 100-400 posts, 1-100 slashdot.org loads per day
Virus definitions: May 23th, 2000
Threat assesment:
Damage: HIGH - Distribution: HIGH - Wild: HIGH
Wild
Damage
Distribution
Technical description
Similar to the freshmeat virus, this worm uses nerd() calls to make users reading slashdot.org (and wasting valuable working time). The contents of worm is "Slashdot.org News for Nerds: Stuff that matters".
Removal:
Write-up by: Jage May 23th, 2000
This is funny. Laugh now.
It's quite possible to write a primitive TCP-IP stack on TI-85 and serve web pages from it. It has 32kB RAM (minus the screen area 128x64, 1kB) + 128kB ROM (hmm... maybe it would be possible to replace this with EPROM?). Lower 32kB is mapped for ROM with bank switching and upper 32kB for RAM. It's running ~6MHz Z-80. You can pretty easily turbocharge it by just modifying one capacitor on the circuit board, but of course it eats a lot more batteries up then. Z80 is able to execute about one instruction every 4-8 cycles, so it's not that fast, but some guys programmed a Wolfenstein clone, Daedalus framerates being like 5 frames per second on so on unmodified TI-85! Ricochet + Daedalus + some extra programming = deathmatch on TI-85? :)
There's also a 512kB memory expansion for it, although it's more like a RAM-disk.
TI-85 a neat system if you're such person who wants to play with gadgetry (and modify it too). And it's pretty cheap too.
Check this, it's done in Windows using standard GDI. Font anti-aliasing
AFAIK, Athlons *do* support SMP, it's just the motherboards are missing... Athlon is using Alpha EV6, which supports per processor bus in contrast of Intels shared bus between all processors. Intel has some major problems with >4-way systems just because of this. Athlons should be able to do better when we finally get those MBs. :)
A link to the parody.
Mozilla's user interface isn't all that speedy yet; but it's important that the main feature of a web browser, page rendering works and works really fast. That's what matters, right? Please remember current Mozilla is still pre-beta. They still have all the debugging code bloat in it! There are versions of Mozilla that don't use it's own widget set (controls in Windows speak, gadgets in Amiga speak) for UI, which have *much* faster response for user interface events. IE is going to get run for it's money from Mozilla project.
Windows *does* anti-alias correctly over non-uniform background (ie. it really blends the pixels properly). Please do your research first. :) The screenshot demonstrated alpha transparency, not anti-aliasing (or if it did, it's really horrible kind of!)
Sorry, but Windows doesn't certainly do Gaussian blur or any other simple trick. It correctly renders anti-aliased fonts with TrueType hints. As much as we love to bash Windows, give credit where it's due.