The Syllable project has published the source code for Syllable Server. The code to build Syllable is maintained in Builder, the build system. There is a main repository of build specifications and overlays for Syllable Desktop and Syllable Server. The code for Server is now completely published in the source repository. A package of Builder (11 MB) for Syllable Server has been released that corresponds to Syllable Server 0.2 with a few fixes. The procedure to build Syllable Server will be the subject of an article in a future Syllable Newsletter.
It’ll be interesting to see how Syllable Server differs from a standard Linux distro.
It’ll be interesting to see how Syllable Server differs from a standard Linux distro.
* Booting usually takes less than ten seconds
* A full GUI is built into the OS
* Support for a wide range of common hardware devices, including video, network, and sound cards from manufacturers such as Intel, AMD, 3Com, nVidia, and Creative (see Syllable Hardware for a complete list)
* Internet access through an Ethernet network (PPP and PPPoE are not fully supported yet, but are available in a test version)
* A graphical web browser (ABrowse), based on WebKit; an e-mail client (Whisper), and hundreds of other native applications
* A journalled file system, modelled on the BeOS file system
* An application launcher (like the Windows Start button)
* 99% POSIX compliance
* GUI-based preferences tools for networking, display preferences, user administration, etc.
* The entire source is available via the GPL and LGPL
* An object-oriented programming API
I guess everything is *different*. How large percent of POSIX is implemented in GNU/Linux? 50%?
That’s Syllable Desktop, not Syllable Server
At the moment, Syllable Server doesn’t have a GUI.
Hardware support will be like other Linux distros.
Our AFS filesystem won’t work on Syllable Server (because it’s a Linux system).
That’s Syllable Desktop, not Syllable Server
Now I am confused- what is Syllable? Linux distribution or Amiga OS clone? Desktop and Server got different base systems?
Syllable Desktop is based on Amiga, and it’s a complete operating system. Syllable Server is the same userspace built on top of a Linux kernel.
You are wrong. Syllable Desktop is based on/is AtheOS. The original maintainer stopped developing it and Syllable was born for the sake of keeping the project alive and the desktop of course.
Edited 2007-12-24 10:13
Syllable is an Open Source operating system. There is Syllable Desktop, which has it’s own kernel, drivers etc. and is a unique OS. Syllable Server is a new project which complements Desktop and is based on Linux. Eventually Server will run the same GUI that Desktop has.
If you want to try Desktop quickly there are LiveCD’s and VMWare images available. It also runs well on a wide range of hardware if you’d like to install it: http://web.syllable.org/pages/get-Syllable.html
Syllable is a bit like a cross between BeOS, Amiga and Linux.
I was under the impression that POSIX was mostly supported in Linux as well, around the 95-99% mark just like Syllable. I could be completely wrong about that though.
The main difference between Syllable Server and Linux will be that it uses it’s own widget toolkit and doesn’t use X for anything.
Why not migrate to linux kernel in the long run. It will solve alot of hardware support/features issuses in the long run. It is also much more responsitive as of 2.6.23, compared to previous versions. The x-windows is utter garbage imho especially if one tries to make a responsitive multithreaded app which handles events and drawing separately. The xcb library is also not a soulution and is not actively developed.
The problem with lots of linux distributions is that they try to reimplement the wheel by using things like hal/dbus/fam when one already has alot of posix stuff with the same functionality already in the kernel ( for example posix message queues instead of dbus or implement fam as a library and not as a daemon which just wastes resident memory ). Anyway, it’s an interesting project whatever direction it takes it will be interesting to look at it from time to time.
>>The xcb library is also not a solution and is not actively developed.<<
Uh? AFAIK, xcb is going to improve X-application responsiveness in case of multi-threading so 1) it is a (part of the) solution for responsiveness and 2) it is still worked on (although it was integrated into XLib differently from what was planned at the beginning).
As for the Posix vs Linux, well it’s a problem for the Unix point of view but this doesn’t matter for the desktop view., so I don’t see how this is relevant to Syllable use of Linux kernel..
The xcb library is also not a soulution and is not actively developed.
Wrong on both counts.
1) XCB is transparently threadsafe. Now that it exists, there’s nothing from making toolkits that are
completely thread-safe and async.
2) XCB is actively developed, and is actually now the base for Xlib.
for example posix message queues instead of dbus
Have you ever looked at d-bus? It doesn’t even vaguely resemble posix message queues.
1) DBus is strongly typed. I can look at a dbus message, and see what “object” in the process it’s
directed at. I can look at the types of arguments and the methdods. Etc.
Posix message queues are closer to raw sockets than to dbus.
or implement fam as a library and not as a daemon which just wastes resident memory
Because having a daemon to handle the kernel’s job AND a library to interact with the daemon is so much better. Right.
Sorry, but even though inotify isn’t all that great, I’d rather have a thin wrapper library around it than a daemon, and a thin wrapper library around the daemon.
Edited 2007-12-24 19:17
I think you meant that it is NOT based on Amiga.
Sorry, I meant AtheOS. They both start with an A.
And I think it’s similar to Amiga.
Edited 2007-12-24 04:39
offtopic: Happy christmas to everyone =)
Well, i actively developed using xlib and submitted a patch to xcb and an example to mailing list, and the bug still exist and the messages were mostly ignored.
The problem with xcb is that it still interfaces X11 which is a protocol and is serial, but the keyborad/mouse/video adapter are not and are parallely atached to the xserver, so why serialize them when they are not serial. Since most people use X on desktop, it should have beed developed for desktop and the networking stuff could be implemented as an extension.
Noone even uses native X over the network because it’s so damn slow. Also when you drag X windows you can sometomes see subwindows jerking because of synchronisation issues.
Also dont give me that about posix queues. You can send a generic Event sturcture which can have a member property, which will make your events typed.
if you are gonna use c++’ you can use typeid. which makes even this member property obsolete. The point is that they create absractions for the sake of abstractions.
Also you dont need a daemon to get inotify events. A library where you register callbacks on inotify events would be as good. And it can even be os-independent.
Anyway I speak out of my experience and frustration with some aspects i developed for.
Anyway i think that the syllable on linux is a great idea, partially because the original one doesn’t boot on my pc and the current version of linux kernel is respositive enough.
Edited 2007-12-25 16:57
Could you elaborate your point about xcb design, I didn’t understand it..
>>Since most people use X on desktop, it should have been developed for desktop and the networking stuff could be implemented as an extension.<<
Sorry but on office desktops, network transparency is really useful, so I like the network transparency “by default” design.
>>Noone even uses native X over the network because it’s so damn slow.<<
So I’m ‘noonne’? Unless you restrict a network to Internet, I’m using X over a LAN each day at work..
Blatant exaggerations make really hard to take your points seriously, you know..
>>Also when you drag X windows you can sometimes see subwindows jerking because of synchronisation issues.<<
It’s nice that you care about this issue and you try to fix it but frankly, I personally couldn’t care less about this issue and wouldn’t trade network transparency for a fix to this issue.
Well my original point is that networking design makes X serial(over the socket) but it doesn’t have to be so.
X is limited to 1 even queue, and if there are alot of events there, it stalls. Imagine one thread for a mouse and one for keyboard events( for example using select() on /dev/input/eventX). When i press a button, i lock a mutex in a window and change it’s properties and at the same time recieve an event in another thread from a mouse which is above another window which i can lock and do something dependent on mouse button. At this time nothing is drawn. Then a video adapter thread locks what’s on screen and draws it an so forth, while other threads can continue to recieve events. But in the case of X11 everything is serialized over the socket, ther parallelism is lost. All events come after each other and in case of Xlib each event blocks. But even xcb doesn’t have the advantage if one needs a reply.
I also don’t say you need any trade-off like network transparency. You can have a special thread that could gather all the events and send them over the network. I’ts just that X design traded off latency for those few than needed network transparency. So everyone has to suffer because of network transparency instead of
choice to suffer it only if they have to.
Regarding the xcb go to their homepage and try to find good documentation. I also have an example which works whith xlib but doesn’t work with xcb. I can send you the code on request. From my point of view xcb is a half-harted poorly documented attempt to address latency but not the design X protocol.
The whole thing could be remedied whith open source drivers at which point noone would have to use X11.
This maybe very off-topic but it’s one of the reasons projects like this on top of linux kernel make so much sence in my opinion. Linux has great hardware support now and a more flexible windowing system( or another os or whatever you call it, i’ll go with any) on top of it would be much better inmho.
Edited 2007-12-26 12:12
I think that the locking/ordering of events in the multiple queue design you’re suggesting must be quite hard:
Say Window A is selected at the beginning.
a-A mouse event select Window B.
b-A key is pressed.
Depending whether a or b occurred first, the key pressed event must be sent to Window A or B.
So these queue must sometime be synchronised carefuly..
I wonder how BeOS worked, with one queue or with multiple queues?
While I don’t know if a different thread&queue to handle each device is interesting, I think that a different thread in the GUI server for each client application makes sense as this simplify the multiplexing of clients: currently an application even if low priority may flood the X server, making the higher priority application appear less responsive than it ought to..
With a different thread in the X server for each client app, maybe the OS scheduling could solve this issue, of course there is still the risk of a priority inversion caused by shared resource (and as the videocard itself is shared, it’s not truly possible to avoid sharing)..