I appreciate the fact that Syllable didn't work on your PC, but you have to accept the fact that we can't provide drivers for every peice of hardware, instantly. When you're using any peice of software with a version of 0.5.6, you should expect some bugs.
This would be better off in the Syllable forums, but did you enable USB Legacy Support in your BIOS? Syllable will see your USB keyboard as a PS/2 device.
At last count, about 50 with a couple of hundred people trying it at any one point. Syllable is at version 0.5.6a; it's Alpha, it's only intended for developers.
Theres no pleasing some people. On one hand they want every single peice of hardware supported and then when we do add a driver, or PPP support, someone else complains.
In case you missed it, Syllable is in development. Of course we're adding features like PPP at the moment! No, I don't expect people to use Syllable just yet. That's why it's at version 0.5.6a!
BeOS, Zeta nor Syllable use Mach. Neither are they micro kernels, not in any CS sense of the word (Although the only OS I can speak with authority on is Syllable, of course). Syllable is just modular, with the ELF loader in the kernel, so it's easier to manage device drivers. However the driver API in Syllable is similiar to Linux E.g. block & character devices with open(), read(), write(), close() & ioctl() functions. There are differences in the details, but in practice Linux drivers can be ported to Syllable very easily.
The Hurd is a Mach based OS though. Unless Hurd/L4 takes off..as much as anything Hurd related has ever taken off, I suppose.
Re:Do they or do they not have the source legally?
on
Zeta Goes Gold
·
· Score: 1
I don't know about OpenOffice or Firefox (Yet), but I know I've successfully ported Glibc to Syllable. Since we started testing our "new" libc, I've recieved patches and bug fixes from two or three other people.
Just because you're not doing it, it certainly doesn't mean no one else is. Hell, using your own example of GCC: have you looked at the number of posts to the GCC mailing list each and every day? Even if the majority of patches being fed into GCC are "backend changes", how are they any less valid? I don't see anyone patching or porting the Intel compiler, or Microsoft Visual C++.
Multi-threaded code is very difficult to write correctly and debug. It's hardly 'easy'.
I beg to difer. Multi-threaded code is dead easy to write once you understand some basic concepts and provided you don't write code like a demented COBOL hacker.
In Syllable the GUI, the kernel and even some device drivers run multiple threads. It's not complicated.
The biggest problem is that a huge amount of code was pulled into Glibc2 from Glibc which is no longer relevent. Just look at all the dead ports under sysdeps/ There are references the AIX all over the Makefiles that don't need to be there. Someone could, and probably should, clean this up but a) It's a lot of work and the maintainers have better things to do & b) Some live ports rely on some of the things provided by those dead ports. #include <sysdeps/unix/bsd/bsd4/foo.c> isn't too uncommon for example. You'd have to carefully test each port every time you removed something to ensure you didn't break anything.
The actual code, and Makefile system used, is pretty decent and makes porting Glibc fairlt easy.
When you don't use X being able to obtain usable source for drivers is very important. If we all subscribed to your model of software development, we'd all be using Windows because Linus would never have been able to write enough device drivers for Linux to make it usable.
Well lets be fair, in the post I respond to you never mention any OS, Windows or otherwise. I stand corrected on Linux; that does handle HT CPU's specially. I'd be prepared to believe that Windows XP with a service pack may handle HT as a special case.
unless you're a kernel hacker and can prove it, I don't have to take the word of an AC
I won't claim to be un uber-kernel-hacker on the level of Alan Cox, but I do manage Syllable and I do hack on the kernel, although the SMP & ACPI code was written by far more clever hackers than me; namely Kurt Skuen and Arno Klenke.
Of course in true "Post AC, get it wrong" fashion for some reason I kept refering to the ACPI table as "MDT" when in fact it's "MADT".
That makes a little bit of sense for 3D graphics drivers, maybe. It doesn't make the slightest bit of sense for a Gigabit ethernet controller, a SATA controller or even an audio DSP. These sorts of components are being churned out by different manufacturers across the world, and most of them have freely available documentation.
Even more bizare, nVidia contributed Gigabit patches to the forcedeth driver. Yet they not only continue to produce their own closed driver, they still refuse to release specs. It boggles the mind.
I'm looking forward to reading the HOWTO. It should be useful. I wasn't really involved in the discussion on porting Firefox to Syllable but the information from various people on the mailing lists, which in turn came from the various documentation available from the Mozilla guys, was that in order to port FF we would have to port the entire Mozilla codebase, starting at XPCOM and working up. That is obviously not the case; Robert has ported FF directly to SkyOS, so we must have taken a wrong turn at some point. I beleive that Roberts port is actually the first port os Firefox that was not already based on an existing Mozilla port, so maybe the Mozilla documentation was wrong? I don't know.
Anyway, fair play to Robert for completing the port. At this point Syllable has a new version of ABrowse which is based on a much newer KHTML, and once Robert releases his HOWTO I'm sure we'll see some activity in porting FF to Syllable too.
You keep badmouthing Linux and X11, yet you have nothing better to show..
You refuse to look. All the code is there. You can run it. There is plenty to show.
..and refuse to make any concrete statements what your ideas for how to do better are.
Again you refuse to look. All our plans are there. You can read them. There are plenty of ideas and plans.
You just arrogantly assume that you will be able to do better..
Oh the humanity, somebody thinks they can do a better job is suddenly "arrogant"! Woe is me.
..and don't care about the damage your unfounded and unsubstantiated assertions are doing in the meantime.
Thats a very funny assertion. Do you seriously think that Syllable is current doing "damage" to X.org? Are you expecting Gartner to release a study showing that a minor flamewar on Slashdot has stunted the development of Windows alternatives? Don't be daft.
And then, when you fail to deliver (as you doubtlessly will)..
Ho hum. "Trying it hard. Don't try, because it's hard." You must be a real ambitious sort of go-getter with an attitude like that.
If we fail, I'll be crying into my cornflakes at all these wasted years. No, really.
..you'll just disappear from the scene.
Uh huh. Don't forget our precious little dog, too!
I am objecting to your claims about X11 performance and usability.
I don't make claims about X11 performance and usability, but I do make claims about X[Free86|.org]'s suitability which is a totally different matter entirely.
No, seriously now, and this it my last post because I'm getting bored trying to track exactly what it is that you're argue.
Our stated goal is not "One Toolkit To Rule Them All" at all. As I've already said, if we can standardise 90% of the applications on a single toolkit then we are doing far better than Linux and we'll be in a similiar position to Windows or MacOS X. Of course we want to encourage use of one UI toolkit, but we're not stupid and we know damn well that we have to be pragmatic. That means that some applications will use their own toolkits; such as Mozilla and OO.o Does that mean Syllable will have failed? No, because a desktop with one single toolkit is not our goal. A desktop where the majority of the applications are consitent and interoporate nicely is.
In fact, the primary reason why people don't do what you are doing is because nobody has had a good answer to this dilemma.
Your argument is essentially "Doing something like Syllable is hard. Don't do it, because it's hard." Thankfully we don't all have such a defeatist attitude. We're certainly going to try; we're not going to give up now before we've even tried. Will we succeed? If I could foresee the future I'd be a millionaire, so I can't actually answer that. It's worth a try though, even if we're surrounded by defeatists like you.
..the fact that you have voiced no plan other than "we'll see when we get there" is unconvincing.
Wether you're personally convinced or not is of no consequence to be totally frank.
You've bounced all over the place during this argument and I still don't understand exactly what your objection to Syllable is. Do you really know what it is? Don't bother to answer that by the way, because I'm actually not that interested. As far as I can see your arguments are based on looking at the screenshots and skiming the Wiki and mailing list archives, at which point you've decided you're an expert on the design and goals of Syllable and proceed to lecture me on how silly we're being and what fools we are for not writing an exciting Bleeding Edge Operating System (Acronym not intentional) based on what is your idea of a good idea. You've focused on the lack of X as though that is the only thing seperating Syllable and Linux (It's not), you've totally missed the point that it is the entire package that is Desktop Linux that we who are working on Syllable see as the problem and then you've ended up telling us that we'll fail because...well, just because you think we will.
Syllable ultimately delivers looks and works just like another KDE theme.
Ding ding ding, we have the looser! How do you know that Syllable "works just like another KDE theme"? Have you actually tried it? Do you know what our plans our for Syllable, and do you realise the it is incomplete (Hence the version number)? Doesn't seem like, and what a surprise.
I thought critizising based on screenshots was an OSNews speciality.
The only difference users are sure to notice is that they can't run Mozilla and OpenOffice, and that's not a point in Syllable's favor.
The only difference between Syllable and E.g. KDE? No. Not that you'd know, of course. Gee, while we're at it an OS currently at version 0.5.4 doesn't run Mozilla and OpenOffice.org and $LARGE_APPLICATION so it must be crap and doomed to failure; never mind that these applications are going to be ported in the future once the rest of the OS is in better shape, no, they must work now or the world is coming to an end.
But you do very much care how it's done, and that's the problem.
You have totally lost me for the second time in this discussion.
Ah but I didn't say concepts, I said mindset. There is a certain psycological baggage asociated with UNIX and Linux and that is something we don't want:)
Largly abandoned UNIX concepts? Under the hood, MacOS X is still very much a Unix. POSIX compatible, similar commandline/shell, user seperation, etc. While OS X doesn't use X, it uses Display PDF, which is also a client/server architecture... like X.
Which surprise surprise, so is Syllable. POSIX, GNU toolchain and userland, Glibc. While Syllable doesn't use X, it uses libsyllable, which is also a client/server architecture... like X.
A number of them were far more advanced than anything you are even attempting.
I never claimed they wern't! Like I've said already, you seem to be looking for some super-advanced research project and that isn't what Syllable is. It's a desktop Operating System.
I don't see X using many of these super-advanced designs of the 70's and 80's either, so what exactly is your argument other than "I like X"? Why don't you stop arguing that we're not doing it right and tell me what you actually think is the "right" way to do it? At the moment I see no constructive criticism, just a lot of silly rhetoric and name calling.
I don't see what that has got anything to do with what I said.
Right, whatever. You said that by using C++ and the design of the client library that we're making some huge mistake, and we should be used $SOME_OTHER_DESIGN instead. You're entitled to your opinion, and hell you might even be right, but my point is that we're set on the course of completing libsyllable and until that happens, we have no intentions of writing another client library in $SOME_OTHER_LANGUAGE.
XRender was already very usable on RedHat 7.2, on which I installed GNOME 2. Antialiased fonts worked perfectly.
Fair enough, I must have missed it. I certainly didn't see any compositing or RENDER accelerated alpha blending going on in KDE 2 or KDE 3 but maybe I just havn't tweaked my XF86Config just right and sacraficed the goat the proper way to get it to work. I don't know. Either way, clearly I'm wrong.
MacOS X does not work on the desktop?
Funny you should mention MacOS X really, don't you think? There is another OS which doesn't use X and largly abandons other UNIX concepts in favour of a more integrated, desktop oriented approach. You don't see much of UNIX poking through into the desktop on MacOS X. Exactly the sort of thing we're trying to achieve with Syllable, funnily enough.
Of course, the shell, terminal subsystems, and other environments are baggage from the point of view building just a high-quality purely client OS, and, of course, users pay a price for that.
I'm not talking about that, I'm talking specifically about X[free86|.org] It has baggage we don't want, including but not limited to the total lack of a standard toolkit.
Syllable is stuck in the UNIX mindset, starting with its choice of runtime, object model, and toolkit design.
I fail to see how any of those things are "the UNIX mindset" They're a more "traditional" mindset; you seem to be looking for some uber Operating System built with bleeding edge langauges and technologies. You're looking for a research project, not a useable day to day Operating System.
I went to the Syllable lists and project sites and looked around, and it seems pretty clear: you guys just haven't done your homework.
On what, exactly? What is it that you think we're trying to achieve? We're certainly not trying to advance the state of Operating System design by twnety years in a single leap, as you seem to believe.
Think what you like about X11. Think the sun shines out of its XDCMP port? Fine with me, you're welcome too it. I know that Linux as a desktop Operating System sucks, badly, and it isn't getting better. X is just one small reason for it, and X is also the foundation of some other problems. If you think that we're doing Syllable simply because, as you put it "X11 sucks" then you've missed the point: the entire package sucks.
It can be done NOW, and that's all that matters. Time does not go backwards.
That does not mean that we should throw away what we already have and start again. libsyllable is just a client library; there is no reason why you can not create wrappers for other languages or even write an entirely new client library in any language you choose. As long as your client library can speak to the appserver there is no problem.
XRender existed 6 months ago. It existed a year ago. It existed 2 years ago. I forgot how old it is but it's definitely more than 2 years old. Even the ancient RedHat 7.2 had it.
When did toolkits like Qt and GTK+ support RENDER? What drivers include RENDER extensions? RENDER might have been in X 2 years ago but it's only been fully usable in the last 6, and there is a hell of a lot of "legacy" code that doesn't use it.
So can you explain how X can run so well on embedded systems? Or computers from the 80s, which are much less powerful than computers today?
They don't use X[Free86|.org] with all those extensions, that's how. I guess I'll rephrash it to make my position clearer: X[Free86|.org] are too heavy weight. Other X solutions are unsuitable as they are either embedded clients or do not support the technologies and extensions that make modern X[Free86|.org] useful.
I also fail to see what Windows applications have to do with X. Of course people will create custom controls; thats not the issue. Even those custom controls will be based on underlying standard controls 99% of the time on Windows. They'll interoperate properly with everything else. At least on a system with a standard toolkit at least 90% of your applications will look and act the same. On Linux it's 50/50, with large applications like Firefox and OO.o throwing their toolkits into the equation as well.
A standard toolkit creates standards. I've never claimed a standard toolkit will eradicate all instances of custom controls.
So you're completely ignoring any technical merit in today's technology. That's an emotional argument. It just makes you look like a zealot.
Well gee, I've spent the last two and a bit years of my life doing one of the most difficult jobs I've ever had to do because I believe strongly in something. Of course I'm a zealot!
Yes, I am ignoring any technical merit in todays technology because it comes with an entire metric tonne of bad technology as well, and you can't seperate the good from the bad. The UNIX mindset does not work on the desktop and the sooner people realise this the sooner Open Source can actually begin to work for users on the desktop. Users want a fast, responsive, integrated system that just works. Linux and other OSS solutions do not give them that. I'm sorry that you can't understand the reasons or our design choices.
I note that you completely fail to actually argue any of my points, some of which are my opinion by the way. I do believe X[Free86|.org] is too heavyweight. X does not have a standard toolkit (Oh sorry, there's Athena. Wow.) Its rendering model is horribly outdated (Unless you use RENDER, but RENDER is an extension in X[Free86|.org] not core X).
Qt and MFC have that market more than covered (and so to Gtkmm and wxWindows and FLTK and other libraries). The question is: what's going to succeed them and why?
I dont know, but that wasn't your argument. You said that the "entire industry" was moving away from GUI toolkits like Qt and MFC, but that is not true. Just because something might be replaced in the future does not mean everything right now is out of date.
There are plenty of examples of APIs that are designed like yours, in which widgets and properties etc. are all exposed through type-safe C++ APIs. By the time the Syllable APIs reach the maturity and completeness of other C++ GUI libraries, we have to expect them to be just as big and complex as those other APIs
Yes, like the BeOS API which Syllable is modelled heavily on. That sure was a bloater wasn't it? Weighs in at a similiar size to libsyllable and the appserver.
What C++ API's are you thinking of? Toolkits such as MFC and Qt rely on a different design than libsyllable, and MFC has it's own special reasons for being bloated.
As I've pointed out, Syllable is a client-server architecture.
Not as far as the API samples are concerned. What you do under the covers doesn't matter.
Now you've lost me. Why would anyone in their right minds expose the underlying client-server design through the API? If it doesn't matter what you do "under the covers", what is your argument here?
When a system that is as widely used as X11 "just begins" to do something, it instantly surpasses something like Syllable in the absolute number of applications taking advantage of a feature.
So? That isn't my argument either. I said that Syllable is far from outdated; it's been doing things for some time which "better" systems like X have only just started to do. Relative userbases are totally irelevent.
It is you who is dismissing established, functional, flexible technology and trying to replace it with an unproven, new system.
Damn straight. Ones man "functional, flexible technology" is another mans ball of twine. We have good reasons for not using X; the fact that it is heavy weight, that is simply does not have a standard toolkit, that it's rendering model is outdated (Sure, you can do compositing now with RENDER, but not six months ago, or last year, or in 1998 when Kurt wrote the appserver), and psycologically it is very much tied to the old Unix mindset. We don't want that Unix mindset and we don't want X.
Our "elevator story" (I missed Corp. Speak 101 so I'm not sure what this is) is simple; We're not UNIX, we've abandoned the UNIX mindset that a lot of people dislike and we want to give you a decent Open Source desktop Operating System that anyone can use. In other words, not Linux.
Slashdot Mirror
I appreciate the fact that Syllable didn't work on your PC, but you have to accept the fact that we can't provide drivers for every peice of hardware, instantly. When you're using any peice of software with a version of 0.5.6, you should expect some bugs.
This would be better off in the Syllable forums, but did you enable USB Legacy Support in your BIOS? Syllable will see your USB keyboard as a PS/2 device.
At last count, about 50 with a couple of hundred people trying it at any one point. Syllable is at version 0.5.6a; it's Alpha, it's only intended for developers.
Theres no pleasing some people. On one hand they want every single peice of hardware supported and then when we do add a driver, or PPP support, someone else complains.
In case you missed it, Syllable is in development. Of course we're adding features like PPP at the moment! No, I don't expect people to use Syllable just yet. That's why it's at version 0.5.6a!
And what non-linux, non-BSD OSes are around now?
You should give Syllable a look.
BeOS, Zeta nor Syllable use Mach. Neither are they micro kernels, not in any CS sense of the word (Although the only OS I can speak with authority on is Syllable, of course). Syllable is just modular, with the ELF loader in the kernel, so it's easier to manage device drivers. However the driver API in Syllable is similiar to Linux E.g. block & character devices with open(), read(), write(), close() & ioctl() functions. There are differences in the details, but in practice Linux drivers can be ported to Syllable very easily.
The Hurd is a Mach based OS though. Unless Hurd/L4 takes off..as much as anything Hurd related has ever taken off, I suppose.
I don't know about OpenOffice or Firefox (Yet), but I know I've successfully ported Glibc to Syllable. Since we started testing our "new" libc, I've recieved patches and bug fixes from two or three other people.
Just because you're not doing it, it certainly doesn't mean no one else is. Hell, using your own example of GCC: have you looked at the number of posts to the GCC mailing list each and every day? Even if the majority of patches being fed into GCC are "backend changes", how are they any less valid? I don't see anyone patching or porting the Intel compiler, or Microsoft Visual C++.
Multi-threaded code is very difficult to write correctly and debug. It's hardly 'easy'.
I beg to difer. Multi-threaded code is dead easy to write once you understand some basic concepts and provided you don't write code like a demented COBOL hacker.
In Syllable the GUI, the kernel and even some device drivers run multiple threads. It's not complicated.
The biggest problem is that a huge amount of code was pulled into Glibc2 from Glibc which is no longer relevent. Just look at all the dead ports under sysdeps/ There are references the AIX all over the Makefiles that don't need to be there. Someone could, and probably should, clean this up but a) It's a lot of work and the maintainers have better things to do & b) Some live ports rely on some of the things provided by those dead ports. #include <sysdeps/unix/bsd/bsd4/foo.c> isn't too uncommon for example. You'd have to carefully test each port every time you removed something to ensure you didn't break anything.
The actual code, and Makefile system used, is pretty decent and makes porting Glibc fairlt easy.
When you don't use X being able to obtain usable source for drivers is very important. If we all subscribed to your model of software development, we'd all be using Windows because Linus would never have been able to write enough device drivers for Linux to make it usable.
Well lets be fair, in the post I respond to you never mention any OS, Windows or otherwise. I stand corrected on Linux; that does handle HT CPU's specially. I'd be prepared to believe that Windows XP with a service pack may handle HT as a special case.
unless you're a kernel hacker and can prove it, I don't have to take the word of an AC
I won't claim to be un uber-kernel-hacker on the level of Alan Cox, but I do manage Syllable and I do hack on the kernel, although the SMP & ACPI code was written by far more clever hackers than me; namely Kurt Skuen and Arno Klenke.
Of course in true "Post AC, get it wrong" fashion for some reason I kept refering to the ACPI table as "MDT" when in fact it's "MADT".
Call it a draw?
That makes a little bit of sense for 3D graphics drivers, maybe. It doesn't make the slightest bit of sense for a Gigabit ethernet controller, a SATA controller or even an audio DSP. These sorts of components are being churned out by different manufacturers across the world, and most of them have freely available documentation.
Even more bizare, nVidia contributed Gigabit patches to the forcedeth driver. Yet they not only continue to produce their own closed driver, they still refuse to release specs. It boggles the mind.
I'm looking forward to reading the HOWTO. It should be useful. I wasn't really involved in the discussion on porting Firefox to Syllable but the information from various people on the mailing lists, which in turn came from the various documentation available from the Mozilla guys, was that in order to port FF we would have to port the entire Mozilla codebase, starting at XPCOM and working up. That is obviously not the case; Robert has ported FF directly to SkyOS, so we must have taken a wrong turn at some point. I beleive that Roberts port is actually the first port os Firefox that was not already based on an existing Mozilla port, so maybe the Mozilla documentation was wrong? I don't know.
Anyway, fair play to Robert for completing the port. At this point Syllable has a new version of ABrowse which is based on a much newer KHTML, and once Robert releases his HOWTO I'm sure we'll see some activity in porting FF to Syllable too.
You keep badmouthing Linux and X11, yet you have nothing better to show..
..and refuse to make any concrete statements what your ideas for how to do better are.
..and don't care about the damage your unfounded and unsubstantiated assertions are doing in the meantime.
..you'll just disappear from the scene.
You refuse to look. All the code is there. You can run it. There is plenty to show.
Again you refuse to look. All our plans are there. You can read them. There are plenty of ideas and plans.
You just arrogantly assume that you will be able to do better..
Oh the humanity, somebody thinks they can do a better job is suddenly "arrogant"! Woe is me.
Thats a very funny assertion. Do you seriously think that Syllable is current doing "damage" to X.org? Are you expecting Gartner to release a study showing that a minor flamewar on Slashdot has stunted the development of Windows alternatives? Don't be daft.
And then, when you fail to deliver (as you doubtlessly will)..
Ho hum. "Trying it hard. Don't try, because it's hard." You must be a real ambitious sort of go-getter with an attitude like that.
If we fail, I'll be crying into my cornflakes at all these wasted years. No, really.
Uh huh. Don't forget our precious little dog, too!
I am objecting to your claims about X11 performance and usability.
I don't make claims about X11 performance and usability, but I do make claims about X[Free86|.org]'s suitability which is a totally different matter entirely.
No, seriously now, and this it my last post because I'm getting bored trying to track exactly what it is that you're argue.
..the fact that you have voiced no plan other than "we'll see when we get there" is unconvincing.
Our stated goal is not "One Toolkit To Rule Them All" at all. As I've already said, if we can standardise 90% of the applications on a single toolkit then we are doing far better than Linux and we'll be in a similiar position to Windows or MacOS X. Of course we want to encourage use of one UI toolkit, but we're not stupid and we know damn well that we have to be pragmatic. That means that some applications will use their own toolkits; such as Mozilla and OO.o Does that mean Syllable will have failed? No, because a desktop with one single toolkit is not our goal. A desktop where the majority of the applications are consitent and interoporate nicely is.
In fact, the primary reason why people don't do what you are doing is because nobody has had a good answer to this dilemma.
Your argument is essentially "Doing something like Syllable is hard. Don't do it, because it's hard." Thankfully we don't all have such a defeatist attitude. We're certainly going to try; we're not going to give up now before we've even tried. Will we succeed? If I could foresee the future I'd be a millionaire, so I can't actually answer that. It's worth a try though, even if we're surrounded by defeatists like you.
Wether you're personally convinced or not is of no consequence to be totally frank.
You've bounced all over the place during this argument and I still don't understand exactly what your objection to Syllable is. Do you really know what it is? Don't bother to answer that by the way, because I'm actually not that interested. As far as I can see your arguments are based on looking at the screenshots and skiming the Wiki and mailing list archives, at which point you've decided you're an expert on the design and goals of Syllable and proceed to lecture me on how silly we're being and what fools we are for not writing an exciting Bleeding Edge Operating System (Acronym not intentional) based on what is your idea of a good idea. You've focused on the lack of X as though that is the only thing seperating Syllable and Linux (It's not), you've totally missed the point that it is the entire package that is Desktop Linux that we who are working on Syllable see as the problem and then you've ended up telling us that we'll fail because...well, just because you think we will.
If you had a point I missed it long, long ago.
Syllable ultimately delivers looks and works just like another KDE theme.
Ding ding ding, we have the looser! How do you know that Syllable "works just like another KDE theme"? Have you actually tried it? Do you know what our plans our for Syllable, and do you realise the it is incomplete (Hence the version number)? Doesn't seem like, and what a surprise.
I thought critizising based on screenshots was an OSNews speciality.
The only difference users are sure to notice is that they can't run Mozilla and OpenOffice, and that's not a point in Syllable's favor.
The only difference between Syllable and E.g. KDE? No. Not that you'd know, of course. Gee, while we're at it an OS currently at version 0.5.4 doesn't run Mozilla and OpenOffice.org and $LARGE_APPLICATION so it must be crap and doomed to failure; never mind that these applications are going to be ported in the future once the rest of the OS is in better shape, no, they must work now or the world is coming to an end.
But you do very much care how it's done, and that's the problem.
You have totally lost me for the second time in this discussion.
Ah but I didn't say concepts, I said mindset. There is a certain psycological baggage asociated with UNIX and Linux and that is something we don't want :)
Largly abandoned UNIX concepts? Under the hood, MacOS X is still very much a Unix. POSIX compatible, similar commandline/shell, user seperation, etc. While OS X doesn't use X, it uses Display PDF, which is also a client/server architecture... like X.
Which surprise surprise, so is Syllable. POSIX, GNU toolchain and userland, Glibc. While Syllable doesn't use X, it uses libsyllable, which is also a client/server architecture... like X.
So where were we?
A number of them were far more advanced than anything you are even attempting.
I never claimed they wern't! Like I've said already, you seem to be looking for some super-advanced research project and that isn't what Syllable is. It's a desktop Operating System.
I don't see X using many of these super-advanced designs of the 70's and 80's either, so what exactly is your argument other than "I like X"? Why don't you stop arguing that we're not doing it right and tell me what you actually think is the "right" way to do it? At the moment I see no constructive criticism, just a lot of silly rhetoric and name calling.
I don't see what that has got anything to do with what I said.
Right, whatever. You said that by using C++ and the design of the client library that we're making some huge mistake, and we should be used $SOME_OTHER_DESIGN instead. You're entitled to your opinion, and hell you might even be right, but my point is that we're set on the course of completing libsyllable and until that happens, we have no intentions of writing another client library in $SOME_OTHER_LANGUAGE.
XRender was already very usable on RedHat 7.2, on which I installed GNOME 2. Antialiased fonts worked perfectly.
Fair enough, I must have missed it. I certainly didn't see any compositing or RENDER accelerated alpha blending going on in KDE 2 or KDE 3 but maybe I just havn't tweaked my XF86Config just right and sacraficed the goat the proper way to get it to work. I don't know. Either way, clearly I'm wrong.
MacOS X does not work on the desktop?
Funny you should mention MacOS X really, don't you think? There is another OS which doesn't use X and largly abandons other UNIX concepts in favour of a more integrated, desktop oriented approach. You don't see much of UNIX poking through into the desktop on MacOS X. Exactly the sort of thing we're trying to achieve with Syllable, funnily enough.
Of course, the shell, terminal subsystems, and other environments are baggage from the point of view building just a high-quality purely client OS, and, of course, users pay a price for that.
I'm not talking about that, I'm talking specifically about X[free86|.org] It has baggage we don't want, including but not limited to the total lack of a standard toolkit.
Syllable is stuck in the UNIX mindset, starting with its choice of runtime, object model, and toolkit design.
I fail to see how any of those things are "the UNIX mindset" They're a more "traditional" mindset; you seem to be looking for some uber Operating System built with bleeding edge langauges and technologies. You're looking for a research project, not a useable day to day Operating System.
I went to the Syllable lists and project sites and looked around, and it seems pretty clear: you guys just haven't done your homework.
On what, exactly? What is it that you think we're trying to achieve? We're certainly not trying to advance the state of Operating System design by twnety years in a single leap, as you seem to believe.
Think what you like about X11. Think the sun shines out of its XDCMP port? Fine with me, you're welcome too it. I know that Linux as a desktop Operating System sucks, badly, and it isn't getting better. X is just one small reason for it, and X is also the foundation of some other problems. If you think that we're doing Syllable simply because, as you put it "X11 sucks" then you've missed the point: the entire package sucks.
You'll want to wait a couple of days and then check our website. There will be a new LiveCD released in a couple of days that can download and try.
It can be done NOW, and that's all that matters. Time does not go backwards.
That does not mean that we should throw away what we already have and start again. libsyllable is just a client library; there is no reason why you can not create wrappers for other languages or even write an entirely new client library in any language you choose. As long as your client library can speak to the appserver there is no problem.
XRender existed 6 months ago. It existed a year ago. It existed 2 years ago. I forgot how old it is but it's definitely more than 2 years old. Even the ancient RedHat 7.2 had it.
When did toolkits like Qt and GTK+ support RENDER? What drivers include RENDER extensions? RENDER might have been in X 2 years ago but it's only been fully usable in the last 6, and there is a hell of a lot of "legacy" code that doesn't use it.
So can you explain how X can run so well on embedded systems? Or computers from the 80s, which are much less powerful than computers today?
They don't use X[Free86|.org] with all those extensions, that's how. I guess I'll rephrash it to make my position clearer: X[Free86|.org] are too heavy weight. Other X solutions are unsuitable as they are either embedded clients or do not support the technologies and extensions that make modern X[Free86|.org] useful.
I also fail to see what Windows applications have to do with X. Of course people will create custom controls; thats not the issue. Even those custom controls will be based on underlying standard controls 99% of the time on Windows. They'll interoperate properly with everything else. At least on a system with a standard toolkit at least 90% of your applications will look and act the same. On Linux it's 50/50, with large applications like Firefox and OO.o throwing their toolkits into the equation as well.
A standard toolkit creates standards. I've never claimed a standard toolkit will eradicate all instances of custom controls.
So you're completely ignoring any technical merit in today's technology. That's an emotional argument. It just makes you look like a zealot.
Well gee, I've spent the last two and a bit years of my life doing one of the most difficult jobs I've ever had to do because I believe strongly in something. Of course I'm a zealot!
Yes, I am ignoring any technical merit in todays technology because it comes with an entire metric tonne of bad technology as well, and you can't seperate the good from the bad. The UNIX mindset does not work on the desktop and the sooner people realise this the sooner Open Source can actually begin to work for users on the desktop. Users want a fast, responsive, integrated system that just works. Linux and other OSS solutions do not give them that. I'm sorry that you can't understand the reasons or our design choices.
I note that you completely fail to actually argue any of my points, some of which are my opinion by the way. I do believe X[Free86|.org] is too heavyweight. X does not have a standard toolkit (Oh sorry, there's Athena. Wow.) Its rendering model is horribly outdated (Unless you use RENDER, but RENDER is an extension in X[Free86|.org] not core X).
Where are the factual inacuracies there?
What are you talking about? All of the sourcecode is in CVS and licensed under OSI approved licenses, with most of the code under the GPL and LGPL.
Where did you ever get the idea that Syllable prevented free access to the source code?
Qt and MFC have that market more than covered (and so to Gtkmm and wxWindows and FLTK and other libraries). The question is: what's going to succeed them and why?
I dont know, but that wasn't your argument. You said that the "entire industry" was moving away from GUI toolkits like Qt and MFC, but that is not true. Just because something might be replaced in the future does not mean everything right now is out of date.
There are plenty of examples of APIs that are designed like yours, in which widgets and properties etc. are all exposed through type-safe C++ APIs. By the time the Syllable APIs reach the maturity and completeness of other C++ GUI libraries, we have to expect them to be just as big and complex as those other APIs
Yes, like the BeOS API which Syllable is modelled heavily on. That sure was a bloater wasn't it? Weighs in at a similiar size to libsyllable and the appserver.
What C++ API's are you thinking of? Toolkits such as MFC and Qt rely on a different design than libsyllable, and MFC has it's own special reasons for being bloated.
As I've pointed out, Syllable is a client-server architecture.
Not as far as the API samples are concerned. What you do under the covers doesn't matter.
Now you've lost me. Why would anyone in their right minds expose the underlying client-server design through the API? If it doesn't matter what you do "under the covers", what is your argument here?
When a system that is as widely used as X11 "just begins" to do something, it instantly surpasses something like Syllable in the absolute number of applications taking advantage of a feature.
So? That isn't my argument either. I said that Syllable is far from outdated; it's been doing things for some time which "better" systems like X have only just started to do. Relative userbases are totally irelevent.
It is you who is dismissing established, functional, flexible technology and trying to replace it with an unproven, new system.
Damn straight. Ones man "functional, flexible technology" is another mans ball of twine. We have good reasons for not using X; the fact that it is heavy weight, that is simply does not have a standard toolkit, that it's rendering model is outdated (Sure, you can do compositing now with RENDER, but not six months ago, or last year, or in 1998 when Kurt wrote the appserver), and psycologically it is very much tied to the old Unix mindset. We don't want that Unix mindset and we don't want X.
Our "elevator story" (I missed Corp. Speak 101 so I'm not sure what this is) is simple; We're not UNIX, we've abandoned the UNIX mindset that a lot of people dislike and we want to give you a decent Open Source desktop Operating System that anyone can use. In other words, not Linux.