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.
To read all comments associated with this story, please click here.
Member since:2005-07-06
>>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..
Member since:2006-03-20
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
Member since:
2007-06-22
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.