I don't know about you, but I've found from personal experience that multimedia playback is on average very poor in Linux. I mean there isn't a decent Divx;-) player anywhere.
Oh, you haven't tried MPlayer then. It's an excellent DivX;-) / MPEG / AVI / ASF / etc. player. It plays DivX files flawlessly. The best part is the cool keyboard control.
As for audio I have a SbLive! and I have it correctly configured in every way in both windows and linux. Windows audio playback with the same speakers and extremely similar configurations is just far superior
The Windows audio playback is probably using the advanced futures of the Em10K chipset. Programming info for the DSP is sadly not free, and thus not available to Linux users, hence no advanced sound features. But this isn't Linux's fault.
In linux I get noise and distortion and just crappy sound
Have you tried the ALSA drivers with it? It might give you better quality.
I thought giving the Kernel the ability to preemt other programs was important. If you give programs the ability to preempt the kernel, doesn't that just change the system back to cooperative multi-tasking?
Nope, because the kernel is still always in control. In a cooperative multi-tasking enviroment the userspace programs can choose to hold on to the processor as long as they like (i.e. not cooperate nicely with others). This patch simply allows a lower priority process to be interrupted by a higher priority one even if the low priority one is in the kernel, doing a system call for example. However, this preemption is done by the kernel scheduler.
But won't that make the problem even worse? Unless you have a veeery slow Linux box (486, 16MB RAM) you can probably do a dozen compiles or more in one week:)
And I can pretty much say for 100% that the kernel will not compile with LCC. Plus you must have an as86 compatible assembler to build the more interesting parts. Nevertheless, good luck, and if you do succeed, let us know!:-)
buzzword or actually implemented in the new KDE/Qt?
Alpha blending IMHO increases elegance (not to be confused with usability) of an interface when used properly. Any KDE developer(s) care to explain how and what this actually means? e.g. Render calls, which components use this, etc?
You can't actually *do* anything in it... it's locked into 'spectator mode'. This isn't made clear in the article (you do get to watch all the windows users killing each other though).
Bullshit. You can play just fine. I suggest you read the docs, and maybe TRY it yourself.
I wasn't impressed anyway... it's just counterstrike by another name, except it's stupidly CPU hungry - certainly my Dual Proc 800 + Geforce couldn't handle it without grinding to a halt every few seconds.
Looks like you have configuration problems. My single CPU Atlon 900 + Geforce2MX400 works just fine at 800x600 on TVout.
Who cares! It means that life outside earth's athmosphere is possible (without the aid of technology). If life can survive and thrive on Mars, who knows how many other life forms are out there!
It's, quite frankly, more than a little bit easier for existing FreeBSD developers to write a given driver than it is for them to teach someone what to do. Writing drivers involves intimate familiarity with the system, especially with a system where the kernel API has been in a constant state of flux in the long-running development branch.
OMG, no wonder FreeBSD is having trouble sustaining its engineering pool. What you are basically saying is that newbie driver hackers are not welcome because the existing 'established' developers, no matter how swamped they already are, can do it better and faster?! That's just silly.
Yes, right now it works. But I run a similar config, and XFS-Linux 2.4.7 broke the low-latency 2.4.6-pre2 patches. It took more than a week to get 2.4.7 patches up
So? Remember, you don't *have* to upgrade your kernel everytime a new patch comes out. I have a production machine with 2.4.3-XFS that has already logged over 130 days of uptime and still going strong. I will most likely start test-running 2.4.10-XFS once that comes out and if proven sufficiently stable will switch over.
that's why I stated in my original post that Linux WILL become the ultimate media OS. Its just not there right now.
Good, at least we can agree on that point:-)
[explanation cut]... Most modern OSs go through hoops to make sure that processes that are I/O bound get as many chances as possible to make requests for I/O. Thus, they can wait on the I/O while other threads use the CPU.
While this is true, implementations of multi-threaded X servers (to overcome the theoretical contention problem you describe) have proven that speed gains are only marginal. So in the real world you will have to choose between:
Marginally better throughput accompanied with exponential programming complexity increase (mandatory thread/locking management in your program).
Good throughput but without more complexity forced upon you then necessary (but with the option of using extra threads).
Pick your poison. JBQ makes an excellent point when he states that BeOS forces developers "to handle asynchronous events through threading, such that the core services of the operating system only handle synchronous requests".
Maybe. Setting up a separate connection for each view seems slow though, and might blow chunks if you actually use the networking features of X
The performance and responsiveness of remote X apps is entirely determined by your network speed and latency (on my local LAN remote X window creation is practically instantaneous).
The default Linux kernel's audio latency still blows, and even the guys doing the low-latency patch still use BeOS as a benchmark for low latency
Probably because BeOS made the biggest noise about low latency audio support.
For example, if you want XFS and low latency in the same kernel, its a crap-shot if the two patches are in sync. And with Linus's kernel of the day syndrome, that situation won't get any better.
Actually the people that really want or need this right now, this moment, can get their cake and eat it too. FYI, I have 2.4.10-pre1-xfs + low latency 2.4.9 patches running just fine:) Of course, all of this patching will not be necessary once these go into the main kernel tree, and the will go in. At least great things are happening. Can't say that for BeOS.
What about drawing to multiple views?
What about it? Your PC will never draw to multiple views simultaneously, not even on BeOS (and not even on an SMP box). That's because there's only one blitter engine on the graphics chip.
Of course there can be multiple outstanding draw requests, but X and gtk+ in combination with the GDK_THREAD_ENTER/LEAVE calls take care of that very well. Oh, and you can always open multiple X server connections from a single application. You will get multiple X pipelines (that get serialized in the X server / graphics driver) but at the application level you will have the equavalent of multiple BWindows with their own BLooper. And since everything on a X screen is inside an X Window you can treat all elements as Views.
If GTK has a single global lock, doing GTK+ operations on one window will lock out those doing operations in another window.
You only ask for the lock when you change internal shared data structures or if you want to push a pixmap to the screen. It's the same as in BeOS. Offscreen drawing can be done inside a gdk pixmap, and you don't need to hold the lock to do this. Only when you are ready to blast the pixmap on the screen do you request the lock. That's exactly how things work in BeOS. The locking might take place on another level but in essence it's exactly the same. And not surprisingly, BeOS mutithreaded code runs at the same performance level in Linux/X (at least my applications do:-) See the screenshots on my homepage with 20 audio scopes running perfectly sync to the 3 audio files being played, simultaneously with gobs of CPU cycles to spare:)
Also, many operations don't use the graphics hardware anymore. GNOME's canvas uses LibArt heavily, and as far as I can see, it is 100% software.
The canvas is just an offscreen image. You can have multiple canvas widgets being modified by multiple threads without problems. That is if libArt is reentrant itself (I've never used it). In the end, the canvas images will have to be drawn in the framebuffer and that is done by a single hardware blitter device.
About Win2000 using so many threads. It'd be interesting to know how many of those threads are created by the programmers explicitly, and how many are the result of just calling a function in win32.
No, not just because it is technically cool. Because with Win2K getting more popular, WinXP coming into the home, and dual Duron systems costing chicken scratch, SMP machines will become very popular. Apple's multi-proc machines were of limited usefulness because so little Mac software is multithreaded. Systems that use threading agressively (and yes, it is possible to use it agressively and still correctly) won't have this problem.
The average Linux installation, will benefit greatly by running on an SMP box. And this, out-of-the-box.
I have 102 processes loaded, that's with 6 Konqueror windows, a bunch of deamons, 8 terminal windows and my audio player on screen. If I had multiple processors in my box, they would all be utilized fully...You don't need very fine grained threading for that (remember, processes are just glorified threads, or the other way around, depending on how you look at it)
Sorry to have 2 replies but I was just very surprised when reading the following piece of text from JBQ:
"Big surprises here : there's usually only one mouse, only one keyboard, such that cases where several applications have to respond to input events at the same time are marginal, unusual cases. As for redrawing, all the redrawing events are sent to the graphics chip, which can only deal with one acceleration at a time anyway. "
And that's exactly what I was saying 2 minutes ago.... JBQ rocks:-)
Oh, I remember refuting many (all) of your points against Linux/X11 a couple of weeks/months ago. I will pick legacy, network transparant, X11, with Geforce2, full OpenGL, over BeOS Vesa 2.0 any day, thank you very much. It makes practical and technical sense...
The next part of your arguement basically boils down to "ignore all the technical reasons, Be died so BeOS must have sucked," and "BeOS sucked because it wasn't easy to port to."
If you want to read it that way, sure. I never said BeOS sucked, however it's faaar from being superior. I was into Be probably way before you even heard of them. I have a BeBox to prove it:) I spent countless hours coding neat stuff for BeOS (it wasn't even called BeOS back then). Hell, I ported one of the first MP3 players over to BeOS:-) I know all about its pervasively multithreading enviroment. Back then I was simply amazed at how easy it was to get graphics and sound mixed with threads. But it was always a toy. You could do neat stuff with it, but there were no real advantages over other OSes at the end of the day (with the exception of the journalled FS).
GTK+ 1.2 is hardly thread safe. According to the GTK+ FAQ, there is a global lock on the whole system which negates any advantages of threading
Oh really? I think you need to take some more classes on threading then. Since your videocard is not multi-threaded all drawing events gets serialized at some point. The global GTK+ is ugly, but very effective. And your applications still take advantage of threading, if you code them correctly. Heh, just a couple of days ago I hit a locking bug in my pet project. The whole GUI froze because I acquired a lock twice, yet the music kept playing on. It even jumped to the next song in the playlist. The GUI thread was deadlocked, yet my audio and disk thread continued like there was nothing wrong. Sure, gtk+ global locks negates any advantage of threading, NOT! You use threads to do CPU intensive work while still being able to process other events (like the GUI). You do not use threads to fight for the single 2D pipeline that most PC graphics cards have these days.
As for Qt 3.0, it hasn't been released yet, so it is of no consequence at the moment.
Oh dear, I should wipe my stolen copy quickly then!
The reason I say that GUI developers should be forced to use threads is because, all too often, developers try to use (comfortable) procedural techniques to do GUI programs, which ineherently lend themselves well to a messaging/multi-threading model.
With the risk of not taking into account the technical advantages this has I will say that this model hasn't helped BeOS one bit! The fact that any programmer that wanted to put a BWindow on the screen had to deal with threads and locking has IMHO stiffled application development a great deal. Just look at BeBits.. it's full of "Hello World" style apps. There are very few mature applications available.
Anyway, JBQ makes a good point: it is hard to port non-threaded software to a threaded environment
He also points out that there are fundamental problems with the way BeOS handles inter-thread messaging. These problems will probably not bite the average graphics viewer coder, or the mp3 player program, but they will bite once you start coding moderately complex tools.
Threads are cool, I use them every day. But like you say, they are not the silver bullet. On a sidenote, my heavily multithreaded audio player has been churning through a 3000 entries long playlist for 2 straight days now, rock solid:) Oh, and it uses GTK+ for threading the scope windows. Yes, each scope window has it's own worker thread, just like BeOS. In this case, it is usefull to have multiple threads calculate and draw the scopes in offscreen bitmaps before blitting them to the screen. Bottom line: use threads where they're usefull, don't use them pervasively (perversely:), just because it's technically "cool".
BTW, you should go back to the forum/discussion area I pointed out earlier. There's some more interesting notes from JBQ on the "pervasively multithreading" nature of BeOS (He mentions smoke and mirrors.... ugh:)
XFS supports extended attributes just like BeFS. no wonder, since BeFS is based, at least in part, on ideas originated in XFS. You will need some userland tools to set extended attributes and probably a modified tar if you want to preserve attributes inside archives. The web page on Access Control Lists and Extended Attributes might also prove useful. Now, combined with fam & imon, which provide (i)node monitoring you have everything except indexed searching, all in Open Source (imon is actually a kernel patch that adds node monitoring at the VFS layer)
All OS afectionados love to brag. At least BeOS users can brag and not lie. I've laid out several reasons why (as a Media OS) BeOS beats Linux. If you'd care to refute any of these, be my guest.
Sure, list them. I happen to know a couple of people who are migrating their (BeOS) Media applications straight to Linux. No point in building your software/hardware on a dead/unsupported system. And from my own experience in porting BeOS software to Linux, I can say that Linux provides most everything that is needed and much more (e.g. progress).
BeOS was designed to encourage highly multithreaded programs with fast GUIs.
Sadly, this hasn't panned out too well. It takes quite long time to get threads right. Porting apps from other OSes took considerable effort and willpower. Be talked about the "tractor app" thingy since 1995. To date there hasn't been a single native tractor app for BeOS. So much for the highly multithreads programs with fast GUIs.
...there is the fact that BeOS's API encourages developers to extensively use attributes
And in the process they pretty much lock themselves to BeOS' APIs. And we all know how large the BeOS installed base is:-)
but you don't see applications doing this prevasively, do you?
No, because well, there's no reason to do so, unless there's a broader standard, and clearly there isn't (look for ACL/extended attributes integration in the 2.5.x kernel tree). BeOS was ahead of the pack, but unfortunately for Be and its develoeprs that meant shit..
the lack of any central encouragement precludes large scale integration of media apps.
Again, this hasn't helped Be one bit. Why? Because the Media Kit is so full of bugs, not to mention horribly documented, it is practically impossible for anyone outside of Be to write any Media add-on more complex than an audio codec.
...which is why neither GNOME nor KDE use threads extensively
The only apps that really benefit from threads are media applications and most, if not all of them do use threads. GTK+ 1.2.x is already thread safe. Qt 3.0 is too. But because developers are NOT FORCED to use threads you will most likely only encounter them when they actually make a difference! I do wish Mozilla used separate threads to manage each browser window. Anyway, threads have their place but don't glorify them too much (just watched over 3 hours of perfectly synced DVD, thanks to some clever threading:)
Where? I looked through the entire BeOS board, couldn't find anything related to multithreading. Did searches for both "GUI" and "thread." "Thread" turned up on irrelevant hit, while "GUI" simply turned up some articles about improving the GUI. What posts are you referring to?
"Multithreading sounds cool, but it's an unnecessarily complex beast to master, and the fact that it's asynchronous by nature makes it fairly hard to debug, and creates some behaviors that vary a lot between machines. Plus, people learn and like to write synchronous code. "
and
"The problem with BeOS isn't the fact that the kernel allows for multiple threads. The problem is the fact that developers are forced to use multithreading under BeOS, that they are forced to use the BeOS locking mechanism, and that various bugs and limitations in BeOS make all that even harder than it should already be. Sure, a computationally intensive application might (and probably will) benefit from spawning an extra thread. Sure, a game that needs to send feedback to different output devices might benefit from putting the game engine in a separate thread. But in many cases, it's just overkill. "
Really, what's the point of running the emulation if you lose speed and capabilities?
The point is that you get to run another OS while still having access to your regular OS. I can keep my development enviroment and monitoring tools up and running in Linux, while booting Win2000 in VMware and browse that one webpage that requires a plugin that's not available in Linux (yet). And if you fullscreen Vmware you will NOT notice that you're running inside Vmware since it's feels as fast as the real thing (granted: 1.33GHZ + 512MB DDR:). Oh, and if it ever crashes you just double click that vmware icon and Win2000 is up an running again in 20 seconds:-)
If you need to ask why, it's probably not for you anyway....
....... At its current pace of development, there is no doubt about that. However, that level of development will only compare to what BeOS was in 1998.
Hahaha, and how is that going to help us? Be fans LOVE to point out the "superior" technology in their beloved BeOS (I was once such a person:). However, that's probably one of the reasons BeOS is gone today. Too much arrogance, too little substance!!
Yes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want tYes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want to be free of the shackles of X?o be free of the shackles of X?
Funny, X is still around after all these years, while BeOS is going down the toilet faster than a turd spinning counterclockwise in Australia. Why don't you port or rewrite the 'great' BeOS Interface Kit to X. You can get all features, including one thread per window on X today, no populair toolkit does this however. I know there is closed-source code out there that does exactly this. According to you people are probably begging for this functionality right now...So go on!
BTW, if you read the osnews.com forums you'll see that there are several serious issues with the BeOS pervasively mulit-threaded interface.
Who says no one wanted it? Looking at the feature set, I am confident that had I seen BeOS then, I would have picked it up, along with Linux.
He was talking about OEMs. BeOS was offered free of charge to any OEM who wanted to pre-install it on their new PC. JLG made a big hoopla out of this. The only problem was that no OEM wanted it......
But they all dropped the ball, indicating that other factors were at work. To all our detriment.
Yeah, the biggest factor was that BeOS was never a drop-in replacement for Windows.
Just think: by 1997, we could all have a multimedia capable OS
I had a multimedia capable OS long before that. Oh, and in 1997 BeOS multimedia was in a sad state. The new media-kit hadn't arrived yet, and it didn't run on commodity x86 hardware yet, so you had to buy a ridiculously expensive Mac machine or a second hand BeBox to get it to run.
with a journalling filesystem.
Journalling is nice, journalling was also very immature on BeOS. I remember loosing 2 filesystem because they got full. Go figure:)
-adnans
Re:I can't wait until XFS is standard...
on
2.4.9 Kernel Released
·
· Score: 3, Informative
XFS is great. I have it on 2 production servers (rock solid since installation). However, for my workstation I've recently switched (back) to ReiserFS. I do a lot of large compiles and move huge amounts of code around and that exposes the ONLY weak part in XFS: unlink() time. XFS is doog slow for deleting large directory trees. I sure hope they optimize this, soon..
Other than the long rm times, it's rock solid. The ACL ioctls should be sorted out too soon, so we can have access to extended attributes (I will NOT miss you Be, Inc.)....
BeOS was developed on 66MHz PPCs with 16MB of RAM and it shows. The damn thing runs like hell on mediocre machines, and even faster on faster ones.
It was also far from what it is today, no journalling filesytem, very crude "Media Kit", very little drivers, horrible VM (still does), etc. etc..
I went back to PR2 on my BeBox, since the latest release (R5) is about 50% slower for most things. Of course driver/application support on PPC is even more pathetic than x86 (imagine that) so it really doesn't matter. The once glorious and ultra-hip BeBox is now a SSH terminal box:-)
Yes it even needs it's own HUB since no 100Mbit network card works in it...not that the network kit would benefit from it.
-adnans
Re:Magnifying glasses say it all...
on
KDE 2.2 Tagged
·
· Score: 2
He could move the find button to another position on the toolbar (not squarely beside the magnifying buttons). That should reduce the confusion quite a bit...
-adnans
Re:Magnifying glasses say it all...
on
KDE 2.2 Tagged
·
· Score: 2
And here's a KDE weakness. Right smack next to the 'font enlarge/shrink' icons is another magnifying glass, but this one is for searching in the webpage! Anyone who thinks for 2 minutes about this realizes it's a bad idea to have very similar icons with completely different functions next to each other, but somehow these sort of glitches appear in KDE.
You can fix this yourself easily. Go to the Settings->Configure Toolbars section and select the "Main Toolbar " toolbar and simply remove the "Find" button from this toolbar. I agree, it's quite unbelievable someone didn't think twice about this one. A bug report is still in order... But the fix is here now...
Errr, yeah right. Where do people come up with these numbers? Oh right, you're multiplying their share value times the number of total shares of stock.
Be's market cap has been hovering around $20 million for ages now. I don't see anyone paying a premium price.
You do realize this is a meaningless number, right?
As meaningless as your drivel, sure:)
Well now your bitterness is just showing...
Please.. I couldn't care less what happens to Be at this point in time. The whole situation does have an entertainment value nonetheless.
BeIA certainly competes head to head with QNX in internet appliances.
QNX is in the embedded space, of which IA's are only a fraction. And we all know IA's are a terrible flop. Who's going to pay $500 for a crippled proprietary PC these days?!! Be management jumped on the IA bandwagon/hype without doing market research themselves. OTOH everyone was predicting the IA market to be a multi-billion dollar one by now.
? It's pretty selfish of you to criticize a company that re-focuses so that they can SURVIVE
Huh? You call this surviving??? Get real....
myself would rather them survive, make money, and THEN go back to BeOS development
Dream on. If they ever made money with BeIA do you seriously thing they'd pick up BeOS development again? That's a carrot they've been dangling in front of the remaining developers. Don't take it seriously...
-adnans
Re:Be made a lot of good choices and still they're
on
Be Buyout Looms Closer
·
· Score: 2
Be had a great piece of hardware, but couldn't sell it
Their hardware was cool, not great. My BeBox was obsolete the day I got a PII 233 box. The PII was much faster at most tasks. The BeBox was basically crippled by the MPC105 Bridge/Controller they used. This chips allows for a single PowerPC with L2 cache, or two PowerPC chips without L2 (in the case of the BeBox). The Bebox was at that time the only way to go if you wanted to code for Be. Shortly thereafter they ported it to Mac hardware, and a few years later to x86. Unfortunately the extra BeBox hardware was very underutilized. I think I wrote one of the only programs for BeOS that actually did something with the 3 built-in IR ports (remote controlled MP3 player). AFAIK there was only one company that ever released hardware for the infamous GeekPort(tm)....
But then again, Be only managed to sell a handfull of these boxes, and all of them at a loss.
They are in the same space as Be is trying to penetrate and I think they have the cash and the incentive. Gain some technology and eliminate a potential competitor for 'pocket change' (Be is worth about $20 million). Not that BeIA poses a big threat to QNX's offering.
In the end I think it's poor management that killed Be (think: Commodore -> Amiga). Here's a quote from the quotable JLG:
"don't compare us to NeXT. We want to be a better tool for developers, not to be tasteful. We don't cost $10,000. We have a floppy drive. We do not defecate on developers."
...Yet that's EXACTLY what they've been doing for the last 2 years...
Slashdot Mirror
I don't know about you, but I've found from personal experience that multimedia playback is on average very poor in Linux. I mean there isn't a decent Divx ;-) player anywhere.
;-) / MPEG / AVI / ASF / etc. player. It plays DivX files flawlessly. The best part is the cool keyboard control.
Oh, you haven't tried MPlayer then. It's an excellent DivX
As for audio I have a SbLive! and I have it correctly configured in every way in both windows and linux. Windows audio playback with the same speakers and extremely similar configurations is just far superior
The Windows audio playback is probably using the advanced futures of the Em10K chipset. Programming info for the DSP is sadly not free, and thus not available to Linux users, hence no advanced sound features. But this isn't Linux's fault.
In linux I get noise and distortion and just crappy sound
Have you tried the ALSA drivers with it? It might give you better quality.
-adnans
I thought giving the Kernel the ability to preemt other programs was important. If you give programs the ability to preempt the kernel, doesn't that just change the system back to cooperative multi-tasking?
Nope, because the kernel is still always in control. In a cooperative multi-tasking enviroment the userspace programs can choose to hold on to the processor as long as they like (i.e. not cooperate nicely with others). This patch simply allows a lower priority process to be interrupted by a higher priority one even if the low priority one is in the kernel, doing a system call for example. However, this preemption is done by the kernel scheduler.
-adnans
But won't that make the problem even worse? Unless you have a veeery slow Linux box (486, 16MB RAM) you can probably do a dozen compiles or more in one week :)
And I can pretty much say for 100% that the kernel will not compile with LCC. Plus you must have an as86 compatible assembler to build the more interesting parts. Nevertheless, good luck, and if you do succeed, let us know! :-)
Also, check out CygWin
-adnans
"and hardware-accelerated alpha blending"
buzzword or actually implemented in the new KDE/Qt? Alpha blending IMHO increases elegance (not to be confused with usability) of an interface when used properly. Any KDE developer(s) care to explain how and what this actually means? e.g. Render calls, which components use this, etc?
Thanks,
-adnans
Courtesy: www.q3cft.de
n uxq3apoint-1.30.x86.run
http://q3ctf.net-soldiers.org/download/patches/li
-adnans
Let that title song of be a one-off one?! I mean, who wants to listen to a crappy Bon Jovi style theme song everytime an episode starts?!! :)
-adnans
You can't actually *do* anything in it... it's locked into 'spectator mode'. This isn't made clear in the article (you do get to watch all the windows users killing each other though).
Bullshit. You can play just fine. I suggest you read the docs, and maybe TRY it yourself.
I wasn't impressed anyway... it's just counterstrike by another name, except it's stupidly CPU hungry - certainly my Dual Proc 800 + Geforce couldn't handle it without grinding to a halt every few seconds.
Looks like you have configuration problems. My single CPU Atlon 900 + Geforce2MX400 works just fine at 800x600 on TVout.
-adnans
Who cares! It means that life outside earth's athmosphere is possible (without the aid of technology). If life can survive and thrive on Mars, who knows how many other life forms are out there!
-adnans
It's, quite frankly, more than a little bit easier for existing FreeBSD developers to write a given driver than it is for them to teach someone what to do. Writing drivers involves intimate familiarity with the system, especially with a system where the kernel API has been in a constant state of flux in the long-running development branch.
OMG, no wonder FreeBSD is having trouble sustaining its engineering pool. What you are basically saying is that newbie driver hackers are not welcome because the existing 'established' developers, no matter how swamped they already are, can do it better and faster?! That's just silly.
-adnans
So? Remember, you don't *have* to upgrade your kernel everytime a new patch comes out. I have a production machine with 2.4.3-XFS that has already logged over 130 days of uptime and still going strong. I will most likely start test-running 2.4.10-XFS once that comes out and if proven sufficiently stable will switch over.
that's why I stated in my original post that Linux WILL become the ultimate media OS. Its just not there right now.
Good, at least we can agree on that point
[explanation cut]... Most modern OSs go through hoops to make sure that processes that are I/O bound get as many chances as possible to make requests for I/O. Thus, they can wait on the I/O while other threads use the CPU.
While this is true, implementations of multi-threaded X servers (to overcome the theoretical contention problem you describe) have proven that speed gains are only marginal. So in the real world you will have to choose between:
Pick your poison. JBQ makes an excellent point when he states that BeOS forces developers "to handle asynchronous events through threading, such that the core services of the operating system only handle synchronous requests".
Maybe. Setting up a separate connection for each view seems slow though, and might blow chunks if you actually use the networking features of X
The performance and responsiveness of remote X apps is entirely determined by your network speed and latency (on my local LAN remote X window creation is practically instantaneous).
-adnans
The default Linux kernel's audio latency still blows, and even the guys doing the low-latency patch still use BeOS as a benchmark for low latency
:) Of course, all of this patching will not be necessary once these go into the main kernel tree, and the will go in. At least great things are happening. Can't say that for BeOS.
:-) See the screenshots on my homepage with 20 audio scopes running perfectly sync to the 3 audio files being played, simultaneously with gobs of CPU cycles to spare :)
Probably because BeOS made the biggest noise about low latency audio support.
For example, if you want XFS and low latency in the same kernel, its a crap-shot if the two patches are in sync. And with Linus's kernel of the day syndrome, that situation won't get any better.
Actually the people that really want or need this right now, this moment, can get their cake and eat it too. FYI, I have 2.4.10-pre1-xfs + low latency 2.4.9 patches running just fine
What about drawing to multiple views?
What about it? Your PC will never draw to multiple views simultaneously, not even on BeOS (and not even on an SMP box). That's because there's only one blitter engine on the graphics chip.
Of course there can be multiple outstanding draw requests, but X and gtk+ in combination with the GDK_THREAD_ENTER/LEAVE calls take care of that very well. Oh, and you can always open multiple X server connections from a single application. You will get multiple X pipelines (that get serialized in the X server / graphics driver) but at the application level you will have the equavalent of multiple BWindows with their own BLooper. And since everything on a X screen is inside an X Window you can treat all elements as Views.
If GTK has a single global lock, doing GTK+ operations on one window will lock out those doing operations in another window.
You only ask for the lock when you change internal shared data structures or if you want to push a pixmap to the screen. It's the same as in BeOS. Offscreen drawing can be done inside a gdk pixmap, and you don't need to hold the lock to do this. Only when you are ready to blast the pixmap on the screen do you request the lock. That's exactly how things work in BeOS. The locking might take place on another level but in essence it's exactly the same. And not surprisingly, BeOS mutithreaded code runs at the same performance level in Linux/X (at least my applications do
Also, many operations don't use the graphics hardware anymore. GNOME's canvas uses LibArt heavily, and as far as I can see, it is 100% software.
The canvas is just an offscreen image. You can have multiple canvas widgets being modified by multiple threads without problems. That is if libArt is reentrant itself (I've never used it). In the end, the canvas images will have to be drawn in the framebuffer and that is done by a single hardware blitter device.
About Win2000 using so many threads. It'd be interesting to know how many of those threads are created by the programmers explicitly, and how many are the result of just calling a function in win32.
No, not just because it is technically cool. Because with Win2K getting more popular, WinXP coming into the home, and dual Duron systems costing chicken scratch, SMP machines will become very popular. Apple's multi-proc machines were of limited usefulness because so little Mac software is multithreaded. Systems that use threading agressively (and yes, it is possible to use it agressively and still correctly) won't have this problem.
The average Linux installation, will benefit greatly by running on an SMP box. And this, out-of-the-box.
I have 102 processes loaded, that's with 6 Konqueror windows, a bunch of deamons, 8 terminal windows and my audio player on screen. If I had multiple processors in my box, they would all be utilized fully...You don't need very fine grained threading for that (remember, processes are just glorified threads, or the other way around, depending on how you look at it)
-adnans
Sorry to have 2 replies but I was just very surprised when reading the following piece of text from JBQ:
:-)
"Big surprises here : there's usually only one mouse, only one keyboard, such that cases where several applications have to respond to input events at the same time are marginal, unusual cases. As for redrawing, all the redrawing events are sent to the graphics chip, which can only deal with one acceleration at a time anyway. "
And that's exactly what I was saying 2 minutes ago.... JBQ rocks
-adnans
I already have, in my previous post.
:) I spent countless hours coding neat stuff for BeOS (it wasn't even called BeOS back then). Hell, I ported one of the first MP3 players over to BeOS :-) I know all about its pervasively multithreading enviroment. Back then I was simply amazed at how easy it was to get graphics and sound mixed with threads. But it was always a toy. You could do neat stuff with it, but there were no real advantages over other OSes at the end of the day (with the exception of the journalled FS).
:) Oh, and it uses GTK+ for threading the scope windows. Yes, each scope window has it's own worker thread, just like BeOS. In this case, it is usefull to have multiple threads calculate and draw the scopes in offscreen bitmaps before blitting them to the screen. Bottom line: use threads where they're usefull, don't use them pervasively (perversely :), just because it's technically "cool".
:)
Oh, I remember refuting many (all) of your points against Linux/X11 a couple of weeks/months ago. I will pick legacy, network transparant, X11, with Geforce2, full OpenGL, over BeOS Vesa 2.0 any day, thank you very much. It makes practical and technical sense...
The next part of your arguement basically boils down to "ignore all the technical reasons, Be died so BeOS must have sucked," and "BeOS sucked because it wasn't easy to port to."
If you want to read it that way, sure. I never said BeOS sucked, however it's faaar from being superior. I was into Be probably way before you even heard of them. I have a BeBox to prove it
GTK+ 1.2 is hardly thread safe. According to the GTK+ FAQ, there is a global lock on the whole system which negates any advantages of threading
Oh really? I think you need to take some more classes on threading then. Since your videocard is not multi-threaded all drawing events gets serialized at some point. The global GTK+ is ugly, but very effective. And your applications still take advantage of threading, if you code them correctly. Heh, just a couple of days ago I hit a locking bug in my pet project. The whole GUI froze because I acquired a lock twice, yet the music kept playing on. It even jumped to the next song in the playlist. The GUI thread was deadlocked, yet my audio and disk thread continued like there was nothing wrong. Sure, gtk+ global locks negates any advantage of threading, NOT! You use threads to do CPU intensive work while still being able to process other events (like the GUI). You do not use threads to fight for the single 2D pipeline that most PC graphics cards have these days.
As for Qt 3.0, it hasn't been released yet, so it is of no consequence at the moment.
Oh dear, I should wipe my stolen copy quickly then!
The reason I say that GUI developers should be forced to use threads is because, all too often, developers try to use (comfortable) procedural techniques to do GUI programs, which ineherently lend themselves well to a messaging/multi-threading model.
With the risk of not taking into account the technical advantages this has I will say that this model hasn't helped BeOS one bit! The fact that any programmer that wanted to put a BWindow on the screen had to deal with threads and locking has IMHO stiffled application development a great deal. Just look at BeBits.. it's full of "Hello World" style apps. There are very few mature applications available.
Anyway, JBQ makes a good point: it is hard to port non-threaded software to a threaded environment
He also points out that there are fundamental problems with the way BeOS handles inter-thread messaging. These problems will probably not bite the average graphics viewer coder, or the mp3 player program, but they will bite once you start coding moderately complex tools.
Threads are cool, I use them every day. But like you say, they are not the silver bullet. On a sidenote, my heavily multithreaded audio player has been churning through a 3000 entries long playlist for 2 straight days now, rock solid
BTW, you should go back to the forum/discussion area I pointed out earlier. There's some more interesting notes from JBQ on the "pervasively multithreading" nature of BeOS (He mentions smoke and mirrors.... ugh
-adnans
I really wish someone would include BFS-style attributes in an Open Source file system
:-)
It's called XFS
XFS supports extended attributes just like BeFS. no wonder, since BeFS is based, at least in part, on ideas originated in XFS. You will need some userland tools to set extended attributes and probably a modified tar if you want to preserve attributes inside archives. The web page on Access Control Lists and Extended Attributes might also prove useful. Now, combined with fam & imon , which provide (i)node monitoring you have everything except indexed searching, all in Open Source (imon is actually a kernel patch that adds node monitoring at the VFS layer)
-adnans
All OS afectionados love to brag. At least BeOS users can brag and not lie. I've laid out several reasons why (as a Media OS) BeOS beats Linux. If you'd care to refute any of these, be my guest.
...there is the fact that BeOS's API encourages developers to extensively use attributes
:-)
...which is why neither GNOME nor KDE use threads extensively
:)
Sure, list them. I happen to know a couple of people who are migrating their (BeOS) Media applications straight to Linux. No point in building your software/hardware on a dead/unsupported system. And from my own experience in porting BeOS software to Linux, I can say that Linux provides most everything that is needed and much more (e.g. progress).
BeOS was designed to encourage highly multithreaded programs with fast GUIs.
Sadly, this hasn't panned out too well. It takes quite long time to get threads right. Porting apps from other OSes took considerable effort and willpower. Be talked about the "tractor app" thingy since 1995. To date there hasn't been a single native tractor app for BeOS. So much for the highly multithreads programs with fast GUIs.
And in the process they pretty much lock themselves to BeOS' APIs. And we all know how large the BeOS installed base is
but you don't see applications doing this prevasively, do you?
No, because well, there's no reason to do so, unless there's a broader standard, and clearly there isn't (look for ACL/extended attributes integration in the 2.5.x kernel tree). BeOS was ahead of the pack, but unfortunately for Be and its develoeprs that meant shit..
the lack of any central encouragement precludes large scale integration of media apps.
Again, this hasn't helped Be one bit. Why? Because the Media Kit is so full of bugs, not to mention horribly documented, it is practically impossible for anyone outside of Be to write any Media add-on more complex than an audio codec.
The only apps that really benefit from threads are media applications and most, if not all of them do use threads. GTK+ 1.2.x is already thread safe. Qt 3.0 is too. But because developers are NOT FORCED to use threads you will most likely only encounter them when they actually make a difference! I do wish Mozilla used separate threads to manage each browser window. Anyway, threads have their place but don't glorify them too much (just watched over 3 hours of perfectly synced DVD, thanks to some clever threading
Where? I looked through the entire BeOS board, couldn't find anything related to multithreading. Did searches for both "GUI" and "thread." "Thread" turned up on irrelevant hit, while "GUI" simply turned up some articles about improving the GUI. What posts are you referring to?
This thread. Read the comments by JBQ.
"Multithreading sounds cool, but it's an unnecessarily complex beast to master, and the fact that it's asynchronous by nature makes it fairly hard to debug, and creates some behaviors that vary a lot between machines. Plus, people learn and like to write synchronous code. "
and
"The problem with BeOS isn't the fact that the kernel allows for multiple threads. The problem is the fact that developers are forced to use multithreading under BeOS, that they are forced to use the BeOS locking mechanism, and that various bugs and limitations in BeOS make all that even harder than it should already be. Sure, a computationally intensive application might (and probably will) benefit from spawning an extra thread. Sure, a game that needs to send feedback to different output devices might benefit from putting the game engine in a separate thread. But in many cases, it's just overkill. "
-adnans
Really, what's the point of running the emulation if you lose speed and capabilities?
:). Oh, and if it ever crashes you just double click that vmware icon and Win2000 is up an running again in 20 seconds :-)
The point is that you get to run another OS while still having access to your regular OS. I can keep my development enviroment and monitoring tools up and running in Linux, while booting Win2000 in VMware and browse that one webpage that requires a plugin that's not available in Linux (yet). And if you fullscreen Vmware you will NOT notice that you're running inside Vmware since it's feels as fast as the real thing (granted: 1.33GHZ + 512MB DDR
If you need to ask why, it's probably not for you anyway....
-adnans
....... At its current pace of development, there is no doubt about that. However, that level of development will only compare to what BeOS was in 1998.
:). However, that's probably one of the reasons BeOS is gone today. Too much arrogance, too little substance!!
Hahaha, and how is that going to help us? Be fans LOVE to point out the "superior" technology in their beloved BeOS (I was once such a person
Yes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want tYes, Be had a lack of applications. That's the problem that any alternative OS that doesn't use X must endure. OSS-types talk about freedom, but what about those who want to be free of the shackles of X?o be free of the shackles of X?
Funny, X is still around after all these years, while BeOS is going down the toilet faster than a turd spinning counterclockwise in Australia. Why don't you port or rewrite the 'great' BeOS Interface Kit to X. You can get all features, including one thread per window on X today, no populair toolkit does this however. I know there is closed-source code out there that does exactly this. According to you people are probably begging for this functionality right now...So go on!
BTW, if you read the osnews.com forums you'll see that there are several serious issues with the BeOS pervasively mulit-threaded interface.
-adnans
Who says no one wanted it? Looking at the feature set, I am confident that had I seen BeOS then, I would have picked it up, along with Linux.
:)
He was talking about OEMs. BeOS was offered free of charge to any OEM who wanted to pre-install it on their new PC. JLG made a big hoopla out of this. The only problem was that no OEM wanted it......
But they all dropped the ball, indicating that other factors were at work. To all our detriment.
Yeah, the biggest factor was that BeOS was never a drop-in replacement for Windows.
Just think: by 1997, we could all have a multimedia capable OS
I had a multimedia capable OS long before that. Oh, and in 1997 BeOS multimedia was in a sad state. The new media-kit hadn't arrived yet, and it didn't run on commodity x86 hardware yet, so you had to buy a ridiculously expensive Mac machine or a second hand BeBox to get it to run.
with a journalling filesystem.
Journalling is nice, journalling was also very immature on BeOS. I remember loosing 2 filesystem because they got full. Go figure
-adnans
XFS is great. I have it on 2 production servers (rock solid since installation). However, for my workstation I've recently switched (back) to ReiserFS. I do a lot of large compiles and move huge amounts of code around and that exposes the ONLY weak part in XFS: unlink() time. XFS is doog slow for deleting large directory trees. I sure hope they optimize this, soon.. Other than the long rm times, it's rock solid. The ACL ioctls should be sorted out too soon, so we can have access to extended attributes (I will NOT miss you Be, Inc.)....
-adnans
BeOS was developed on 66MHz PPCs with 16MB of RAM and it shows. The damn thing runs like hell on mediocre machines, and even faster on faster ones.
:-)
It was also far from what it is today, no journalling filesytem, very crude "Media Kit", very little drivers, horrible VM (still does), etc. etc..
I went back to PR2 on my BeBox, since the latest release (R5) is about 50% slower for most things. Of course driver/application support on PPC is even more pathetic than x86 (imagine that) so it really doesn't matter. The once glorious and ultra-hip BeBox is now a SSH terminal box
Yes it even needs it's own HUB since no 100Mbit network card works in it...not that the network kit would benefit from it.
-adnans
He could move the find button to another position on the toolbar (not squarely beside the magnifying buttons). That should reduce the confusion quite a bit...
-adnans
And here's a KDE weakness. Right smack next to the 'font enlarge/shrink' icons is another magnifying glass, but this one is for searching in the webpage! Anyone who thinks for 2 minutes about this realizes it's a bad idea to have very similar icons with completely different functions next to each other, but somehow these sort of glitches appear in KDE.
You can fix this yourself easily. Go to the Settings->Configure Toolbars section and select the "Main Toolbar " toolbar and simply remove the "Find" button from this toolbar. I agree, it's quite unbelievable someone didn't think twice about this one. A bug report is still in order... But the fix is here now...
-adnans
Errr, yeah right. Where do people come up with these numbers? Oh right, you're multiplying their share value times the number of total shares of stock.
:)
Be's market cap has been hovering around $20 million for ages now. I don't see anyone paying a premium price.
You do realize this is a meaningless number, right?
As meaningless as your drivel, sure
Well now your bitterness is just showing...
Please.. I couldn't care less what happens to Be at this point in time. The whole situation does have an entertainment value nonetheless.
BeIA certainly competes head to head with QNX in internet appliances.
QNX is in the embedded space, of which IA's are only a fraction. And we all know IA's are a terrible flop. Who's going to pay $500 for a crippled proprietary PC these days?!! Be management jumped on the IA bandwagon/hype without doing market research themselves. OTOH everyone was predicting the IA market to be a multi-billion dollar one by now.
? It's pretty selfish of you to criticize a company that re-focuses so that they can SURVIVE
Huh? You call this surviving??? Get real....
myself would rather them survive, make money, and THEN go back to BeOS development
Dream on. If they ever made money with BeIA do you seriously thing they'd pick up BeOS development again? That's a carrot they've been dangling in front of the remaining developers. Don't take it seriously...
-adnans
Be had a great piece of hardware, but couldn't sell it
:)
Their hardware was cool, not great. My BeBox was obsolete the day I got a PII 233 box. The PII was much faster at most tasks. The BeBox was basically crippled by the MPC105 Bridge/Controller they used. This chips allows for a single PowerPC with L2 cache, or two PowerPC chips without L2 (in the case of the BeBox). The Bebox was at that time the only way to go if you wanted to code for Be. Shortly thereafter they ported it to Mac hardware, and a few years later to x86. Unfortunately the extra BeBox hardware was very underutilized. I think I wrote one of the only programs for BeOS that actually did something with the 3 built-in IR ports (remote controlled MP3 player). AFAIK there was only one company that ever released hardware for the infamous GeekPort(tm)....
But then again, Be only managed to sell a handfull of these boxes, and all of them at a loss.
-adnans (still a proud BeBox 133 owner
They are in the same space as Be is trying to penetrate and I think they have the cash and the incentive. Gain some technology and eliminate a potential competitor for 'pocket change' (Be is worth about $20 million). Not that BeIA poses a big threat to QNX's offering.
...Yet that's EXACTLY what they've been doing for the last 2 years...
In the end I think it's poor management that killed Be (think: Commodore -> Amiga). Here's a quote from the quotable JLG:
"don't compare us to NeXT. We want to be a better tool for developers, not to be tasteful. We don't cost $10,000. We have a floppy drive. We do not defecate on developers."
-adnans (ex BeOS coder/enthousiast)