Issues

Mar - Oct 2005

Feb 2005
Jan 2005
Dec 2004
Nov 2004
Oct 2004
Sept 2004
Aug 2004
July 2004

Links

Syllable
OSNews

November 2004 Newsletter

Syllable is an in-development open source operating system for the home and small office user. The Syllable Development Newsletters are condensed reports on the past month's activity -- highlighting progress made and other project updates. For previous months, please see the links on the left of this page. Red text below denotes direct quotes from developers.

There were 171 mailing-list posts in November. A quiet month in terms of discussion, but with plenty of development work in various areas nonetheless -- kernel updates, Glibc work and plans for a meetup. Read on for the summaries...

Contents

• 1. Miscellaneous updates
• 2. Glibc progress
• 3. 3D engines
• 4. Kernel patches
• 5. Messaging systems
• 6. New LiveCD release
• 7. C++ in the kernel
• 8. SYL-CON planning
• 9. AEdit 1.6 released

1. Miscellaneous updates

Ever-busy Arno Klenke announced a bundle of patches updating several areas of the OS, seeing if there were any objections before checking them into the source tree:

ata driver:
*LBA48 support is now enabled by default
*The ata pci driver configures all controllers before adding them to the ata busmanager. This should fix a double detection of drives on mainboards that configure their pata and sata ports to the same legacy port address

scsi busmanager:
*Implemented scsi_readv()/scsi_writev() which seems to improve the performance of usb mass storage devices

aedit:
*Improved filerequester handling

kernel:
*Some cleanups of the SSE registers save/restore code
*Added cpu id for celeron m/pentium m

libsyllable:
*Changed the default look of the listview and treeview string nodes to look like the iconview
*Fixed a bug that occurrs when selecting items in single click mode in the iconview

Download:
http://www.liqwyd.com/arno/patches.zip

Syllable's new 'Kernel Dude', Jake Hamby, had a look at the kernel patches before checking them in. A few days later, Henrik Isaksson posted a quick message about his latest work:

I've checked in a few small patches:

- Arno's libsyllable patches.
- Added GetKeyCode() and GetQualifiers() to ShortcutKey.
- ATerm dead keys fix.

He also updated the CatFish app translation tool. After some technical discussion, Jake fixed the Radeon driver to work a 1400x1050 resolution, and finally, in the last few days of November, Arno posted a screenshot and mini changelog of his recent ColdFish music player developments:

here is a screenshot of the next coldfish version. The changes are:

*Support for plugins
*Added the coldfish dock plugin
*A port of the xmms blursk plugin

There will also be some other changes to the media system, e.g. a new way to sync audio and video

http://www.liqwyd.com/arno/coldfish.png

2. Glibc progress

The C library is an essential component in most modern operating systems, and Syllable uses GNU libc for this purpose (found in just about every Linux distribution). Currently, Syllable's version is slightly dated, so project lead Kristian Van Der Vliet had spent several months updating it the latest release -- 2.3.3. After much graft he was pleased to announce:

Fresh the Terminal not five minutes ago:

