As one of the NorthPoint customers, I can say that this genuinely sucks ass. I live in Mclean, and I have 416K SDSL service from NorthPoint. First, I get consistant 48K downloads, at all times of the day. Second, I have a 100ms ping to almost every (fast) server you'd care to name (/., of course, times out on every ping test;) Lastly, its SDSL service, so its like having a miniature T1 in your house. All this for $50 a month (DSL is *damn* expensive around here!) If NorthPoint is going out of business, I'm screwed. I either have to deal with Covad (sucks ass) or Verizon (sucks even more ass). The good companys never do make it, do they?
Doh! That's almost the definition of proprietory! You have to buy hardware from them and only them. I, for one, hate the fact taht you have to buy Macs premade. If I haven't built it myself, I don't want it under my desk.
BeOS runs on Intel too, and it has hte simplest installation known to man. Sure it doesn't support as much HW as Linux, but its installation complexity isn't proporitonal to its hardware support. Linux just does a lot of things wrong from the install/configuration standpoint. First, there is no standard method of adding hardware and drivers. Kudzu-like programs mitigate some of this, but they constrain the user into using a very specific software set. Second, the OS doesn't automatically autoconfigure anything. I'm not saying the user shouldn't be able to do it, I'm saying the user shouldn't HAVE to do it. Third, it manages resources all funny. Every other OS I've ever used can assign IRQs and DMAs and memory ranges without problems, but with Linux, I have to know these details to configure my sound card. Unlike OS-X, there are not standard methods of doing configuration files on Linux. Each one is different. It doesn't take much to create a standard method for something like this. All you need to do is provide a standard method accessible from the system API. Most developers will just use the built-in services, and not bother to hack their own config format. This way, all files that can use the standard format (XML) do use the standard format. Forth, documentation is lacking. I love the UNIX concept of man pages, why doesn't Linux do this anymore? In Linux documentation is split between man pages, info pages, README's, and web-sites. I think Linux should live up to its UNIX heritage and unify its documentation. Man is probably too limited, but the numerous schemes based on XML seem promising. (BTW, include it standard in every distro. Why did man pages become so universal? Because the OS had out-of-box support for them!) I could go on, but I have a feeling I'm repeating myself...
although this poster is largly incorrect, he has a point. AMD is releasing a product called LDT (or, sigh, HyperTransport... dumb names... Athlon my ass, it's a K7) which will offer a 6.4 GB/sec point-to-point bus. While Intel seems to have something similar in the pipeline, AMD's solution is much farther along.
Why do I see this every time a new procesor comes out. Not everyone runs a freaking web-server! Some things fit entirely into memory (especially with SDRAM so cheap!) and the faster processor scales performance quite linierly. Given that mature DDR-SDRAM and RDRAM chipsets are just around the corner, the I/O arguement really doesn't make sense for a lot of uses anymore. For example, I do 3D. I'd much rather have a 20% faster processor than a 200% faster PCI bus.
Sure. Mathematical proofs are VERY biased to those who are verball oriented. I, for one, can easily get a concept if you put it into words, but big equations just fly over my head like so much wind. Besides, bias is built into the very fabric of perception. Name something that *isn't* biased.
I don't know about you, but (aside from when I was writing a kernel driver) Linux (X actually, but since I use the GUI, its all the same) has crashed on me more often than BeOS. Not to mention that it hosed ext2 twice... BeOS is probably a little less stable than Linux, but I only reboot my machine once every few weeks and neither OS crashes on me. As I said, net_server is pretty unstable, but that's why its being replaced.
You're making the fundemental mistake that power and ease of use are inversely proportional. That's simply false. Take 3D Studio for example. It is quite easy to use but is insanely powerful. Same thing with BeOS (yea, get off/. stupid BeOS user, I know...) It has nice GUI applets for every config item. Its consistant. Everything is organized. Does that mean its not powerful? Hell no! Sure its got a great GUI, but its CLI is equal to that of Linux, because its GNU (what isn't bundled already is in the GeekGadgets distro.) Sure it has GUI config tools, but beneath them are.... TEXT FILES! (Mostly, some apps use binary files, but most of the OS uses text files.) It's get/etc,/etc/services, profile, you name it. Sure it autodetects all your hardware, but what's this? An applet that allows you to modify all your resources... from ONE place? How un-UNIX-ish (tongue in cheek). Sure it autoloads all drivers, but wait, changing drivers simply involves moving the correct one into a particular directory! Don't like the USB driver? Just write your own and replace the binary! You can also write custom filters and modules to extend the server. Don't like pushing CTRL-FX to change workspaces? Just write a filter to map it to CTRL-ALT-HOME-INSERT-PageUp-Shift-2! Then there is the messaging system. I can have programs that map keys to system messages. Go ahead and write an Apache add-on that allows you to change the max number of connections by press SHIFT+ and SHIFT-. Or, you can write a C++ program that sets a watch on a directory and messages a Python scripts that sends the message over the network to an app that tells you that your mother just found your porn collection. Now *that's* power. Still, its easier to use than Windows. Power and ease of use are not diametrically opposite. It simply takes a lot of good design to implement both.
Er, you're running Debian, known to be a distribution aimed at enthusiasts; yet you're complaining that it took some fiddling to get the sound card working.
>>>>>>>
It should be configured automatically in *every* distro enthusiast or not. I see no reason to make a distinction here. You autoconfig it, and provide the ability for the user to modify the settings. That way the regular user (or the enthusiast who doesn't give a flying fuck about his sound card's IRQs) can just use it, and the user who wants to micromange can change the settings. It doesn't decrease the power of the system, just makes it more polished. Hacked together (I'm not saying Debian is) and unpolished!=powerful. Polished and well put together!=not-powerful. An enthusiast likes using his computer and fiddling with it. However, I know few enthusiasts who want to fiddle just to get trival things like sound to work. *Real* enthusiasts want to get in and tweek code, make their system better, do something useful. *Real* enthusiasts don't like complexity for complexity's sake.
I just love/. Nobody understands the concept of the "middle way." 100% diversity is bad. 100% uniformity is bad. The ideal blend lies somewhere inbetween. The Windows OpenGL model is actually a very good illustration of RightWay(TM). In Windows, each vendor provides an implementation of a service, and each app writes to a particular OpenGL API (be it in C/C++, Delphi, VisualBasic, Java, or whatever.) The thing that ties them together is the common OpenGL ABI. Thus, one can switch from the ATI OpenGL implementation (OpenGL drivers implement the entire pipeline, from app-level functions on down) can be easily replaced with NVIDIA's one, and (barring extension incompatibilities) every Java, VB, Delphi and C++ app will continue working unaffected. This is exactly the model that should be used for GUI toolkits. There should be one ABI that all apps write to. Thus, the application developer can choose the API (I'm distinguishing the two: API is source level, ABI is binary level) they want, and the user can choose the implementation they like. Competition is perserved, app developers get a good amount of freedom, and the user is allowed to make their own decisions while retaining a consistant environment. Originally, X did something a bit like this. You could switch window managers around, and all apps would work fine. Its only because they made a miscalculation in the features necessary in the server to support this idea that it isn't true anymore.
A) BeOS doesn't yet have networking in the kernel. Even with BONE, its microkernel-nature isn't effected too much since microkernels that do networking in userspace (such us QNX4 which, contrary to my previous post, does indeed do networking in userspace) use highly-optimized shared-memory paths to communicate with the kernel. These paths are much easier to corrupt and thus cause crashes than normal messaging interfaces. Besides, BeOS (and arguably NT) is more of a microkernel than NeXT, OSX, or whatever. Mach or not, they use a single system server, which gets rid of a lot of the benifets of the microkernel design. As for USB devices, how does that make it not a microkernel? Its a bus just like the ATA or PCI busses, and I have yet to see anybody propose to do PCI outside the kernel.
That ain't no micokernel.
>>>>>>>>>
That might sully its definition as a "true" microkernel, but I'd argue that BeOS is more of a microkernel OS where it counts than any other Mach-based OS, except maybe HURD. First, many microkernel OSs have networking integrated, I believe QNX4 had it in the kernel. Second, Most Mach based OSs use a monolithic system server, which throws many of the benifets of a microkernel OS out the window. In BeOS, for example, if the net_server crashes, it can be restarted without too much trouble. If networking in the BSD system server crashes, then the OS is down the tube anyway.
X is here today, it works, it is improving, and it allows you to write your application however you want (even if it is the wrong way to approach the problem)
>>>>>>>>>>>>
Who says this is a good thing? I'm both a developer and a user, and both sides of me say that the user is king.
First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new
toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows."
>>>>>>>>>>
Have you gone mad? That's like X11! You are empowering the developer instead of the user. By keeping "buttons" and "menus" and "clients" on the server side, it makes it much easier for users to make apps conform to their preferences, not those of random application developers.
I think he means more of a "meta-API." Not an API for apps, but an API for widget sets. That way the user gets to decide which widget set to use, not the application developers.
I too wish that BeOS would be open sourced. It would guarentee the existance of the platform. However, I believe it is not possible because several parts of the OS contain licensed code and I doubt Be has the available man-power to clean it up.
It was worth the wait, seeing it is totally royalty free! BeOS simply licensed their font engine from someone else (Bitstream?), which means that theoretically Be looses money on each free BeOS copy downloaded. Wonder how long they can sustain it...
>>>>>>>>>>>
Its called a one-time license fee.
Oh, so we throw away X and just re-invent it again?
>>>>>>>>>
That's funny. If you juxtapose your Athena comments and this one, you realize that in the first, you say its perfectly fine to abandon compatibility, and in the second, you condem the idea. Besides, throwing away X would not entail reinventing it again. X is not the be-all-end-all of windowing systems; better stuff can (and has) been invented.
Please! X development might have been dormant a couple
of years ago, but man, it's going places today!
>>>>>>>
Wow! AA text!
I'm sick and tired of hearing how X is bloated and stuff.
>>>>>>
And I bet Windows users are tired of the same. That doesn't make it any less true...
My Linux X desktop with NVidia hardware is *FASTER* than anything BeOS can come up with
>>>>>>>>>>
Oh please. I was doing a quick test the other day to determine how different data set sizes affected processor intensive (matrix multiplies) code. At one point I used a small data set an an insane number of repititions. The processor was absolutely pegged because everything was being handled by the caches and my thread was using 100% of CPU time. Even then, I could open netpositive and browse reasonably comfortably (faster than most of the pre 0.8 Mozilla releases anyway.) Suffice it to say that GNOME starts flickering and jerking like hell under the same test. Not to mention the fact that KDE 2.1 (feature parity! can't use blackbox for these tests) is slower than even NT 4.0.
(oops,
that was a low blow, sorry, OpenGL beta10 should be here anyday now right?)
With RENDER becoming more widespread by the day you can bet your ass anti-aliasing will
become more pervasive
>>>>>>>>>>>>>.
Maybe it will be pervasive by the time beta10 comes out? Listen to yourself! You're your own worst enemy!
Tell you what, you come up with free windowing system in the next year that allows me to run a web browser
on a box that's half a world away, then lets talk about replacing X. Also, think about the following
>>>>>>>
Question: Who gives a damn about running a web-browser on a box half a world away. I'd rather have a 20% speed increase!
Software base. Make sure it's compatible with at least gtk+ and Qt.
>>>>>>>>>>>
Or Win32;)
Multi-monitor support. An X replacement would need to have this too. Good luck!
>>>>>>>>>>>
Wow! A feature first found in Windows 98! Congrats! Besides, other windowing systems (I believe photon, already have this too.)
For example, there
is no Xinerama like functionality in BeOS, and very unlikely to ever happen since a rewrite of the
app_server would be needed.
>>>>>>>>
Where did you hear this? The hooks are already in place for multiple monitor support, if you'd read the API. I'd say multiple monitor support would be much easier than multi-user, and somebody has already made a good bit of progress on that.
Replacing X with something better? Try it! The good folks from the Berlin-Consortium have been trying this
for years, without much success. I'd say time and energy would be much better spend optimizing the current X
architecture/drivers than to come up with a whole new system that will eventually be X.
>>>>>>>>>>>>>
Yes. X was handed down from god and all future windowing systems are desitned to be duplicates of it. Give me a break. Like I said, better stuff has already been done.
How does BeOS factor into this? Get past the name, please. Besides, the comment doesn't even make any sense! You're comparing an OS to a windowing system.
Person 1: "Well, if one were written for Windows and the other for Quarz, you couldn't even run them on the same screen!"
Person 2: Duh. What's your point?
Person 1: See, that was clever! I'm clever! I came up with a clever and comprehensible comment!
Person 2: Right...
Now, I'll explain my point. My point is that the first party (you) reccomended to the second party (me), that if the second party wanted consistancy on their desktop, then they should only use apps from one toolkit. This the second party pointed out to the first party that two of the best apps on Linux were written for different toolkits, and thus the second party was forced to exchange RAM and consistancy (consistancy is VERY precious to the second party, as anyone whose seen his directory structure can attest to) and application quality. The first party then made a snide comment about BeOS, and told the first party to use both toolkits, thus creating a paradox with the first party's original statement, and the first party was immediatly sucked into the abyss of non-sensicalness.
Everytime X is mentioned, the UNIX grognards come out of the woodwork. All through the halls of/., shouts of "compatibility!" "network transpareny!" "maturity!" "flexibility!" "extensibility!" and "X only sucks a little bit!" resound. Every comment I've seen seems to be from people who are so attached to their antiquated way of doing things that they cannot handle the mind-expanding notion that maybe, just maybe, the best GUI has yet to be designed. Let's just iterate (or maybe recurse?) through some of their misgivings about replacing X.
Compatibility: If I cared all that much about compatibility, I'd still be using Windows. 'Nuff said.
Network transparency: This is a half-decent point. However, Berlin does network transparency as well, so it is a moot point anyway. The truth is, other windowing systems do network transparency, and some better than X. If you don't believe me, read the docs on QNet and QNX's Photon. Whoa, somebody actualy DID come up with something better than X!
Maturity: I don't know how to explain this to the grognards. Let me put it this way. I love my grandparents. I want to learn from my grandparent's vast life-experience. However, there is no way in hell I'd be caught dead dressing like them. Even with a cap on backwards, a tweed coat is a tweed coat. The same thing holds true for software. 30 year old software, just like 30 year old people (no offense to those of you that far over the hill;) should be replaced. People say, "we shouldn't reinvent the wheel." The first wheel was made of wood roughly hacked together. Now we have high-tech rubber-wrapped precision wheels. I'd say wew've done a fair bit of reinventing. Besides, a better analogy is the cart. The cart did its job of getting stuff from place to place. Then came carriages, and while they were based upon carts, they suddenly had the new capability of ferrying people around! After that, we invented cars (with some steps in between;) and while the car is an extension of the carriage, it is a radically different beast and enables people to do things like go across the country. Then we invented planes (which use wheels as well!) which make international travel easy, at least as long as you're not booked on United. While the airplane too is an extension of the cart, it is a radically different idea that makes new things possible. A more technology example is UVM. I keep reading bits about how BSD VM is so great because it is a mature codebase that is the product of years of development. Then I read the thesis paper on UVM, and I find that this "green" piece of software blows BSD-VM out of the water. Looking at mature methods to implement your software is good. Deluding yourself into believing that everything good in computer science had been invented by 1980 is bad. The lesson of all this is that we must learn from the past and we must build upon the past. We should not, however simply modify the past.
Flexibility: Flexibility is over-rated. No, its true. X had to make some tough design decisions, and it chose to make things more flexibile rather than better. While a certain amount of flexibility is necessary, software should be designed with two goals in mind: Providing the absolute best experience for the next ten years (a generation in software-time) and providing some sort of migration path to the next level. While X, due to its flexible nature, has survived the last decade and a half, it is not, in its current form, able to keep up with its younger competitors.
I strongly agree with this. People who want to replace X generally don't understand X. X is far and away the most powerful and flexible windowing system available on any
computing platform today.
>>>>>>>>>>>
Let's see. Quartz provides a better imaging system. GDI provides a better acceleration system and more features. QNX Photon provides better network transparency. BeOS provides a better API. They are all faster ('cept maybe Quartz) than X. How can you rationalize calling it the "most poweful and flexible windowing system available on any computer platform today" when that statement is an outright lie?
Which is exactly why all Windows apps look different and use a different set of core services? That's bullshit. Developers are lazy. Provide them with a good-feature set to start out with, and most won't stray from the toolkit unless there is a damn good reason to. Besides, users (in general) hate apps that don't "fit-in" with their desktops, which provides additional incentive for developres (at least those you give a damn about their users) to work within an existing framework.
Well, that's entirely your choice. If that's what you want, only use programs that have those features and don't mix-and-match toolkits.
>>>>>>>>>>>>>>
GIMP is the best Linux image editor. KDevelop is the best Linux IDE. Reconcile that Lusenix boy.
You've got to remember when X was designed. In the 80's, while anti-aliasing did exist, computers really
didn't have the processing power to use it comfortably
>>>>>>>>>>>>>>
It doesn't matter. If X can't be extended to support AA in the core protocol, it means the core protocol was badly designed. It is a matter of high-level vs. low-level, but the truth is, that X is not extendible at all. If Be (or QSSL or MS) had infinate man-power, they could extend their GUI tomorrow to use fully hardware accelerated display PDF technology running on a remote server in Alaska. After the change, 95% of all apps would still work perfectly (given a fiber-optic connection to Alaska, of course;) If you look at their repsective API's, you'll see why. For BeOS and QNX, the app interacts with the GUI at the widget level, which gives these OSs that kind of flexibility. X, however, can't even do anti-aliasing without extensions. (As an aside, extensions should only be used when the core-protocol absolutely cannot accomodate the changes. Adding to the core protocol allows all apps to automatically take advantage of new features, and makes new technology transparent to developers. Extensions exist only for extreme cases, something too few people realize.) That is a fundemental flaw in its low-level nature. There are many ways to design a windowing system, and the abstraction-level of that windowing system lies on a gradient. When you move in one direction on that gradient, you gain some features and you lose some features. The trick is to strike the correct balance between these features, something I believe X did not do.
Slashdot Mirror
Actually, you got to give MSN their due. Their termination plan was pretty high-class.
As one of the NorthPoint customers, I can say that this genuinely sucks ass. I live in Mclean, and I have 416K SDSL service from NorthPoint. First, I get consistant 48K downloads, at all times of the day. Second, I have a 100ms ping to almost every (fast) server you'd care to name (/., of course, times out on every ping test ;) Lastly, its SDSL service, so its like having a miniature T1 in your house. All this for $50 a month (DSL is *damn* expensive around here!) If NorthPoint is going out of business, I'm screwed. I either have to deal with Covad (sucks ass) or Verizon (sucks even more ass). The good companys never do make it, do they?
Doh! That's almost the definition of proprietory! You have to buy hardware from them and only them. I, for one, hate the fact taht you have to buy Macs premade. If I haven't built it myself, I don't want it under my desk.
I believe most Macs ship with the ROM on the harddrive. Besides, who cars about ROM size?
BeOS runs on Intel too, and it has hte simplest installation known to man. Sure it doesn't support as much HW as Linux, but its installation complexity isn't proporitonal to its hardware support. Linux just does a lot of things wrong from the install/configuration standpoint. First, there is no standard method of adding hardware and drivers. Kudzu-like programs mitigate some of this, but they constrain the user into using a very specific software set. Second, the OS doesn't automatically autoconfigure anything. I'm not saying the user shouldn't be able to do it, I'm saying the user shouldn't HAVE to do it. Third, it manages resources all funny. Every other OS I've ever used can assign IRQs and DMAs and memory ranges without problems, but with Linux, I have to know these details to configure my sound card. Unlike OS-X, there are not standard methods of doing configuration files on Linux. Each one is different. It doesn't take much to create a standard method for something like this. All you need to do is provide a standard method accessible from the system API. Most developers will just use the built-in services, and not bother to hack their own config format. This way, all files that can use the standard format (XML) do use the standard format. Forth, documentation is lacking. I love the UNIX concept of man pages, why doesn't Linux do this anymore? In Linux documentation is split between man pages, info pages, README's, and web-sites. I think Linux should live up to its UNIX heritage and unify its documentation. Man is probably too limited, but the numerous schemes based on XML seem promising. (BTW, include it standard in every distro. Why did man pages become so universal? Because the OS had out-of-box support for them!) I could go on, but I have a feeling I'm repeating myself...
although this poster is largly incorrect, he has a point. AMD is releasing a product called LDT (or, sigh, HyperTransport... dumb names... Athlon my ass, it's a K7) which will offer a 6.4 GB/sec point-to-point bus. While Intel seems to have something similar in the pipeline, AMD's solution is much farther along.
Why do I see this every time a new procesor comes out. Not everyone runs a freaking web-server! Some things fit entirely into memory (especially with SDRAM so cheap!) and the faster processor scales performance quite linierly. Given that mature DDR-SDRAM and RDRAM chipsets are just around the corner, the I/O arguement really doesn't make sense for a lot of uses anymore. For example, I do 3D. I'd much rather have a 20% faster processor than a 200% faster PCI bus.
Sure. Mathematical proofs are VERY biased to those who are verball oriented. I, for one, can easily get a concept if you put it into words, but big equations just fly over my head like so much wind. Besides, bias is built into the very fabric of perception. Name something that *isn't* biased.
I don't know about you, but (aside from when I was writing a kernel driver) Linux (X actually, but since I use the GUI, its all the same) has crashed on me more often than BeOS. Not to mention that it hosed ext2 twice... BeOS is probably a little less stable than Linux, but I only reboot my machine once every few weeks and neither OS crashes on me. As I said, net_server is pretty unstable, but that's why its being replaced.
You're making the fundemental mistake that power and ease of use are inversely proportional. That's simply false. Take 3D Studio for example. It is quite easy to use but is insanely powerful. Same thing with BeOS (yea, get off /. stupid BeOS user, I know...) It has nice GUI applets for every config item. Its consistant. Everything is organized. Does that mean its not powerful? Hell no! Sure its got a great GUI, but its CLI is equal to that of Linux, because its GNU (what isn't bundled already is in the GeekGadgets distro.) Sure it has GUI config tools, but beneath them are .... TEXT FILES! (Mostly, some apps use binary files, but most of the OS uses text files.) It's get /etc, /etc/services, profile, you name it. Sure it autodetects all your hardware, but what's this? An applet that allows you to modify all your resources... from ONE place? How un-UNIX-ish (tongue in cheek). Sure it autoloads all drivers, but wait, changing drivers simply involves moving the correct one into a particular directory! Don't like the USB driver? Just write your own and replace the binary! You can also write custom filters and modules to extend the server. Don't like pushing CTRL-FX to change workspaces? Just write a filter to map it to CTRL-ALT-HOME-INSERT-PageUp-Shift-2! Then there is the messaging system. I can have programs that map keys to system messages. Go ahead and write an Apache add-on that allows you to change the max number of connections by press SHIFT+ and SHIFT-. Or, you can write a C++ program that sets a watch on a directory and messages a Python scripts that sends the message over the network to an app that tells you that your mother just found your porn collection. Now *that's* power. Still, its easier to use than Windows. Power and ease of use are not diametrically opposite. It simply takes a lot of good design to implement both.
Er, you're running Debian, known to be a distribution aimed at enthusiasts; yet you're complaining that it took some fiddling to get the sound card working.
>>>>>>>
It should be configured automatically in *every* distro enthusiast or not. I see no reason to make a distinction here. You autoconfig it, and provide the ability for the user to modify the settings. That way the regular user (or the enthusiast who doesn't give a flying fuck about his sound card's IRQs) can just use it, and the user who wants to micromange can change the settings. It doesn't decrease the power of the system, just makes it more polished. Hacked together (I'm not saying Debian is) and unpolished!=powerful. Polished and well put together!=not-powerful. An enthusiast likes using his computer and fiddling with it. However, I know few enthusiasts who want to fiddle just to get trival things like sound to work. *Real* enthusiasts want to get in and tweek code, make their system better, do something useful. *Real* enthusiasts don't like complexity for complexity's sake.
I just love /. Nobody understands the concept of the "middle way." 100% diversity is bad. 100% uniformity is bad. The ideal blend lies somewhere inbetween. The Windows OpenGL model is actually a very good illustration of RightWay(TM). In Windows, each vendor provides an implementation of a service, and each app writes to a particular OpenGL API (be it in C/C++, Delphi, VisualBasic, Java, or whatever.) The thing that ties them together is the common OpenGL ABI. Thus, one can switch from the ATI OpenGL implementation (OpenGL drivers implement the entire pipeline, from app-level functions on down) can be easily replaced with NVIDIA's one, and (barring extension incompatibilities) every Java, VB, Delphi and C++ app will continue working unaffected. This is exactly the model that should be used for GUI toolkits. There should be one ABI that all apps write to. Thus, the application developer can choose the API (I'm distinguishing the two: API is source level, ABI is binary level) they want, and the user can choose the implementation they like. Competition is perserved, app developers get a good amount of freedom, and the user is allowed to make their own decisions while retaining a consistant environment. Originally, X did something a bit like this. You could switch window managers around, and all apps would work fine. Its only because they made a miscalculation in the features necessary in the server to support this idea that it isn't true anymore.
A) BeOS doesn't yet have networking in the kernel. Even with BONE, its microkernel-nature isn't effected too much since microkernels that do networking in userspace (such us QNX4 which, contrary to my previous post, does indeed do networking in userspace) use highly-optimized shared-memory paths to communicate with the kernel. These paths are much easier to corrupt and thus cause crashes than normal messaging interfaces. Besides, BeOS (and arguably NT) is more of a microkernel than NeXT, OSX, or whatever. Mach or not, they use a single system server, which gets rid of a lot of the benifets of the microkernel design. As for USB devices, how does that make it not a microkernel? Its a bus just like the ATA or PCI busses, and I have yet to see anybody propose to do PCI outside the kernel.
BeOS has an IP stack in-kernel.
>>>>>
Not yet.
That ain't no micokernel.
>>>>>>>>>
That might sully its definition as a "true" microkernel, but I'd argue that BeOS is more of a microkernel OS where it counts than any other Mach-based OS, except maybe HURD. First, many microkernel OSs have networking integrated, I believe QNX4 had it in the kernel. Second, Most Mach based OSs use a monolithic system server, which throws many of the benifets of a microkernel OS out the window. In BeOS, for example, if the net_server crashes, it can be restarted without too much trouble. If networking in the BSD system server crashes, then the OS is down the tube anyway.
X is here today, it works, it is improving, and it allows you to write your application however you want (even if it is the wrong way to approach the problem)
>>>>>>>>>>>>
Who says this is a good thing? I'm both a developer and a user, and both sides of me say that the user is king.
First, we do not need another toolkit. We need an environment that makes it easy to write toolkits. If we have this, GTK and Qt will be ported quite quickly, and maybe new
toolkits simple enough to be programmed by mere mortals will appear.Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows."
>>>>>>>>>>
Have you gone mad? That's like X11! You are empowering the developer instead of the user. By keeping "buttons" and "menus" and "clients" on the server side, it makes it much easier for users to make apps conform to their preferences, not those of random application developers.
I think he means more of a "meta-API." Not an API for apps, but an API for widget sets. That way the user gets to decide which widget set to use, not the application developers.
I too wish that BeOS would be open sourced. It would guarentee the existance of the platform. However, I believe it is not possible because several parts of the OS contain licensed code and I doubt Be has the available man-power to clean it up.
It was worth the wait, seeing it is totally royalty free! BeOS simply licensed their font engine from someone else (Bitstream?), which means that theoretically Be looses money on each free BeOS copy downloaded. Wonder how long they can sustain it...
;)
>>>>>>>>>>>
Its called a one-time license fee.
Oh, so we throw away X and just re-invent it again?
>>>>>>>>>
That's funny. If you juxtapose your Athena comments and this one, you realize that in the first, you say its perfectly fine to abandon compatibility, and in the second, you condem the idea. Besides, throwing away X would not entail reinventing it again. X is not the be-all-end-all of windowing systems; better stuff can (and has) been invented.
Please! X development might have been dormant a couple
of years ago, but man, it's going places today!
>>>>>>>
Wow! AA text!
I'm sick and tired of hearing how X is bloated and stuff.
>>>>>>
And I bet Windows users are tired of the same. That doesn't make it any less true...
My Linux X desktop with NVidia hardware is *FASTER* than anything BeOS can come up with
>>>>>>>>>>
Oh please. I was doing a quick test the other day to determine how different data set sizes affected processor intensive (matrix multiplies) code. At one point I used a small data set an an insane number of repititions. The processor was absolutely pegged because everything was being handled by the caches and my thread was using 100% of CPU time. Even then, I could open netpositive and browse reasonably comfortably (faster than most of the pre 0.8 Mozilla releases anyway.) Suffice it to say that GNOME starts flickering and jerking like hell under the same test. Not to mention the fact that KDE 2.1 (feature parity! can't use blackbox for these tests) is slower than even NT 4.0.
(oops,
that was a low blow, sorry, OpenGL beta10 should be here anyday now right?)
With RENDER becoming more widespread by the day you can bet your ass anti-aliasing will
become more pervasive
>>>>>>>>>>>>>.
Maybe it will be pervasive by the time beta10 comes out? Listen to yourself! You're your own worst enemy!
Tell you what, you come up with free windowing system in the next year that allows me to run a web browser
on a box that's half a world away, then lets talk about replacing X. Also, think about the following
>>>>>>>
Question: Who gives a damn about running a web-browser on a box half a world away. I'd rather have a 20% speed increase!
Software base. Make sure it's compatible with at least gtk+ and Qt.
>>>>>>>>>>>
Or Win32
Multi-monitor support. An X replacement would need to have this too. Good luck!
>>>>>>>>>>>
Wow! A feature first found in Windows 98! Congrats! Besides, other windowing systems (I believe photon, already have this too.)
For example, there
is no Xinerama like functionality in BeOS, and very unlikely to ever happen since a rewrite of the
app_server would be needed.
>>>>>>>>
Where did you hear this? The hooks are already in place for multiple monitor support, if you'd read the API. I'd say multiple monitor support would be much easier than multi-user, and somebody has already made a good bit of progress on that.
Replacing X with something better? Try it! The good folks from the Berlin-Consortium have been trying this
for years, without much success. I'd say time and energy would be much better spend optimizing the current X
architecture/drivers than to come up with a whole new system that will eventually be X.
>>>>>>>>>>>>>
Yes. X was handed down from god and all future windowing systems are desitned to be duplicates of it. Give me a break. Like I said, better stuff has already been done.
How does BeOS factor into this? Get past the name, please. Besides, the comment doesn't even make any sense! You're comparing an OS to a windowing system.
Person 1: "Well, if one were written for Windows and the other for Quarz, you couldn't even run them on the same screen!"
Person 2: Duh. What's your point?
Person 1: See, that was clever! I'm clever! I came up with a clever and comprehensible comment!
Person 2: Right...
Now, I'll explain my point. My point is that the first party (you) reccomended to the second party (me), that if the second party wanted consistancy on their desktop, then they should only use apps from one toolkit. This the second party pointed out to the first party that two of the best apps on Linux were written for different toolkits, and thus the second party was forced to exchange RAM and consistancy (consistancy is VERY precious to the second party, as anyone whose seen his directory structure can attest to) and application quality. The first party then made a snide comment about BeOS, and told the first party to use both toolkits, thus creating a paradox with the first party's original statement, and the first party was immediatly sucked into the abyss of non-sensicalness.
Everytime X is mentioned, the UNIX grognards come out of the woodwork. All through the halls of
Compatibility: If I cared all that much about compatibility, I'd still be using Windows. 'Nuff said.
Network transparency: This is a half-decent point. However, Berlin does network transparency as well, so it is a moot point anyway. The truth is, other windowing systems do network transparency, and some better than X. If you don't believe me, read the docs on QNet and QNX's Photon. Whoa, somebody actualy DID come up with something better than X!
Maturity: I don't know how to explain this to the grognards. Let me put it this way. I love my grandparents. I want to learn from my grandparent's vast life-experience. However, there is no way in hell I'd be caught dead dressing like them. Even with a cap on backwards, a tweed coat is a tweed coat. The same thing holds true for software. 30 year old software, just like 30 year old people (no offense to those of you that far over the hill
Flexibility: Flexibility is over-rated. No, its true. X had to make some tough design decisions, and it chose to make things more flexibile rather than better. While a certain amount of flexibility is necessary, software should be designed with two goals in mind: Providing the absolute best experience for the next ten years (a generation in software-time) and providing some sort of migration path to the next level. While X, due to its flexible nature, has survived the last decade and a half, it is not, in its current form, able to keep up with its younger competitors.
I strongly agree with this. People who want to replace X generally don't understand X. X is far and away the most powerful and flexible windowing system available on any
computing platform today.
>>>>>>>>>>>
Let's see. Quartz provides a better imaging system. GDI provides a better acceleration system and more features. QNX Photon provides better network transparency. BeOS provides a better API. They are all faster ('cept maybe Quartz) than X. How can you rationalize calling it the "most poweful and flexible windowing system available on any computer platform today" when that statement is an outright lie?
Which is exactly why all Windows apps look different and use a different set of core services? That's bullshit. Developers are lazy. Provide them with a good-feature set to start out with, and most won't stray from the toolkit unless there is a damn good reason to. Besides, users (in general) hate apps that don't "fit-in" with their desktops, which provides additional incentive for developres (at least those you give a damn about their users) to work within an existing framework.
Well, that's entirely your choice. If that's what you want, only use programs that have those features and don't mix-and-match toolkits.
>>>>>>>>>>>>>>
GIMP is the best Linux image editor. KDevelop is the best Linux IDE. Reconcile that Lusenix boy.
You've got to remember when X was designed. In the 80's, while anti-aliasing did exist, computers really ;) If you look at their repsective API's, you'll see why. For BeOS and QNX, the app interacts with the GUI at the widget level, which gives these OSs that kind of flexibility. X, however, can't even do anti-aliasing without extensions. (As an aside, extensions should only be used when the core-protocol absolutely cannot accomodate the changes. Adding to the core protocol allows all apps to automatically take advantage of new features, and makes new technology transparent to developers. Extensions exist only for extreme cases, something too few people realize.) That is a fundemental flaw in its low-level nature. There are many ways to design a windowing system, and the abstraction-level of that windowing system lies on a gradient. When you move in one direction on that gradient, you gain some features and you lose some features. The trick is to strike the correct balance between these features, something I believe X did not do.
didn't have the processing power to use it comfortably
>>>>>>>>>>>>>>
It doesn't matter. If X can't be extended to support AA in the core protocol, it means the core protocol was badly designed. It is a matter of high-level vs. low-level, but the truth is, that X is not extendible at all. If Be (or QSSL or MS) had infinate man-power, they could extend their GUI tomorrow to use fully hardware accelerated display PDF technology running on a remote server in Alaska. After the change, 95% of all apps would still work perfectly (given a fiber-optic connection to Alaska, of course