In other words, Berlin takes the Mac approach of taking UI decisions away from app developers.
>>>>>>>>>
Yea, and it gives the decision back to the user! I like the Blue Metal theme, but my Athena apps don't look like that! And the KDE Blue Metal theme is a little different and the buttons look wierd. I don't give a rat's ass what the developer thinks looks nice, I want it the way I want it!
Themes, schmemes, that's not real choice. Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin.
>>>>>
Honestly, most developers aren't smart enough to be innovative. In a one-toolkit system, there is still room for innovation, since nothing prevents you from adding your own widgets. For example, TrueSpace and Bryce have pretty imaginative interfaces. True, it's more work to implement custom widgets, but that's a good thing. That way, people who really have good ideas can work a little harder to impelement them, while people who are just lazy (and would have created inconsistant rather than innovative interfaces otherwise) can just use the default. For desktop OSs, its probably good to dictate policy this way because people really don't want inconsistancy without really tangible benifets.
the size of an object on a 15 inch screen is the same as its size on paper, which is the size of an object on the big viewscreen at NASA...users would be compelled to use the highest resolution/color depth possible for the visual quality rather than for the space on their desktop.
Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution.
>>>>>>>>
Dude, its called a third generation graphics layer. Anything that uses virtual coordinates has this "problem." If you want to do it differently, just change the mapping (its very easy in OpenGL).
OK, maybe that's overstating the case a bit.
>>>>>>>
What case;)
The point remains, though, that they have strong assumed that there's one "right way" to do things. Even Windows lets you specify lots of things in either pixels or inches (or centimeters, maybe - I don't remember).
>>>>>>>>>
If its in inches, its the same thing as using virtual coordinates. Pixels are an ancient relic that really need to be discarded. Font-sensitive GUI layout libraries all the way baby.
As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.
>>>>>>>>>>
And if an app really does have the need to change a default, they can do it, they just have to do a little more work. You really have to ask yourself, does my app really need to make something 3.1" when 3.0" is the default? If it does, then go ahead and override the defaults. If it doesn't, just go with the flow. In a system that doesn't impelment some policy, you have people using 3.5" and 3.52" 9cm, just because the developer liked it better, not because of any real merit. The mere fact that most people consider KDE and GNOME to be functionaly equal attests to the fact that (in that case) competition doesn't make things better, just different.
you've just blown a whole lot of clock-cycles on nothing
>>>>>>>>>>
A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.
B) This is hardware accelerated, courtesy of OpenGL. Transparency, for example, is painful in 2D cards (since its done in software) but OpenGL cards are built to handle this. Trust me, if a run of the mill TNT-1 can handle Carmack's love creations, it'll have no trouble handling a simple (or complex) desktop.
Another thing you forgot. OpenML is quite heavily tied to OpenGL, so a server that uses OpenGL for display will have a leg up in integrating ML's functionality into the system.
1. You mention in your FAQ that a developer can use a wrapper around QT and GTK+ - nice idea, but what about Motif stuff? wrapper around those also? same for TCL/TK, FLTK, and native xlib stuff? This will make everything VERY slow..
>>>>>>>>>>
Sorry to break this to ya, but Qt, GTK+, etc are essentially just wrappers around X anyway. Its not fast the way it is NOW.
Sorry for the two replies, but I had to point this out. I don't like Linux's tendency to use multiple processes instead of threads. Whenever you switch processes, you have to change memory maps, frag your TLB, blow some cache, and it just gets nasty in general. Heavly multi-processed code is almost exactly equivilent to multi-threaded code, so I don't know what the justification is for using one over the other. The only thing multiple-processes buys you is protection from your own threads. And Linux has some pretty good threading code, so its not lack of support in the platform.
Probably because BeOS made the biggest noise about low latency audio support.
>>>>
But more likely because it has audio latencies a order of magnitude lower than stock Linux and Windows.
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.
>>>>>>>>
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. That's why I said it was a crapshot. And I know that 2.5 is getting lots of latency work, that's why I stated in my original post that Linux WILL become the ultimate media OS. Its just not there right now.
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.
>>>>>>>
Only if all you're doing is shoving bitmaps at the screen. The actual drawing code CAN run in parallel. Let me explain this to you. Say you start drawing a line. The line algorithm steps along the line and starts writing the pixels to video RAM. Halfway through, you're thread gets preempted and another graphics thread starts running. If there is a global lock on the drawing code, then that thread will block until the first thread finishes drawing. On the other hand, if everything is correctly parallized, that second thread can keep on writing to memory without interfering with the other thread. Also, the blitter can be shared as well. True, there is one blitter, but it is one hellishly fast blitter. On my DirectX tests, the RivaTNT's blitter can blit more than 30,000 small bitmaps per second. Thus, it can blit a bitmap once every 33 usecs. Also, the blitter can queue up blits. That leads to the following scenario: say a process locks GDK, issues a series of blits, then unlocks it. During this process, it is preempted by another drawing thread. By the time the system has done a context switch, most of the blits will be done. If they aren't, the thread can still issue more blits to be queued. If there is a global lock, however, the second thread will sleep, and by the time the system gets around the scheduling the first thread again, all of the blits would have completed long ago. In a parallel system, the second thread's blits also would have been queued and completed. In a serial system, only the first thread's blits would have been finished. The idea of keeping the I/O hardware as busy as possible is an important one in OS design. 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.
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.
>>>>>>>>>>
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. But I'd have to look at performance data to be sure.
Its more dishonest to try to make it seem like a chip has a higher clockspeed than it does. I'm not defending Intel, but their behavior doesn't make AMD's OK. At least Cyrix used PR number upfront by calling them MII PR300s. AMD isn't even going the PR route.
Yea, but thats misleading. The PCxxx spec denotes clockspeed, not bandwidth. Calling it PC2100 makes it seem 21 times faster than PC100 RAM, and almost three times as fast as PC800. Intel doesn't claim to have PC-3200 RDRAM in its P4 computers, even though the P4's memory banks have 3.2 GB/sec of bandwidth.
I don't get your arguement that BeOS isn't superior to Linux for media. 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. True, the low-latency kernels do get far lower latencies than BeOS these days, but they still aren't part of the main tree, and thus aren't available to many people. 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.
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.
>>>>>>>>
What about drawing to multiple views? If GTK has a single global lock, doing GTK+ operations on one window will lock out those doing operations in another window. 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.
Oh dear, I should wipe my stolen copy quickly then!
>>>>>
That's not my point. My point is that it hasn't been released, it isn't in any distros, and is thus not really usable yet. Even after its release, it will be awhile before many apps take advantage of its features.
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.
>>>>>>>
I don't really think that its is really the multi-threaded nature of BeOS that stifled application development. Windows 2000 uses threads even more agressively than BeOS (right now, with 2 IE Windows, two explorer Windows, and MS Word running, I have 273 total threads, maybe 100 that don't sleep all the time), and it has a ton of mature software. MS word uses half a dozen threads with one document open. IE uses 32 threads for its two windows, and there are over 30 system threads running. And Win2K can hardly be called an unstable environment. And Word 97, Visual Studio, and IE-6 are all sold, mature, complex programs that are EXTREMELY responsive to the user. I'm not dumb enough to think that more threads are necessarily better, I'm just pointing out that complex multithreaded environments ARE possible and they CAN be stable.
Anyway, JBQ makes a good point: it is hard to
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.
>>>>>>>
Yes, this dropped message thing is troubling. But it has yet to pop up in actual usage and if BeOS development had continued it could presumably be fixed. QNX is totally message based, and I really doubt you'd trust a nuclear reactor to an inherently flawed model.
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 [alsaplayer.org] 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".
>>>>>>>
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.
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:)
>>>>>>>>
Yea I read it.
Uh, no. PC800 transfers at 1600 MB/sec. Its clocked at 400MHz base * 2x DDR * 2 bytes per transfer = 1600 MB/sec. And yes, its honest to report DDR busses as being double the megahertz because they mostly behave that way. Thus, PC-2100 really is DDR-266.
Its creepy that Intel seems like the honest platform now. A P4 2000 is actualy 2GHz. PC800 RDRAM is actually 800Mhz. But calling an Athlon 1.4 an Athlon 1600 is almost as bad as calling 266 DDR SDRAM PC2100!
Except not really. BFS is very well documented, and some of its code actually appears in Giampalo's fskit. Plus, all of the data structures are cleanly laid out, so implementing a clone (eg. AFS) is very straightforward.
Practical File System Design by Dominic Giampalo.
Great book, has a detailed overview of the BeOS structure, some comparisons and explanations of other filesystems (like ext2, NTFS, XFS, and HFS+), and a cool file system builder kit with full source to pretty nifty example filesystem.
Sure, list them.
>>>>
I already have, in my previous post.
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." I make no arguement that Be the company is pretty dead, but I'm not talking about success. I'm talking about the technical quality of the OS.
The only apps that really benefit from threads are media applications and most, if not all of them do use threads.
>>>>>>
That's not really true. Many applications can benifet from threads, it just requires a different style of programming. People said the same thing about OO programming until they realized that the main problem was that too many people were too set in their procedural ways. I've programmed with threads ever since I left high school comp-sci, and it really isn't that hard. Its more difficult to debug, true, but not appreciably, if the app is coded in a multi-threaded way to begin with.
GTK+ 1.2.x is already thread safe. Qt 3.0 is too.
>>>>>>>
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. As for Qt 3.0, it hasn't been released yet, so it is of no consequence at the moment.
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:)
>>>>>>>>.
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. Plus, it is a big boon to those with SMP machines (getting more and more common) if an OS's application base is extensively threaded.
That's wasn't in the forum, it was attached to a story. Anyway, JBQ makes a good point: it is hard to port non-threaded software to a threaded environment. But that's not the issue here. BeOS was designed to get rid of a lot of baggage, and unnecessarily single-threaded software was one of those pieces of luggage. I've been a BeOS user for several years, and the apps have been extremely stable, multi-threading or not. People who have developed native BeOS applications have pointed out that it is easy once you understand it. I'm not trying to claim that threading is a silver bullet that will solve everything. However, it is a technique that has many advantages, especially for SMP machines, that that technique is often ignored by software developers who are too scared to architecture their programs differently.
Yes, but they are largely useless. In every RPM-based system I've ever used, you're almost forced to install programs with --nodeps. This is due to its stupid dependency setup that checks not for file dependencies, but package dependencies. This becomes a major headache if you, for example, install something like X by compiling it. It is difficult to express these more advanced features of RPM in a GUI that is also easy to understand.
Actually, it might be possible to use BeOS's indexing system to implement something like this, although I don't know how hierarchical stuff like typenames are.
That's true, but you're thinking too much in a windows-oriented way.
>>>>>>
I hate to say this, but the Windows way is the right way, in this case.
In windows, you need to tell where to place software because the drive letter filing system forces you.
>>>>>>
It's not the drive letter filing system. For most configurations, Linux's and Window's filing systems are the exact same, except with different root directory names and different path seperators. Its not the FS, but the installation convention.
In linux, since everything is part of one big file tree it's easier to differentiate file types in different directories.
>>>>>>
But people don't think in terms of filetypes, they think in terms of applications.
For example, in debian, most application's binaries will go to/usr/X11R6/bin, theiur libraries to/usr/X11R6/lib and their documentation to/usr/man for the manpages and/usr/share/doc for the readme, changelog and extended documentation. I used to dislike it too, but only because I was used to the windows system. It's far more logical if different types of files end up in pre-determined locations, so you never have to go hunting around your disk when you want something specific.
>>>>>>>
Its more logical if you're a computer, but less so if you're a human being. If I want documentation for program FooBar, I think about the program first, then what I want to do with it. Its the whole concept of object orientation. Its not find_readme(programName), but programName->FindReadme().
The whole UNIX filing system is seriously screwed up. With todays software applications with their dozens of files, it goes against the whole hierarchy convention to just jam everything into/usr/bin or/usr/lib. It requires too much central control (the Debian guys have to make sure that nothing conflicts) and is too prone to losing files. What happens if namespaces conflict? What happens if you rename a file (or more usually, a symlink). All of these things result in uneeded files being left around. It gets even worse with compiled software (which is often necessary, if you tend to keep up with the latest releases). There is virtually no way to uninstall compiled software without resorting to using something like encap.
To be honest, I can't understand why the debian and debian-derived distro's are the only ones using apt-get. It's so much better than windows and slightly better than rpm (since dpkg is the equivalent for rpm, but what is the rpm equivalent for apt-get?).
>>>>>>>
urpmi.
Let me use NeXT as the ideal app management system. All apps are self contained in bundles. Installing the app involves putting a bundle in the appropriate directory. Uninstalling the app involves deleting the bundle. Simple, clean, and extremely flexible.
Uh, no. Clicking setup.exe works 90% of the time under Windows. 90% of the time under Linux, rpm -i koffice*.rpm gives you an errror message saying you need to install some other RPM. Then you have the fact that circular dependencies can only be resolved by putting both RPMs on the same command line. Then... then you have a user who just wiped Linux and reinstalled Windows...
Even when it works, typing rpm-i koffice*.rpm requires breaking out an xterm, cd'ing to the right directory, and typing the comman. You've already lost a whole lot of users right at 'xterm'.
Yes, KDE2
Maybe because IE is loaded by the OS when the computer starts? As for Word staring that quickly, that's total BS (at least on my machine).
>>>>>>>>
Even when you have started the app previously (which means that Linux will cache the image), all KDE-2 apps still take several seconds to load. I know that this isn't a problem with Linux, since most Athena apps of comparable functionality take much less time to load. As for Word, I don't know how your machine is configured, but mine is a nicely tweeked Win2K machine running on a PII-300 with 256MB of RAM. I have all the stupid graphical features turned off, I have harddrive indexing turned off, and I've done the standard little tweeks. Word (97, but 2000 isn't much slower, and Word 97 still beats KWord in functionality) starts up in a second or two. After having loaded it once, starting up is instantaneous.
With both my GeForce II and Radeon (the Radeon generally locks up within 10 minutes or so under W2K, too).
>>>>>>>>>
Hmm, did you update the graphics drivers for both? Win2K is really finicky about bad drivers. Do you have DMA disabled? Win2K doesn't like the SiS 630's IDE controller. Do you have lots of things running in your system tray? Win2K is faster than KDE-2 for a whole lot of people, so its not just my config.
Slashdot Mirror
In other words, Berlin takes the Mac approach of taking UI decisions away from app developers.
;)
>>>>>>>>>
Yea, and it gives the decision back to the user! I like the Blue Metal theme, but my Athena apps don't look like that! And the KDE Blue Metal theme is a little different and the buttons look wierd. I don't give a rat's ass what the developer thinks looks nice, I want it the way I want it!
Themes, schmemes, that's not real choice. Any time you add flexibility you create opportunities for both inconsistency and innovation; they're two sides of the same coin.
>>>>>
Honestly, most developers aren't smart enough to be innovative. In a one-toolkit system, there is still room for innovation, since nothing prevents you from adding your own widgets. For example, TrueSpace and Bryce have pretty imaginative interfaces. True, it's more work to implement custom widgets, but that's a good thing. That way, people who really have good ideas can work a little harder to impelement them, while people who are just lazy (and would have created inconsistant rather than innovative interfaces otherwise) can just use the default. For desktop OSs, its probably good to dictate policy this way because people really don't want inconsistancy without really tangible benifets.
the size of an object on a 15 inch screen is the same as its size on paper, which is the size of an object on the big viewscreen at NASA...users would be compelled to use the highest resolution/color depth possible for the visual quality rather than for the space on their desktop.
Thank you very much for deciding that for me. Maybe I want to free up screen real estate by switching to a higher resolution.
>>>>>>>>
Dude, its called a third generation graphics layer. Anything that uses virtual coordinates has this "problem." If you want to do it differently, just change the mapping (its very easy in OpenGL).
OK, maybe that's overstating the case a bit.
>>>>>>>
What case
The point remains, though, that they have strong assumed that there's one "right way" to do things. Even Windows lets you specify lots of things in either pixels or inches (or centimeters, maybe - I don't remember).
>>>>>>>>>
If its in inches, its the same thing as using virtual coordinates. Pixels are an ancient relic that really need to be discarded. Font-sensitive GUI layout libraries all the way baby.
As it turns out very few applications take advantage of that, but at least they have the choice instead of being told which method to use.
>>>>>>>>>>
And if an app really does have the need to change a default, they can do it, they just have to do a little more work. You really have to ask yourself, does my app really need to make something 3.1" when 3.0" is the default? If it does, then go ahead and override the defaults. If it doesn't, just go with the flow. In a system that doesn't impelment some policy, you have people using 3.5" and 3.52" 9cm, just because the developer liked it better, not because of any real merit. The mere fact that most people consider KDE and GNOME to be functionaly equal attests to the fact that (in that case) competition doesn't make things better, just different.
you've just blown a whole lot of clock-cycles on nothing
>>>>>>>>>>
A) First, all the gee-wiz features in MacOS-X and the new Linux WMs (except EVAS) are software accelerated. THAT'S slow.
B) This is hardware accelerated, courtesy of OpenGL. Transparency, for example, is painful in 2D cards (since its done in software) but OpenGL cards are built to handle this. Trust me, if a run of the mill TNT-1 can handle Carmack's love creations, it'll have no trouble handling a simple (or complex) desktop.
Another thing you forgot. OpenML is quite heavily tied to OpenGL, so a server that uses OpenGL for display will have a leg up in integrating ML's functionality into the system.
1. You mention in your FAQ that a developer can use a wrapper around QT and GTK+ - nice idea, but what about Motif stuff? wrapper around those also? same for TCL/TK, FLTK, and native xlib stuff? This will make everything VERY slow..
>>>>>>>>>>
Sorry to break this to ya, but Qt, GTK+, etc are essentially just wrappers around X anyway. Its not fast the way it is NOW.
IIRC, XFS does that too. In theory the same is possible with NTFS too, but MS chose not to implement it.
Trident chips suck anyway? The people who buy notebooks with the CyberBlade chip probably won't even notice that its unaccelerated!
Sorry for the two replies, but I had to point this out. I don't like Linux's tendency to use multiple processes instead of threads. Whenever you switch processes, you have to change memory maps, frag your TLB, blow some cache, and it just gets nasty in general. Heavly multi-processed code is almost exactly equivilent to multi-threaded code, so I don't know what the justification is for using one over the other. The only thing multiple-processes buys you is protection from your own threads. And Linux has some pretty good threading code, so its not lack of support in the platform.
Probably because BeOS made the biggest noise about low latency audio support.
:) 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.
>>>>
But more likely because it has audio latencies a order of magnitude lower than stock Linux and Windows.
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
>>>>>>>>
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. That's why I said it was a crapshot. And I know that 2.5 is getting lots of latency work, that's why I stated in my original post that Linux WILL become the ultimate media OS. Its just not there right now.
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.
>>>>>>>
Only if all you're doing is shoving bitmaps at the screen. The actual drawing code CAN run in parallel. Let me explain this to you. Say you start drawing a line. The line algorithm steps along the line and starts writing the pixels to video RAM. Halfway through, you're thread gets preempted and another graphics thread starts running. If there is a global lock on the drawing code, then that thread will block until the first thread finishes drawing. On the other hand, if everything is correctly parallized, that second thread can keep on writing to memory without interfering with the other thread. Also, the blitter can be shared as well. True, there is one blitter, but it is one hellishly fast blitter. On my DirectX tests, the RivaTNT's blitter can blit more than 30,000 small bitmaps per second. Thus, it can blit a bitmap once every 33 usecs. Also, the blitter can queue up blits. That leads to the following scenario: say a process locks GDK, issues a series of blits, then unlocks it. During this process, it is preempted by another drawing thread. By the time the system has done a context switch, most of the blits will be done. If they aren't, the thread can still issue more blits to be queued. If there is a global lock, however, the second thread will sleep, and by the time the system gets around the scheduling the first thread again, all of the blits would have completed long ago. In a parallel system, the second thread's blits also would have been queued and completed. In a serial system, only the first thread's blits would have been finished. The idea of keeping the I/O hardware as busy as possible is an important one in OS design. 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.
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.
>>>>>>>>>>
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. But I'd have to look at performance data to be sure.
Its more dishonest to try to make it seem like a chip has a higher clockspeed than it does. I'm not defending Intel, but their behavior doesn't make AMD's OK. At least Cyrix used PR number upfront by calling them MII PR300s. AMD isn't even going the PR route.
Yea, but thats misleading. The PCxxx spec denotes clockspeed, not bandwidth. Calling it PC2100 makes it seem 21 times faster than PC100 RAM, and almost three times as fast as PC800. Intel doesn't claim to have PC-3200 RDRAM in its P4 computers, even though the P4's memory banks have 3.2 GB/sec of bandwidth.
I don't get your arguement that BeOS isn't superior to Linux for media. 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. True, the low-latency kernels do get far lower latencies than BeOS these days, but they still aren't part of the main tree, and thus aren't available to many people. 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.
:) 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 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.
>>>>>>>>
What about drawing to multiple views? If GTK has a single global lock, doing GTK+ operations on one window will lock out those doing operations in another window. 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.
Oh dear, I should wipe my stolen copy quickly then!
>>>>>
That's not my point. My point is that it hasn't been released, it isn't in any distros, and is thus not really usable yet. Even after its release, it will be awhile before many apps take advantage of its features.
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.
>>>>>>>
I don't really think that its is really the multi-threaded nature of BeOS that stifled application development. Windows 2000 uses threads even more agressively than BeOS (right now, with 2 IE Windows, two explorer Windows, and MS Word running, I have 273 total threads, maybe 100 that don't sleep all the time), and it has a ton of mature software. MS word uses half a dozen threads with one document open. IE uses 32 threads for its two windows, and there are over 30 system threads running. And Win2K can hardly be called an unstable environment. And Word 97, Visual Studio, and IE-6 are all sold, mature, complex programs that are EXTREMELY responsive to the user. I'm not dumb enough to think that more threads are necessarily better, I'm just pointing out that complex multithreaded environments ARE possible and they CAN be stable.
Anyway, JBQ makes a good point: it is hard to
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.
>>>>>>>
Yes, this dropped message thing is troubling. But it has yet to pop up in actual usage and if BeOS development had continued it could presumably be fixed. QNX is totally message based, and I really doubt you'd trust a nuclear reactor to an inherently flawed model.
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 [alsaplayer.org] has been churning through a 3000 entries long playlist for 2 straight days now, rock solid
>>>>>>>
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.
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
>>>>>>>>
Yea I read it.
Uh, no. PC800 transfers at 1600 MB/sec. Its clocked at 400MHz base * 2x DDR * 2 bytes per transfer = 1600 MB/sec. And yes, its honest to report DDR busses as being double the megahertz because they mostly behave that way. Thus, PC-2100 really is DDR-266.
Its creepy that Intel seems like the honest platform now. A P4 2000 is actualy 2GHz. PC800 RDRAM is actually 800Mhz. But calling an Athlon 1.4 an Athlon 1600 is almost as bad as calling 266 DDR SDRAM PC2100!
No, since you aren't claiming that its a 1600MHz chip, just calling it an Athlon 1600. Same thing as the old PR ratings.
Its been ported to PPC and Alpha, so why not SPARC?
Except not really. BFS is very well documented, and some of its code actually appears in Giampalo's fskit. Plus, all of the data structures are cleanly laid out, so implementing a clone (eg. AFS) is very straightforward.
Practical File System Design by Dominic Giampalo.
Great book, has a detailed overview of the BeOS structure, some comparisons and explanations of other filesystems (like ext2, NTFS, XFS, and HFS+), and a cool file system builder kit with full source to pretty nifty example filesystem.
Sure, list them.
:)
>>>>
I already have, in my previous post.
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." I make no arguement that Be the company is pretty dead, but I'm not talking about success. I'm talking about the technical quality of the OS.
The only apps that really benefit from threads are media applications and most, if not all of them do use threads.
>>>>>>
That's not really true. Many applications can benifet from threads, it just requires a different style of programming. People said the same thing about OO programming until they realized that the main problem was that too many people were too set in their procedural ways. I've programmed with threads ever since I left high school comp-sci, and it really isn't that hard. Its more difficult to debug, true, but not appreciably, if the app is coded in a multi-threaded way to begin with.
GTK+ 1.2.x is already thread safe. Qt 3.0 is too.
>>>>>>>
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. As for Qt 3.0, it hasn't been released yet, so it is of no consequence at the moment.
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
>>>>>>>>.
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. Plus, it is a big boon to those with SMP machines (getting more and more common) if an OS's application base is extensively threaded.
That's wasn't in the forum, it was attached to a story. Anyway, JBQ makes a good point: it is hard to port non-threaded software to a threaded environment. But that's not the issue here. BeOS was designed to get rid of a lot of baggage, and unnecessarily single-threaded software was one of those pieces of luggage. I've been a BeOS user for several years, and the apps have been extremely stable, multi-threading or not. People who have developed native BeOS applications have pointed out that it is easy once you understand it. I'm not trying to claim that threading is a silver bullet that will solve everything. However, it is a technique that has many advantages, especially for SMP machines, that that technique is often ignored by software developers who are too scared to architecture their programs differently.
Yes, but they are largely useless. In every RPM-based system I've ever used, you're almost forced to install programs with --nodeps. This is due to its stupid dependency setup that checks not for file dependencies, but package dependencies. This becomes a major headache if you, for example, install something like X by compiling it. It is difficult to express these more advanced features of RPM in a GUI that is also easy to understand.
Actually, it might be possible to use BeOS's indexing system to implement something like this, although I don't know how hierarchical stuff like typenames are.
That's true, but you're thinking too much in a windows-oriented way.
/usr/X11R6/bin, theiur libraries to /usr/X11R6/lib and their documentation to /usr/man for the manpages and /usr/share/doc for the readme, changelog and extended documentation. I used to dislike it too, but only because I was used to the windows system. It's far more logical if different types of files end up in pre-determined locations, so you never have to go hunting around your disk when you want something specific.
/usr/bin or /usr/lib. It requires too much central control (the Debian guys have to make sure that nothing conflicts) and is too prone to losing files. What happens if namespaces conflict? What happens if you rename a file (or more usually, a symlink). All of these things result in uneeded files being left around. It gets even worse with compiled software (which is often necessary, if you tend to keep up with the latest releases). There is virtually no way to uninstall compiled software without resorting to using something like encap.
>>>>>>
I hate to say this, but the Windows way is the right way, in this case.
In windows, you need to tell where to place software because the drive letter filing system forces you.
>>>>>>
It's not the drive letter filing system. For most configurations, Linux's and Window's filing systems are the exact same, except with different root directory names and different path seperators. Its not the FS, but the installation convention.
In linux, since everything is part of one big file tree it's easier to differentiate file types in different directories.
>>>>>>
But people don't think in terms of filetypes, they think in terms of applications.
For example, in debian, most application's binaries will go to
>>>>>>>
Its more logical if you're a computer, but less so if you're a human being. If I want documentation for program FooBar, I think about the program first, then what I want to do with it. Its the whole concept of object orientation. Its not find_readme(programName), but programName->FindReadme().
The whole UNIX filing system is seriously screwed up. With todays software applications with their dozens of files, it goes against the whole hierarchy convention to just jam everything into
To be honest, I can't understand why the debian and debian-derived distro's are the only ones using apt-get. It's so much better than windows and slightly better than rpm (since dpkg is the equivalent for rpm, but what is the rpm equivalent for apt-get?).
>>>>>>>
urpmi.
Let me use NeXT as the ideal app management system. All apps are self contained in bundles. Installing the app involves putting a bundle in the appropriate directory. Uninstalling the app involves deleting the bundle. Simple, clean, and extremely flexible.
Uh, no. Clicking setup.exe works 90% of the time under Windows. 90% of the time under Linux, rpm -i koffice*.rpm gives you an errror message saying you need to install some other RPM. Then you have the fact that circular dependencies can only be resolved by putting both RPMs on the same command line. Then... then you have a user who just wiped Linux and reinstalled Windows...
Even when it works, typing rpm-i koffice*.rpm requires breaking out an xterm, cd'ing to the right directory, and typing the comman. You've already lost a whole lot of users right at 'xterm'.
Great job on making the /. URL reporting absolutely useless. Avoid this link, its like goatse.cx.
Well, if you can stand X, more power to you. Maybe your fast hardware masks it, or you just aren't as twitchy as I am ;)
Yes, KDE2
Maybe because IE is loaded by the OS when the computer starts? As for Word staring that quickly, that's total BS (at least on my machine).
>>>>>>>>
Even when you have started the app previously (which means that Linux will cache the image), all KDE-2 apps still take several seconds to load. I know that this isn't a problem with Linux, since most Athena apps of comparable functionality take much less time to load. As for Word, I don't know how your machine is configured, but mine is a nicely tweeked Win2K machine running on a PII-300 with 256MB of RAM. I have all the stupid graphical features turned off, I have harddrive indexing turned off, and I've done the standard little tweeks. Word (97, but 2000 isn't much slower, and Word 97 still beats KWord in functionality) starts up in a second or two. After having loaded it once, starting up is instantaneous.
With both my GeForce II and Radeon (the Radeon generally locks up within 10 minutes or so under W2K, too).
>>>>>>>>>
Hmm, did you update the graphics drivers for both? Win2K is really finicky about bad drivers. Do you have DMA disabled? Win2K doesn't like the SiS 630's IDE controller. Do you have lots of things running in your system tray? Win2K is faster than KDE-2 for a whole lot of people, so its not just my config.