make[2]: Leaving directory `/boot/atheos/home/root/Source/Glibc/libc/login'
make -C elf others
make[2]: Entering directory `/boot/atheos/home/root/Source/Glibc/libc/elf'
make[2]: Nothing to be done for `others'.
make[2]: Leaving directory `/boot/atheos/home/root/Source/Glibc/libc/elf'
make[1]: Leaving directory `/boot/atheos/home/root/Source/Glibc/libc'
[root@pc021:~/Source/Glibc/libc-config]

Those of you paying attention might have already noticed that this is a successful exit from make. For Glibc 2.3.3, no more than a week out of sync with libc CVS and bang up to date with Syllable CVS.

My tests even run, too.

I need to clean up (The last few days saw some frantic hacking to remove large chunks of not-needed-on-Syllable code) and there are some nasty Syllable-specific Makefile hacks I need to make generic. But it compiles, and it runs (Well, the parts I've tested so far run).

I think I see a light at the end of the tunnel at long last.

Various developers cheered this news, while Jake Hamby offered to do some testing. Shortly after, Vanders posted a quick note that he'd coerced the 'make install' phase into working, before stumbling on a strange bug that had many coders baffled. It wasn't long before the problem was resolved; from here, Vanders posted more promising news and started uploading his work:

[Insert ticker-tape and brass band here]

After something like 14 months of hacking I've finally done it; Glibc 2.3.3 runs. I've got the Glibc libraries and a new libgcc_s.so compiled and all of my current tests compile and run without crashing, or producing funny results. Even Gcc 3.3.4 has been built against the new libc and works; a pretty good test case.

I'll upload binaries and source tonight; I know there are at least one or two of you who would like to have a play with Glibc 2.3.3 and I hope a few more of you are willing to test it (Don't worry, it installs alongside 2.1.2 so nothing will stop running)

With the files in place, Jake replied with some technical musings on executable formats:

Excellent news, Vanders! My excursions into glibc and gcc and binutils have always left me feeling uneasy. Each one has so many dependencies on the others, not to mention kernel dependencies. Also, all of the information you need to customize for a particular platform is scattered among so many different config files, not to mention #ifdefs in the code.

He continued with findings from his own research. Glibc may not be an exciting, cool, immediately noticeable component of the Syllable OS, but it's still crucially important -- this kind of foundation work is a great step forward.

3. 3D engines

Brent P Newhall asked the list:

Has anyone ported any 3D game engines to Syllable? I don't mean things like Dan O'Neill's Quake 2 port; I mean actual 3D engines that could be used to create, oh say, a native Syllable 3D game.

A quick response from Jamie Clarkson listed the possibilities:

The Quake 2 engine is probably the best you'll get, it's highly optimized for software rendering. Most useable engines nowadays are completely hardware oriented.

Doing a Total Conversion (or just a mod) for Q2, Q1 or Doom would probably be the best way at the moment.

Software OpenGL is available (Mesa3D), but thats not exactly suitable as a realtime 3D engine backend (although you could probably do some nice 2D games with it).

A port of Descent might be nice, but it's been a long time since I looked at that code so couldn't even guess how hard it would be.

Brent replied that he wasn't looking for a port -- particularly of a FPS -- but a standalone engine. David Gentle suggested OGRE before the thread petered out.

4. Kernel patches

Continuing his work on the kernel, Jake Hamby detailed the fixes and updates he'd just checked in to the source tree:

I've just checked in the kernel improvements I mentioned last week. The main feature is that SSE/SSE2 instructions are now enabled so if you have a Pentium 3 or higher, or Athlon with SSE support, you should now be able to compile programs such as mplayer with SSE support. Here's my note from ChangeLog.Kernel:

• Implement lazy FPU save/restore for faster context switching and save the state of XMM registers on Pentium3 and above for SSE support.
• Exception handlers in fault.c send signals (SIGSEGV, SIGFPE, SIGILL) rather than exiting the process.
• Spelling fixes in comments.
• The function is_signals_pending() is now correctly spelled is_signal_pending().
• The new SeqLock_s type from Linux is used in timer.c for reading the timer registers without disabling interrupts, and the "inc/io_ports.h" header defines constants for the PIC I/O ports, which are used for readability in irq.c, smp.c and timer.c.
• Other minor cleanups include removing useless statistical counters from array.c, adding a warning to kmalloc() when 128K or larger allocations are made, modifying bcache.c to use an area instead of kmalloc() for its hashtable, using g_sSemListSpinLock instead of g_sSchedSpinLock in sema.c, a new do_free_pages() function in mman.c that doesn't call flush_tlb_global() (used in loops by areas.c), inlined asm functions in "inc/intel.h" and atheos/kernel.h, and updated macros from Linux for atheos/isa_io.h. "macros.h" now uses a macro called __likely() on GCC 3.0 and above as a hint to the compiler in kassertw() that the expression asserted is expected to be true.

5. Messaging systems

Jonas Jarvoll pointed out Muscle ('Multi User Server Client Linkage Environment') and considered how it could be used in Syllable:

I found this announcement on Freshmeat:
http://www.lcscanada.com/muscle/index.html

It is a lib to communicate over Internet with Message similiar to Syllable's. As far as I know Syllable (but then again, I dont know so much about Syllable ;)) only supports messages sent locally (within the same computer). It would be great if you can have a similiar message handling also for sending to other computers. Perhaps Muscle could be a startpoint if anyone feels for implement "Internet - messages".

This sparked off an interesting and lively debate. Brent P Newhall tried to find a practical use for this system, while Matt Emson pointed out that Muscle used to compile under AtheOS, many moons ago. Meanwhile, Jonas responded with his thoughts on how the system could be useful:

Some ideas, perhaps all not realistic:
- Remote desktop
- PrinterServer
- Databases
- Games

I think it would be very easy to make client-server programs that still remains Syllable like. For sure you can already now use sockets and "normal" network programming but you will get a more consistent looking apps if you could use the same method for sending over internet as you do for other internal stuff. Another advantage is that you as a developer dont have to learn both how messages and how Internet programming works.

With Internet programming I mean those functions that is neccessary to call for creating a socket and setup the port to communicate over a TCP/IP network.

Matt wasn't convinced by all of these; he agreed that it had some use in databases, but wasn't always appropriate everywhere else. In response to Jonas' last two paragraphs, he also added:

I think you have to be careful here. MUSCLE is a seperate API. It is not something to merge in to Syllable. MUSCLE existed before Syllable, and had an AtheOS port. Forking MUSCLE and merging it with Syllable will yield little benefits in the long term. MUSCLE is in continuous development; it is used in a commercial product from LCS. They use LINUX now, but LCS were early adopters of BeOS and the BeBox, and indeed, early versions of MUSCLE ran on customised BeBox hardware. This is why the whole MUSCLE API seems familiure - it originates from the same source, namely BeOS.

Jonas replied that he didn't suggest merging MUSCLE into Syllable, Tom Marshall chipped in with some thoughts on remote desktops, and Matt claimed it was pointless to 'reinvent the wheel' -- particularly when MUSCLE already existed in various platforms. In response, Daniel Gryniewicz noted that 'Syllable has never been about "Cross Platform"', which prompted the final post in the thread, from Matt:

Jonas mentioned MUSCLE with great enthusiasm. I pointed out that you may as well use MUSCLE as is - it will allow for cross platform messaging. I then mentioned that there were many advantages to using MUSCLE over writing an insular Syllable orientated protocol. After all - this is just another protocol over TCP/IP - lets not get precious about Syllable or draw ambiguous and irrelevant comparisons to GUI toolkits. This is not what I was talking about. MUSCLE is just another protocol for transfering packets of info over TCP. It's HTTP, not SMB or NFS etc. It's more high level than raw sockets, but less high level than, say FTP.

The benefit of cross platform is that there are already multiple MUSCLE servers out there on the Net, live. Write your own Syllable version of the MUSCLE protocol, use the servers for free - get distributed file sharing. Choose to ignore BeShare traffic if desired - you can probably do so with no ill side effects...

6. New LiveCD release

BurningShadow's LiveCDs are useful for trying Syllable without the hassles of partitioning -- they run entirely off CD. This month, BS announced the latest release with various new goodies:

It's time for a new LiveCD, and this one includes some extra drivers, and keymaps. Another package is also released today, and contains the same as the LiveCD, but this one is intended for use on already installed systems. The extra-pack can be found here: http://syllable.burningshadow.dk/download.php?view.17 The LiveCD can be found here: http://syllable.burningshadow.dk/download.php?view.18

Updates:

-Applications:
--AEdit 1.6
--ColdFish 1.1 /w dock-plugin
--Ruslans keyboard-pref.
--StopClock
--Links2

[ 25 keymaps, not listed for brevity ]

-Drivers
--Video
---i855
---GeForceFX
---Riva
---radeon
--Bus
---PCI
--NIC
---forcedeth
---sis900
-Misc
--Extra icons
--Extra dock-plugins
--WarpSpeed Test1 decorator

7. C++ in the kernel

A discussion on programming languages and ideal applications soon led to that never-ending debate, C++ code in the kernel -- it still flares up on the linux-kernel list periodically. William Rose was all in favour of high-level languages for kernel coding, as he posted:

I am increasingly convinced that letting the kernel use certain useful language features such as objects, exceptions and possibly language-based threading constructs would make the kernel a whole lot simpler to write and possibly more reliable. C++ is a good mix of offering these features (especially with a toolkit like ACE or Concurrent C++) and having a large pool of available programmers. With a relatively standard ABI now available (though there are still some incompatibilities) and patches demonstrating the use of C++ in the Linux kernel, I think that there is a lot of potential for C++ to improve the readability and stability of the kernel.

Maybe I am smoking too much of the Stroustrup special, though...

Jake agreed that C++ could enhance readability in some cases, citing Apple's I/O Kit work as an example, but wasn't overly thrilled with the other issues involved:

I'm very skeptical that adding the runtime support for things like exceptions would be useful for Syllable at this point. Exceptions in particular introduce a whole new set of potential code paths through the kernel that are not explicitly specified like traditional error code handling. I think the majority of the benefits from C++ would come from taking advantage of the stricter type checking and object orientation, not from exceptions, global constructors, or RTTI.

If anyone wants to contribute patches to make the Syllable kernel more C++ friendly, by all means, go for it. But it's not very high on my priority list right now.

Here onwards, William and Jake debated the technical pros and cons of in-kernel C++ code, both putting forward solid arguments.

8. SYL-CON planning

The initial thoughts on SYL-CON, a meetup for Syllable developers and users, were covered in last month's SDN. Michael Saunders raised the issue again, suggesting various ideas and trying to gauge how many people were interested:

A month or so back, there was a thread discussing SYL-CON -- a proposed meetup for developers and users. According to the website's survey, an impressive 44 people have said they'll come; another 80 are in the "maybe" camp. When Will_H and I were first chatting about this, we were thinking of, perhaps, 10 to 20 people -- these results are brilliant! Even if only half the definites turn up, it'll still be more than enough for a great little event IMO.

Anyhoo, if we're heading for February with this, now's a good time to start planning and organising. Various things need considering beforehand, so beneath I've jotted down the current (rough) plans and some extra ideas. The more feedback the better...

1) LOCATION
The initial plan was a London hotel -- specifically Heathrow airport or nearabouts. This should be doable for us UKers and be accessible for those flying from Europe or the USA. Or failing this, we could always crash over at Vanders' place :-)

2) DATES
January might be a bit too soon, so I presume February would be ideal for most. This is difficult to organise; some folks may have to get time off work, and we'd like to have as many core developers as possible. If we agree on a rough "window" in Feb, we can fine-tune the exact date later. Another consideration here is duration: two full days? More? Fewer?

3) TOPICS
As a small-ish event I'd guess we won't have anything formal, but allocating an hour or two here and there for certain subjects could be good. For instance, developer Foo could talk about Bar, answer questions and demonstrate stuff -- having Syllablised laptops would be highly useful here (I'll certainly bring mine). Brainstorming, bugfixing and general banter, etc.

4) SPONSORSHIP
I'm not too au fait with the ins-and-outs of this; nonetheless, it'd be useful. Currently no companies have a financial interest in Syllable's progress so our chances here are slim, but it still may be worth approaching certain people. As the event would be well publicised (OSNews, Slashdot, and I'd try to get a small writeup in LXF) there'd be scope for advertising.

OK, those are just some thoughts off the top of my head. As mentioned earlier, 44 people up for this (and 80 maybes) is fantastic, and SYL-CON could be a great event. If those interested could post their thoughts, suggestions and ideal dates, we can get cracking!

Brent P Newhall replied with info on when he was free, along with suggestions for the event. He also noted that, despite the initial response to the survey, things didn't always turn out so well:

I've been involved in organizing a few events similar to SYL-CON, and in my experiences, many grand plans were proposed, most of which collapsed. I'd prefer that we work out a simple, foolproof plan that will at least get us all together for a day or so. I'd be thrilled to go to a full-scale convention with reserved hotel space and sponsorship, and I hope that will happen, but I think it's most important that we hammer out something simple, which we can extend as much as feasible.

Michael agreed that too much ambition could be a Bad Thing(tm). Meanwhile, several other developers joined in the discussion, offering their preferred dates and locations, and the ball started rolling -- February in or around London seemingly the most popular at this point.

9. AEdit 1.6 released

Jonas Jarvoll announced the stable release of his changes to AEdit, Syllable's default text editor:

After a few weeks of testing I have decided to release 1.6. AEdit is the native texteditor for Syllable and is included in the distribution. The main difference between 1.5 (which is probably what you are using if you have just installed Syllable) and 1.6 is that 1.6 supports multiple documents using tabs. A screenshot of 1.6 can be found at http://www.nocrew.org/software/syllable/aedit-screenshot-1.6.png

A binary package and a source package can be found under http://www.nocrew.org/software/syllable. Be sure to pick the right version.

ChangeLog between Beta 3 and Final
=========================
* Mixed Redo and Undo icon on the toolbar
* Changed so that only the filename is showed in the Tab label (this to avoid silly long tab name)
* Due to the above changed to the tab label I forgot to add an asterix if the buffer has been modifed. This is now fixed.
* You can now pass multiple filenames when starting AEdit and AEdit will open each in a new tab (eg. "aedit test1 test2 teste3") You can actually write "aedit *.cpp" and AEdit will open all your c-source files in the current directory.
* For some strange reason Ctrl+B didnt work. I have changed it to Ctrl+L instead.
* Added support for DragAndDrop of files from the desktop

Edited by Michael Saunders. If you have any other Syllable-related news, just drop me a line.