Yes and also chang the meaning of the G from 'GIMP' to 'GNU' or something else (Gawd-why-not-do-it-with-a-real-object-oriented-la nguage comes to mind:)
That's because selecting it from a drop-down-menu is comparatively intuitive, all other restrictions of Windows notwithstanding.:)
You know, I think I could enable subpixel rendering *faster* on Linux. On Windows, I would need to *find* the menu where windows hides this option. If you've experienced XP you'll know that this might not be as easy as it sounds. I'm sure I'll be pestered along the way by so called warnings about "damage" to my computer if I enter such and such a directory:-)
And once the XftConfig langugage is replaced by a more structured XML DTD (soon) it will be much easier to concoct a GUI which would supposedly make activating/deactiving these features easier.
This might explain why client-side rendering was chosen. There are pros and cons but the pros seem to outweight the cons by far.
The biggest advantage of this scheme by far is that you don't have to have any magic support for antialiased fonts in your toolkits
This doesn't seem to be a problem since most populair toolkits already support the Render extension. Remember, RENDER is a completely new rendering system for X, not just anti-aliasing.
...even Athena widgets...
If there was great demand for this it would already have happenend don't you think? Changing the Xaw toolkit to support RENDER would not be too hard I think.
They are using AlsaPlayer (shameless plug:) for doing sound output and scratching. I'm currently working on a software only scratchin system, much like TerminatorX.
Incidentally, I just heard a rumour that FinalScratch is indeed using some parts of AlsaPlayer, the plugin system. Wonder if that's true.
That Evil-la you are talking about was a piece of crap! It had a tied-in $20 month subscription, was dialup only, and BeIA (the BeOS part) was so buggy it was practically unusable. Only a couple dozen or so were ever sold.
Because there is only one captain on the ship, Apple. Good luck fixing it in the Linux world. The only way it might have a chance of working IMHO is if such a proposal gets included the Linux Standard Base. Here's a bold idea, why not copy the way Apple does it??? No need to reinvent the wheel...
ALSA = lowlevel soundcard drivers
JACK = highlevel audio (PCM) API
So JACK is using ALSA to output audio. The nice thing about JACK is that it's the first serious attempt in the Linux (Unix) world to get a professional audio API in the hands of developers. SGI's dmSDK was promising but that project seem to have stalled, i.e. no open development going on (no CVS). JACK also replaces arts and esd when it comes to multiplexing audio output. The only problem is that developers may find they have to redesign their whole audio application in order to fit inside the JACK (callback based) framework.
A typical Linux/Unix audio application opens a special file and starts writing the audio data to it. The application will block on the write() (or read() when recording). This works fine for simple things like playing an mp3 or doing some window manager sound. It gets hairy when you try to sync multiple audio applications and achieve low latency at the same time. With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio applications. Every application has the chance to insert its own piece of audio data (or inspect what's already there), all app will always write the exact same amount of samples per callback, which keeps them in perfect sync. You can also do cool things like create your own ports and wire JACK aware apps together. In short, it rocks:-)..and it makes Linux a worthy competitor to OS X's CoreAudio.
Shameless plug:-) AlsaPlayer was the first released JACK app, mainly because of its BeOS heritage (the internals work exactly like the ancient BeOS audio_server, which was callback based).
-adnans
Nathan Scott: extended attributes ??!
on
Kernel 2.5.3 Released
·
· Score: 3, Informative
But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.
but it's hella slow. Not sure what good it is though. Only usefull for "always on top" folders, like the taskbar or some monitoring tool.
-adnans
CrossOver still doesn't work for me
on
KDE 2.2.2
·
· Score: 2
QObject::connect: No such signal NSPluginInstance::destroyed()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: '_ptrpriv')
kio (KProtocolInfo): ERROR: Protocol '' not found
kio (KProtocolInfo): ERROR: Protocol '' not found
Think about more complex scenes where framerate drops below 75fps. A faster GPU will probably fix this and that *will* improve playability. Remember, It's not about the number of frames you get when staring at a wall, it's the framerate you get when you're blasting away on an open plane with 50 enemies surrounding you.
For example, every single GUI element of a BeOS app is at least 1 thread, possibly more...
No, every single BWindow has its own thread. All GUI elements in this window are controlled by the window looper. Of course you can spawn additional threads per window, but it's not as horrible as you sketch:)
Linux was not designed to create and destroy such a large amount of threads so frequently.
It wasn't? Who said this? It sure does rock then for a system that has supposedly slow thread creation. I just wrote a tiny app that spawns 1000 threads in less than half a second. That's should be enough for the things they want to do. I can't imagine anyone creating more than 1000 windows per half a second:-)
What's the point in doing this. If they are wrapping Linux kernel in BeOS like calls defies the purpose of the excercise. BeOS has been known for its superb threading whereas Linux well... Let's just say it's not Linux's strongest side.
Can you elaborate? There is nothing wrong with Linux threading. I had heavily threaded BeOS code which was ported to Linux and it ran just as efficient, if not faster! BeOS is known for its "pervasive multithreading", and there's nothing particularly "superb" about it. In fact, for large applications it pretty much sucks ass since BeOS can't guarantee 100% message delivery. Many big name vendors simply abandoned BeOS apps because of this trouble. Or, they created a global lock which got rid of the "pervasive" part of the threading just so they could predict the behaviour of their app. Imagine having your application running fine on a fast 1GHZ box, while it crashes and burns on a slower box because it looses 1 or 2 important messages! Of course, this would indicate a design flaw, but you can't blame the engineers for getting it wrong the first time. Unfortunately for Be, since they were a new entity it only took a couple of wrong turns to tick off potential customers.
I've heard of people not reading the article linked in a slashdot posting, but you take the cake! At least read the SUMMARY of the article before sounding off!
I was merely answering the question that was asked in the TITLE of this slashdot posting. Did you read that? Ah, thought so! I have no real comments regarding the various initiatives. IMHO the BeOS community as a whole has proven that it doesn't have the muscle (numbers / financial backing) to sustain itself. And the BeOS window of opportunity closed a long time ago. Be knew this, hence their (unsuccessful) focus-shift to IA's.
Nope. As has been stated over and over again, BeOS cannot and will not be relicensed as Open Source software. There is simply too much proprietary, third party, technology embedded in it that it would take a lot of time, and probably a lot of cash, to strip away. It took SGI almost a year, if not longer, to get XFS released as GPL. Okay, the had to reengineer a good deal of the Linux kernel too. Besides, even if Be manages to strip out the proprietary bits you will most likely be left with a shell of code that will not compile, for a significant amount of time (*cough* Mozilla *cough*).
And IMHO, the "coolest" bits of BeOS have already made it into Linux -> 64-bit journalling FS with attributes, XFS! The other cool BeOS buzzword "pervasive-multithreading" didn't turn out to be that cool after all.
You want the X Resize And Rotate extension, short RandR. This extension will probably be in an upcoming release of XFree86. It's already in the kdrive server (mostly for handhelds). It allows the dynamic resize and rotation of the root X Window. You can also change the root depth without restarting.
As for the network transparency, useful as it seems to be to many people, does it need to be tied to the video functions?
Slashdot Mirror
Yes and also chang the meaning of the G from 'GIMP' to 'GNU' or something else (Gawd-why-not-do-it-with-a-real-object-oriented-la nguage comes to mind :)
Maybe this is a silly question..
:-)
Yes it is...
-adnans
That's because selecting it from a drop-down-menu is comparatively intuitive, all other restrictions of Windows notwithstanding. :)
:-)
You know, I think I could enable subpixel rendering *faster* on Linux. On Windows, I would need to *find* the menu where windows hides this option. If you've experienced XP you'll know that this might not be as easy as it sounds. I'm sure I'll be pestered along the way by so called warnings about "damage" to my computer if I enter such and such a directory
And once the XftConfig langugage is replaced by a more structured XML DTD (soon) it will be much easier to concoct a GUI which would supposedly make activating/deactiving these features easier.
-adnans
Ah, how intuitive... how many hours of reading manpages, HOWTOs and FAQs did it take to figure that one out?
It could have taken you one Google search for "xfree86 subpixel rendering" to find this link!
-adnans
This might explain why client-side rendering was chosen. There are pros and cons but the pros seem to outweight the cons by far.
...even Athena widgets...
The biggest advantage of this scheme by far is that you don't have to have any magic support for antialiased fonts in your toolkits
This doesn't seem to be a problem since most populair toolkits already support the Render extension. Remember, RENDER is a completely new rendering system for X, not just anti-aliasing.
If there was great demand for this it would already have happenend don't you think? Changing the Xaw toolkit to support RENDER would not be too hard I think.
-adnans
Does this mean my Be(en)Box is worth some money?
-adnans
If you feel adventurous you can try and duplicate what this guy is doing:
t ml
:) for doing sound output and scratching. I'm currently working on a software only scratchin system, much like TerminatorX.
http://www.cs.ubc.ca/~tbeamish/digitalturntable.h
They are using AlsaPlayer (shameless plug
Incidentally, I just heard a rumour that FinalScratch is indeed using some parts of AlsaPlayer, the plugin system. Wonder if that's true.
-adnans
Anybody remember FinalScratch?
Ironically FinalScratch now runs on Linux
-adnans
That Evil-la you are talking about was a piece of crap! It had a tied-in $20 month subscription, was dialup only, and BeIA (the BeOS part) was so buggy it was practically unusable. Only a couple dozen or so were ever sold.
Hardly a good comparison IMHO.
-adnans
Because there is only one captain on the ship, Apple. Good luck fixing it in the Linux world. The only way it might have a chance of working IMHO is if such a proposal gets included the Linux Standard Base. Here's a bold idea, why not copy the way Apple does it??? No need to reinvent the wheel...
-adnans
ALSA = lowlevel soundcard drivers
:-) ..and it makes Linux a worthy competitor to OS X's CoreAudio.
:-) AlsaPlayer was the first released JACK app, mainly because of its BeOS heritage (the internals work exactly like the ancient BeOS audio_server, which was callback based).
JACK = highlevel audio (PCM) API
So JACK is using ALSA to output audio. The nice thing about JACK is that it's the first serious attempt in the Linux (Unix) world to get a professional audio API in the hands of developers. SGI's dmSDK was promising but that project seem to have stalled, i.e. no open development going on (no CVS). JACK also replaces arts and esd when it comes to multiplexing audio output. The only problem is that developers may find they have to redesign their whole audio application in order to fit inside the JACK (callback based) framework.
A typical Linux/Unix audio application opens a special file and starts writing the audio data to it. The application will block on the write() (or read() when recording). This works fine for simple things like playing an mp3 or doing some window manager sound. It gets hairy when you try to sync multiple audio applications and achieve low latency at the same time. With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio applications. Every application has the chance to insert its own piece of audio data (or inspect what's already there), all app will always write the exact same amount of samples per callback, which keeps them in perfect sync. You can also do cool things like create your own ports and wire JACK aware apps together. In short, it rocks
More on this at the JACK website
Shameless plug
-adnans
But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.
Yes, go to the Gdkxft site and download/install the 1.4 tarball. Then:
$ LD_PRELOAD=libgdkxft.so mozilla
Enjoy a jaggy-less web experience!
-adnans
VOB files can be unencrypted too. I have quite a few DVDs that have unencrytped VOBs on them.
-adnans
but it's hella slow. Not sure what good it is though. Only usefull for "always on top" folders, like the taskbar or some monitoring tool.
-adnans
QObject::connect: No such signal NSPluginInstance::destroyed()
QObject::connect: (sender name: 'unnamed')
QObject::connect: (receiver name: '_ptrpriv')
kio (KProtocolInfo): ERROR: Protocol '' not found
kio (KProtocolInfo): ERROR: Protocol '' not found
when visiting www.apple.com... sigh.... help?!
-adnans
You seem to forget that Sun went off and bought StarOffice and did open source it.
Of course Sun had the resources to do this. Be didn't. In fact if this deal didn't went trough the next step would have been bankruptcy.
-adnans
Think about more complex scenes where framerate drops below 75fps. A faster GPU will probably fix this and that *will* improve playability. Remember, It's not about the number of frames you get when staring at a wall, it's the framerate you get when you're blasting away on an open plane with 50 enemies surrounding you.
-adnans
For example, every single GUI element of a BeOS app is at least 1 thread, possibly more...
:)
:-)
No, every single BWindow has its own thread. All GUI elements in this window are controlled by the window looper. Of course you can spawn additional threads per window, but it's not as horrible as you sketch
Linux was not designed to create and destroy such a large amount of threads so frequently.
It wasn't? Who said this? It sure does rock then for a system that has supposedly slow thread creation. I just wrote a tiny app that spawns 1000 threads in less than half a second. That's should be enough for the things they want to do. I can't imagine anyone creating more than 1000 windows per half a second
How are you going to deal with this problem?
Apparantly this is not a problem at all!
-adnans
What's the point in doing this. If they are wrapping Linux kernel in BeOS like calls defies the purpose of the excercise. BeOS has been known for its superb threading whereas Linux well... Let's just say it's not Linux's strongest side.
Can you elaborate? There is nothing wrong with Linux threading. I had heavily threaded BeOS code which was ported to Linux and it ran just as efficient, if not faster! BeOS is known for its "pervasive multithreading", and there's nothing particularly "superb" about it. In fact, for large applications it pretty much sucks ass since BeOS can't guarantee 100% message delivery. Many big name vendors simply abandoned BeOS apps because of this trouble. Or, they created a global lock which got rid of the "pervasive" part of the threading just so they could predict the behaviour of their app. Imagine having your application running fine on a fast 1GHZ box, while it crashes and burns on a slower box because it looses 1 or 2 important messages! Of course, this would indicate a design flaw, but you can't blame the engineers for getting it wrong the first time. Unfortunately for Be, since they were a new entity it only took a couple of wrong turns to tick off potential customers.
Read more on the art of loosing BMessages here (particularly JBQ's posts).
-adnans
I've heard of people not reading the article linked in a slashdot posting, but you take the cake! At least read the SUMMARY of the article before sounding off!
I was merely answering the question that was asked in the TITLE of this slashdot posting. Did you read that? Ah, thought so! I have no real comments regarding the various initiatives. IMHO the BeOS community as a whole has proven that it doesn't have the muscle (numbers / financial backing) to sustain itself. And the BeOS window of opportunity closed a long time ago. Be knew this, hence their (unsuccessful) focus-shift to IA's.
-adnans
Nope. As has been stated over and over again, BeOS cannot and will not be relicensed as Open Source software. There is simply too much proprietary, third party, technology embedded in it that it would take a lot of time, and probably a lot of cash, to strip away. It took SGI almost a year, if not longer, to get XFS released as GPL. Okay, the had to reengineer a good deal of the Linux kernel too. Besides, even if Be manages to strip out the proprietary bits you will most likely be left with a shell of code that will not compile, for a significant amount of time (*cough* Mozilla *cough*).
And IMHO, the "coolest" bits of BeOS have already made it into Linux -> 64-bit journalling FS with attributes, XFS! The other cool BeOS buzzword "pervasive-multithreading" didn't turn out to be that cool after all.
-adnans (ex-BeOS fool)
You want the X Resize And Rotate extension, short RandR. This extension will probably be in an upcoming release of XFree86. It's already in the kdrive server (mostly for handhelds). It allows the dynamic resize and rotation of the root X Window. You can also change the root depth without restarting.
As for the network transparency, useful as it seems to be to many people, does it need to be tied to the video functions?
It is not tied to video functions.
the car doesn't get suicidal when you're driving!