After an extensive development period, the Syllable project has released Syllable Desktop 0.6.5 with improvements all over. As always there are bug fixes, most notably in USB and the network stack, leading to large reliability and performance improvements. LibUSB and SANE were ported, so there is now USB access from user space and support for scanners. There are new network and video drivers, including a unique S3 DeltaChrome driver that Arno Klenke wrote from scratch. Two new window decorators debut from John Aspras. CD burning ability is now integrated in the form of SimpleBurn and CDRTools. A new network preferences applet from Andrew Kennan was integrated, and also Arno Klenke’s port of OpenBeFS. Many ports were upgraded and the system layout has been heavily reorganised. Files needed for compiling software have been split off in a separate package. This is also the release that harmonises a number of things between Syllable Desktop and Syllable Server. The full change log is here. Installation CDs, the upgrade, and images for emulators are here. Additional software can be found here.
If only it still had the iconset from version 0.5.6…!
Is BFS now an option for installation? AFS is still quite immature and buggy from what I’ve been following on the mailing list over the years.
When did we start calling BFS, “BeFS” by the way? I missed that memo 😉
No. GRUB won’t boot it and the kernel block cache needs work before BFS works reliably.
AFS has it’s bugs but then so does OpenBFS. I’ve had AFS recover from some pretty bad crashes with some big journals to reply, and we haven’t seen the old “empty_delme_dir() bug” in a long time.
Didn’t SkyOS release it’s GRUB modifications that allowed OpenBFS to be booted by GRUB? as SkyFS is derived from OpenBFS
SkyOS uses a modified GRUB 0.92 that includes code to boot BFS or SkyFS partitions. The source can be found somewhere in the news archive on skyos.org
Edited 2008-01-08 12:35 UTC
Yes, we know. We’ve not bothered to merge them into our version of GRUB. It’s pointless at the moment given that the block cache simply isn’t up to the task of running an installation from BFS.
Edited 2008-01-08 12:44
What the heck are you talking about? I added Haiku to my GRUB with Ubuntu and it works fine, and Haiku uses bfs.
Standard GRUB will not boot a BFS partition. I’m looking at my Ubuntu 7.10 installation right now, and there is no bfs_stage1_5 file. e2fs, FAT, JFS, Reiser and XFS, but no BFS.
So whatever you’re doing, you are not using the standard GRUB that comes with Ubuntu.
The version of GRUB that comes with Syllable will also not boot BFS. Hence why I said “GRUB won’t boot it”.
GRUB will boot BeOS by chainloading the partitions own stage 1.5 boot block, IIRC. Its definately been able to boot it – somehow or other – for years, as I’ve done it, frequently.
Well yes, obviously. But then we’d have to write a stage 1.5 boot loader for GRUB to chainload.
Vanders, I’m sure you know this, so just so no one gets the wrong idea here: GRUB doesn’t have to understand B(e)FS to boot BeOS or Haiku. You simply use GRUB’s chainload feature, as described in
http://www.osnews.com/files/syllable-install.html
This way GRUB loads and hands off to BeOS/Haiku’s loader which is embedded in the partition’s own boot record. You can use the command ‘makebootable’, but the BeOS (and future Haiku) installer should already have done that for you. (This is not BeOS’s MBR menu known as ‘bootman’ – two separate things. Bootman, if you choose to install it, loads the partition boot record code put there by ‘makebootable’.)
The only reason for GRUB to have intrinsic knowledge of a certain filesystem is to host GRUBs menu settings and additional components -within- the filesystem of a specific partition, like the one you’ve got Linux or Syllable on. Without this intrinsic knowledge of a certain filesystem, a boot menu can’t fit much more than chainloading in the tiny space of a disk’s Master Boot Record. In my opinion chainloading is cleaner than sort of spilling over into a partition, but people seem to enjoy bloat. ;P The only good reason I can see for doing it might be being able to load different operating systems with multiple presets of boot parameter for each.
Yes. However the discussion originally started with the question of if you could now install Syllable on a BFS filesystem instead of AFS. My point is this: ignoring the Syllable block cache issues, we would require a GRUB that is capable of booting BFS itself as Syllable Desktop has a multiboot kernel and GRUB is a multiboot loader. Chain loading the Haiku BFS bootloader is no use for Syllable, even if we ported it.
If and when we solve the block cache issues, we can simply use the BFS/SkyFS stage1_5 patches written by Robert for use with SkyOS.
You don’t need BFS support to boot a BFS partition. How else would any PC boot BeOS at all? Even the Windows bootmanager can boot BFS partitions. For that to work, the first block of the partition contains the actual boot code (which then contains support for BFS). That code gets written to the partition if you invoke “makebootable” in BeOS. I think the feature of the bootmanager is called “chain loading”. (chainload=1 in the grub config? Just be careful to not make logical partitions “active”.)
Yes, it contains the boot loader for BeOS. This entire discussion is about booting Syllable from a BFS partition. The BeOS/Haiku boot loader that may or may not be present on the partition (if you formatted the partition from Syllable there is certainly no bootloader installed) is no help here.
A lot of people seem confused about what exactly the boot loader is and how it all works. When I say “GRUB can not boot from a BFS partition” I mean exactly that. GRUB can chainload another bootloader that can do it, of course it can, but that’s a totally separate boot loader that you just happen to load with GRUB. GRUB is not booting from the BFS partition at all. It’s loading a totally different bootloader that in this particular instance happens to be system specific.
Syllable uses GRUB as its bootloader. For Syllable to be able to boot from a BFS partition, GRUB must be capable of booting from BFS: it must have a bfs_stage1_5 loader that it can embed into the filesystem.
SkyOS uses GRUB as the bootloader and already has the ability to do this. In fact Robert had to modify BFS slightly so that GRUB could embed the stage1_5 file correctly. When and if Syllable can be installed on a BFS partition we will almost certainly use the same GRUB patches that Robert wrote for SkyOS.
I like the little os. It still has a long way infront but its good to see something different. I’m curently posting from Syllable 0.6.5.
Healthy change log, Kudos to the team for there hard work:)
AFAICS the LivdCD is still at 0.6.4.
– Gilboa
There will be a new LiveCD soon.
Thanks.
– Gilboa
Now if they would just implement good printing support, this would count as thebest free Unix-like for Desktop usage…
Well, you need, I dunno, a word processor for printing to make sense.
Do any of the web-based WPs work in WebKit? What about printing off hard copies of web pages and PDF files? What about the fact that simply having something like the ability to print using OpenType fonts would be a huge PR coup that would instantly make Syllable an interesting platform for people who might want to develop a word processor.
Well CUPS is there and works already, using Guttenprint for most of the printer drivers. Actually integrating “printing” into the rest of the system is a totally different kettle of fish, of course. That’s something I hope to make a start with soon.
Cool. Hopefully you intergrate OpenType support as a system-wide feature like Windoze and Mac OS rather than leaving stuff like that “up to the program” as in Linux (and consequently meaning that just about the only reliable way to use OpenType fonts either for PDF creation or normal printing is to use Heirloom troff…
Syllable relies on Ghostscript to handle the Postscript rasterising, and as far as I am aware Ghostscript can handle OpenType fonts just fine. There should be no reason why you could not install OpenType fonts right now and start using them under Syllable, for both printing and on-screen use (FreeType2 can use OpenType as well).
Of course the trick is to make it easy to do that, and Font handling is one thing that isn’t fully done in Syllable yet.
You’ve obviously never tried to use OpenType fonts in Linux if you’re saying that. Even programs that can use them in display can’t always print them and apps built on libraries that SHOULD allow their use don’t always perform as they should… Not taking away from your project, though, just bringing up something that you should pay attention to during the 0.7 cycle (or whenever you really start work on full printer support)
Any screenshots of the new decorators since the LiveCD isn’t out yet?
I remember back a while ago you guys decided you were going to integrate Orca (REBOL) in as a system/application scripting language. is that still in the works or did it get scrapped (or at least put off far into the future)?
why Syllable and Haiku do not undertake a common kernel development(one, YES one) kernel and build their systems on top of that(common kernel != linux/bsd). They can even adopt a uKernel approach (e.g L4) since all these talented men can work together.One kernel, common drivers, different user space => two OSes.
Mostly because we’re doing different things. The NewOS kernel that the Haiku project chose to use is much closer to the BeOS kernel and it uses a license they prefer so it makes a lot of sense for them to use it. The Syllable kernel is closer to Linux and under the GPL.
Neither Syllable nor Haiku want to go back and re-write our respective kernels.
Do you realize that both Syllable and Haiku (and yourself too because you’re against it without providing explanation) suffer from a massive case of NIH syndrome by not reusing the Linux|BSD kernel?
So I doubt that they would use the same kernel: this goes against their NIH syndrome..
I’m not even going to bother getting into it, but there are plenty of reasons. By your logic, Linux is a NIH kernel because Linus didn’t just use the 386BSD kernel. Whatever.
Why not take a look at the software we do use instead of whining about what we don’t? That wouldn’t make such a good whiny argument though would it?
The whole point of these (and other similar projects) is to try to do things better than the way it is currently done. If everybody simply reused what already existsed and no one tried to see if there was a fundamentaly better way of doing things, we’d never make any progress. What you call NIH syndrome others call Research and Progress.