Slashdot Log In
Athena: A Fast Kernel-Independent GUI OS
Posted by
timothy
on Thu Dec 28, 2000 12:50 AM
from the inertia-to-overcome dept.
from the inertia-to-overcome dept.
Per Wigren writes: "I just found out about Athena OS which got me really amazed. It's a 100% OO, kernel-independent GUI OS with an XML-based scriptinglanguage called DML that allows the user to edit the OS itself, as well as creating simple applications and extensive GUI interfaces! It's extremely fast! It started an Amiga Workbench-clone desktop with draggable screens in less than 2 seconds... Download is less than 1M ... I honestly think Athena has potential to obsolete both Gnome and KDE ..." Take note of these words from the FAQ regarding Athena's terms: "[O]pen source may be something of a misnomer from a purist's point of view. Linux users should note that Pandora has nothing to do with the GPL or any other public licensing scheme."
This discussion has been archived.
No new comments can be posted.
Athena: A Fast Kernel-Independent GUI OS
|
Log In/Create an Account
| Top
| 190 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Sounds fishy... (Score:3)
If it's from X, well, that's cool (BSD-style). If it's from the Linux Kernel, that would probably not be cool (likely just GPLed). I guess we'll see when it comes out, but the reference to 'strict licensing terms' makes me a little leery.
Also, could they pick a new name before it comes out, please? Between MIT's Project Athena, and AtheOS, I'm confused already.
Until then, that's the most kick-ass version of twm I've ever seen, and at the moment it looks like they went through a lot of work to implement essentially a new version of Enlightenment on top of Linux; until they expand their platform support a bit I won't be that impressed.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
O/S requirements - who cares about the GUI? (Score:3)
OK, so there are a few non-GUI aspects to the Athena product, but the overall focus is so strongly tied to their GUI in virtually all areas that it raises the question of whether they are addressing a real requirement. Operating systems do a lot of things and managing graphics visuals and graphic-oriented input is only one of them, and a fairly peripheral task at that, arguably one that should be abstracted out rather than permeating the design.
Without clear separation of concepts you lose traceability of design requirements and hence of product quality --- this applies almost universally. In the fullness of time, the end result for Athena is going to be a fancy GUI system and a poor operating system, I'd venture.
Follow the rules! (Score:3)
It is very important that when you use the word 'operating system', you only refer to versions of unix. You must understand that linux is superior to all other unixes, but that the operating system that was the great pure evil and the companies that were the great satan in the eighties (IBM, HP, Sun and SGI) are now cool. Some people even seem to think Apple is now coolish, because it does something with a free unix.
Examples of things that are NOT and operating system: windows (32 bit patch on a graphical userinterface for an obsolete interrupt handler ripped off from cp/m), the driver software of gamig consoles (no unix shell), NT (a vms rip-off, which wasn't a real OS anyway, because we don't understand how the shell works).
If you don't follow these rules, you are not showing your dedication to linux and open source. Remember how compaq were slagged off for offering the linux binaries for the DEC fortran compiler free for download? "Where are the sources?!!" and "This is a deliberate attempt to torpedo the vastly superior but non commercial gnu f77 project" and "How dare they pollute linux with a compiler for an inferior language"
If you are still reading: I was quite impressed with the athena demo. I hope it will run independant of X11 soon.
The real news (Score:3)
Re:OK, this is just crap (Score:3)
download XML documents, and an associated XSL document would turn it into something displayable on the client side. God forbid a Perl, Java, PHP, or ASP program on the server do this for you
What if the client wants to get the data displayed in a format they can control? Surely you don't suggest implementing everything on the server? Perhaps clients should be spared the processor cycles necessary to change font sizes too, since the site designer obviously knows what's best for everyone.
OK, a little harsh maybe. But you see my point. I think the concept of getting raw data from the server and being able to present it client-specifically is an awesome idea. You can always provide a suggested style for the user to view the data as you intended, but why would you stop those who want it from displaying it in a custom format?
you will see an example where they make a widget resizable by attaching "resize" objects to it. "resize" is an object?! Diagram that, UML-mongers!
Actually, this is a really cool design pattern called Decorator. Read up on it, it's actually a useful idea for some applications.
Re:Oh, the horror... (Score:3)
2. If you say "Open Source", you ought to read the definition at http://www.opensource.org/osd.html. Also, using the GPL does *not* turn over the copyright on your project to the FSF or anyone else. Since I know you're smart enough to read a license and understand it, I can only assume you're lying in a cynical attempt to manipulate the Free Software community.
3. Preventing 3rd party distribution is not how Open Source works. If you're going to be honest, tell us you don't give a shit about Open Source, that you think it's a flawed business model, and that we're all a bunch of commies. But don't lie to us. We hate that.
decorator design pattern (Score:3)
Design Patterns [barnesandnoble.com]
This is the book that helped me move from writing Hello World type of oo applications to truly far reaching, extendable, and maintainable apps. Also, it made my applications more modular and therefore made the workload more easily distributed across a team of people... something that is very important to OSS developers and also something that they don't really teach you in school very well.
-pos
The truth is more important than the facts.
I like the idea, not the implementation. (Score:3)
This Athena OS takes this idea and makes an attempt in doing it. However, it simply is not gonna work because if does not have the 'charisma' to succeed. It is already getting bashed with the first posts on Slashdot.
My major technical qualm is with DML. This effort parallels the XPFE (XML,JS,CSS) GUI framework that is used in Mozilla. It would be so much better to use this Mozilla technology because it has a better chance of succeeding (ask me if you want some reasons).
Anyway, life goes on, and maybe something else that is better will crop up soon.
kernel-independent? (Score:3)
Isn't a kernel defined as any abstract layer immediately above the machine? And an OS is generally defined by its kernel. Assuming it really existed, a kernel-free OS would require all binary software to already be in machine instructions (i.e. no OS, a contradiction) -- or that a copy of the "kernel"/OS be part of every software component(pretty useless).
These guys are playing a simple game of symantics and not calling their kernel what it really is.
Not to be confused with....AtheOS (Score:3)
Is anybody else confused? I am.
Re:Cross-platform-o-rama! (Score:3)
What about Eazel (Score:3)
like SashXB, just worse (Score:3)
Time for a harsh dose of reality..... (Score:4)
1) This document could be used to describe Win32, NeXTStep, BeOS, etc. (except without the B.S. about not having a kernel).
2) API's are not necessarily procedural as they describe. Certainly BeOS is a good example of this, as are the standard Java libraries.
3) OO languages do not "translate" down to procedural code. They can and do compile down to binaries, depending on the implementation. Binaries, btw, are written in the CPU's native instruction set, and there is basically no other way to do it (besides using an interpreter which is -gasp- written in binary). I can only imagine these guys are talking about the Cfront compiler which implemented the original C++, or the various freeware Eiffel and Sather compilers I've seen. Certainly there are other ways to go.
4) They are essentially saying that reference counting is better than automatic memory management. Certainly that is debatable, but guess what? Most OS API's are C or C++, so they already do reference counting to manage their objects. This is not a revolutionary concept.
5) This is an "operating system", but it relies on something else to provide hardware abstraction. Guess what, it's NOT an operating system then.
6) This project does what Taligent, Java, Oberon, Smalltalk, Inferno, etc. have either tried or succeeded in doing. Revolutionary? I don't think so.
But finally, by FAR the clearest indicator that this thing is not going to make it is that they don't have a very clear set of requirements. If you look at their "Goals", they are entirely "OS designer-centric" rather than based on some final result that the end user of the system is going to get. This is a clear sign that this is just an academic exercise with no real purpose. They don't even make a clear case for the problem that's out there which they are trying to solve.
Two points (Score:4)
- What if the client wants to get the data displayed in a format they can control?
... I think the concept of getting raw data from the server and being able to present it client-specifically is an awesome idea.
Yeah, but that's not the concept behind XML/XSL. It is, to some extent, the concept behind XML; the server delivers raw data for whatever purposes the client needs it. However, if I attach an XSL or XSLT document, then I'm telling you how I want it displayed. The issue is "where is the presentation layer"? If I deliver you HTML, that question has been determined: I'm at the presentation stage. If I deliver you some kind of XML, then I have no idea how (or if) the data is to be presented to a human.Your point is quite valid, but the issue of how data is delivered and presented is artificial. It was created by people who forgot that not all clients are web browsers and not all transports are HTTP. (Actually, they probably never knew, because they got out of school in 1996 and went to work at Microsoft.) "Web" designers who use a Model-View-Controller design don't have any problem delivering an "XML version" of their data, where appropriate. The XML+XSL was a clumsy one-size-fits all approach. "It's for browser! It's for middle tiers!" Oh I see... I'm a server and I don't know what I'm serving to or why, I just spray whatever data you want into any socket connection that comes my way. That works great until you start serving data that has some value (like account information or a telnet session or email for a particular recipient). Then the server has to be a little more careful about what data is sends and what it is willing to do on behalf of the client.
- Actually, this is a really cool design pattern called Decorator. Read up on it, it's actually a useful idea for some applications.
No it isn't. Adding a resize object to a widget in order to make it resizable is not a Decorator pattern. A proper use of the Decorator patter would be to create a DecoratedWidget base class that contained a reference ordinary Widget. The DecoratedWidget would pass through ordinary Widget methods and subclasses of DecoratedWidget could add "one-off" methods such as resize() without creating zillions of subclasses of Widget.This design pattern is heavily used in Java, particularly when doing a lot of AWT (GUI) programming (something I avoid, but I've done enough of it...). Decorators are particularly useful when your language doesn't support multiple inheritance (like Java). Java, in particular, supports a mechanism called an "interface" which is like a pure virtual object. You can "implent" as many interfaces as you'd like, but you have to provide method implementations for all of each interface's methods. Often, for an inteface "Foo", there will be a class called "SimpleFoo" that you can use in a Decorator pattern to provide the base functionality for implementations of Foo. Read up on it.
Fascinating trend in new operating systems. (Score:4)
This is definately a sign of the increasing tendencies of software torwards homogeneousness and platform independence. Even Microsoft has caught on with the
100% commercial and NOT open source (Score:4)
Emphasis is theirs.
Cute project, destined for failure. (Score:4)
Oh, the horror... (Score:4)
I always knew that Athena was going to get a hostile reaction from some sectors of the Linux community, but many of the comments I've been reading are just a little extreme (well, a lot). Whatever the reasons for such hostility, I have a few points to make:
P. Manias
Rocklyte Systems
New level of /. cluelessness (Score:4)
The remaining ones are about whether they should call themselves an OS and whether they should use the name Athena. Is Slashdot now News for Editors?
How about some actual discussion of the technology involved? Are there no nerds left on here?
OK, this is just crap (Score:5)
Have you ever seen one of those situations where someone takes a smattering of technical knowledge and industriously recreates something that already exists... but does it badly? (If you haven't seen this, Microsoft has a whole catalog of products to illustrate this point.)
There is so much cluelessness on the Athena OS site, it's really hard to figure out where to start, but getting down to the core technology: DML is stupid. DML is the "Object Oriented GUI language in XML." Buzzword compliant? You bet? Useful? Not!
XML is a rotten format for programming languages. Anyone who's worked with XSLT knows what I mean. XSLT (related to XSL) is, essentially, a programming language that converts XML documents into other XML documents and XSLT itself is (drum roll please) an XML document. Why? 'Cause XML documents are sooooo late 90's -- and in the late 90's, you could sell shit-on-a-stick if it was XML-compliant. If you've ever seen an XSLT program/document that did anything vaguely complex, you immediately think, "Fuck! I could do this in 10 lines of..." Perl? PHP? Java? Visual Basic? All of the above! There is no language that is not preferable to XSLT.
The idea that spawed XSL/XSLT was that in "the future", browsers wouldn't download HTML, they'd download XML documents, and an associated XSL document would turn it into something displayable on the client side. God forbid a Perl, Java, PHP, or ASP program on the server do this for you -- no, let's make the thin client fat again, by giving it the responsibility of not only rendering, but organizing the data. Proof positive that this was a dumb idea what that Internet Explorer 5.0 proudly featured a robust implementation of this idiocy.
So, already, we have the case that anyone who isn't laboring under the deficits inflicted by a head injury has figured out that you really don't want to force any kind of programming language to look like a valid XML document. So what is the big deal with "Athena OS"? Oh, it's a programming language that is XML-compliant. How clever.
This "XML-compliant" programming language causes you to do really weird things architecturally. If you read the whitepaper, you will see an example where they make a widget resizable by attaching "resize" objects to it. "resize" is an object?! Diagram that, UML-mongers!
Piled on top of basic Bad Technology(tm), are numerous statements that indicate that these guys have never looked at any other system. Their claims about the flexibility of their design are laughable to anyone who has seen Motif widget management or Java AWT LayoutManagers (GridBagLayout is a bear, but it's incredibly powerful). Seriously, they try to sound like they've invented a better mousetrap, but you start to wonder if they've ever seen a real mouse. Like, where did they get this gem:
- XML and HTML standards are defined by their respective organisations and have no direct association with Rocklyte Systems or the DML standard.
It's like they don't even know where HTML and XML come from... but whereever they're from, it's not Rocklyte Systems and we want to remind you of that. This is just laugh-out-loud funny.Cross-platform-o-rama! (Score:5)
- Java
...but six years too late and not nearly as good.it's a window manager (Score:5)
it may become more in the future. but calling a window manager an OS is a major exaggeration.
for it to be an OS it would need to allow me to log into it, and create an environment where i can run programs without them being aware that they are actually on a different system (the linux host).
i have seen nothing of that in the description.
greetings, eMBee.
--