Kristian Van Der Vliet has implemented asynchronous input/output. This has been tested with QEmu, which shows increased performance both due to this and the also new implementation of memory-mapped files. A development build with async I/O is already available.
Other recent enhancements it includes are automatic log-in without password and installation by keyboard only, without needing a mouse.
Async I/O is implemented as a native POSIX interface. The available functions are aio_read() and aio_write(). In addition, the asynchronous case for msync() in memory-mapped files is now supported. In Syllable 0.6.6, async I/O is simulated in the GNU C library and executed synchronously. This was enough to make QEmu work, but now async I/O is actually implemented through a syscall kernel interface.
Originally, Syllable relied solely on pervasive multithreading for its exceptional responsiveness. A few years ago, a new scheduler was introduced that is more suitable to desktop use than the original round-robin scheduler. Async I/O will further enhance responsiveness in ported applications that use it.
Does anybody know if Java runs on Syllable yet?
I enjoy seeing Syllable continue to evolve. It’s good to have a bit of diversity in the Free software desktop. I hope for more from Syllable (and Haiku) in the future.
There is no JVM for Syllable.
The work we’ve done recently means that JamVM will soon be running. Although that doesn’t mean we’ll have a complete set of runtime classes, and anything GUI related is obviously not going to work on Syllable yet.
Hi Vanders,
It’s always interesting to read your posts on here and nice to see what you have to say.
One thing I occasionally wonder is whether there might some day be a bounties system for Syllable – do you have any thoughts on this? I don’t honestly know how well, especially for a relatively small project, these things work but it is something I’ve occasionally searched for in the past.
Do you have any thoughts on this?
Cheers,
Mark
I’ve always disliked bounties. I’d prefer people contribute because they want to, not because there might be money in it.
I also have concerns that any work that is contributed under a bounty may prove difficult to maintain once the original developer has collected the money: maintaining stuff as Syllable grows is already a problem due to the sheer amount of work involved.
I’d say bounties are potentially good for when people want to contribute but need a little bit of external motivation (or they need a justification for spending time on it that could be used on non-hobby stuff, perhaps). Still I think you make a good point …
… particularly here! OSS really works when developers maintain their code – a code-drop-and-run policy isn’t going to help anyone very much and it would seem that a bounty system might encourage this.
It still perhaps might be nice to have some suggested projects for different parts of the system, though? I had a poke around in the Syllable Kernel code ages ago and remember it being fairly tractable to understand – then I got distracted.
I occasionally wonder if I ought to revisit this; it seems like it would be easier to “make a difference” in contributing to Syllable than to contribute to Linux which already has squillions of hackers doing stuff.
We’ll have a short ToDo list up soon, and of course the bugs always need fixing!
We did also try a “Project of the Month” last year, which has turned into the Project of the Year when interest dropped off quickly.
You’d be more than welcome, certainly!
Good point – hence my concern when they do have bounties that there is no requirement to ensuring that the code is clean and maintainable for the long term. I for one aren’t apposed to bounties given that I’ve seen in projects mountains of things that have been ignored by the main developers and little interest in fixing them up by those outside the community. NWAM on OpenSolaris being the prime example of something that has been in development for over a year and lags so far behind NetworkManager it is painful.
I’ve always been interested in Syllable, but haven’t yet been able to try it out.
I notice that Syllable Desktop does not use the Linux kernel, while Syllable Server does use the Linux kernel.
So, to those who develop Syllable or those who already could try Syllable: Is the Syllable Desktop kernel really “better” for desktop use than the Linux kernel? If so, in what way?
Or is it just a matter of pride? (It took years to create the kernel, that’s why we continue using it, no matter if it’s actually better!)
This is a complicated question, and often quite emotive, so you’ll have to excuse me if I don’t provide a very in-depth answer. A very good starting point would be http://web.syllable.org/pages/about.html
The Syllable Desktop kernel is designed to be a good desktop kernel. It is low latency, low-overhead, fully re-entrant (it always has been), capable of spawning it’s own kernel threads, and is very lightweight.
There are technical points which we feel make the Syllable Desktop kernel better suited for desktop computers, such as 1:1 threads which are fully managed by the kernel, low-latency lightweight IPC in the form of message ports, a simple modular design with a stable kernel ABI, automatic hardware detection and driver management, very fast boot times etc.
For an OS like Syllable it’s also a practical advantage that allows us to get very good, very thin, vertical integration. Syllable does not have many layers of indirection that you get with Linux, and we do not need to co-ordinate our efforts across disparate groups of developers if we want to add functionality that spans the kernel, system libraries and user-space. This is one of the things that allow us to keep Syllable lightweight.
I just can’t help thinking a “tuned” Linux kernel would be the way to go, even if you avoided all the indirection layers in userspace (X, Xlib, Gtk…). Obviously much of the fun may be in messing with the kernel, but I can’t imagine Linux kernel couldn’t be made to support all the features Syllable kernel has, while still retaining the benefits of industry-supported codebase (drivers etc.).
Using relatively “standard” components is also a good insurance against sudden stagnation (and other work going to waste) if/when key developers find themselves with no time to contribute anymore (family, work, being hit by bus, …).
Linux kernel does more-or-less all the same stuff already that the Syllable-kernel does as far as I can see, and probably those things that it doesn’t do could be implemented in modules.. Atleast one benefit would be the huge amount of drivers that Linux kernel ships with. Just trim the kernel and leave out those features that aren’t used in Syllable?
If we used a different kernel, we would have to re-implement everything we already have and then we would be at the mercy of a third party.
A software monoculture is bad. There is plenty of space for more than one kernel.
I wasn’t complaining, I was rather wondering. How many things are there that aren’t already in Linux kernel, and how many of those features would be hard to add to it? And I was just thinking whether you have the manpower to write drivers for too many hardware devices..
The stable ABI would be a complete non-starter, and the Syllable Desktop has an in-kernel ELF loader & RTLD which does not exist in Linux. Message ports and 1:1 threads would also be a problem.
That’s the nice part: porting Linux drivers to Syllable is not very hard at all because the APIs are actually quite similar. Almost all of the drivers currently in Syllable come from Linux anyway.