Is it just me, or is the name not necessarily just superflous?
1) The P4 has very long pipes.
2) The P4 has small caches.
3) The P4 has huge bus bandwidth.
4) The regular FPU has been largely depreciated in favor of SSE2.
What does all this add up to? A chip to accelerate 3D. This feature list reads largely like the list of the Playstation 2. (Aside from the long pipelines thing.) You've got the small caches, high bandwidth, and the vector pipes. My guess is that Intel, seeing NVIDIA cramming more and more into the GPU, is trying to come back and troughly blow them out of the water. This chip might process slower per clock for many uses, but the high clock makes up for that. On the otherhand, things that are extermely regular without any branches (ahem, 3D geometry processing) will absolutely fly through this thing.
Probably less than a few percent. Consider the fact that almost all business machines are uni-proc, all consumer machines (except the DualG4) are uni-proc, the only SMP machines you have are (some) servers and workstation machines. The midrange-and-up (where you fund the bulk of multi-processor machines) and the server market are pretty tiny (in terms of machines shipped) than the consumer and business markets (I think the statistic is in the hundreds of millions of consumer machines shipped per year.)
AMD's profit margin is less than Intel's. If you've seen the kind of price decreases AMD has put up, you'll know why. You can get a 1GHz Thunderbird Athlon for around $650 on pricewatch.
I think you've confused the term "vaporware." Vaporware is stuff that doesn't show up. It is said to come out, but never does. Given the fact that RDRAM is shipping, and the P4 is close to shipping, you can hardly term them "vaporware." Vaporware has a much narrower definition than most/.ers realize. The Nintendo 64 magnetic drive was vaporware (it was called the 64DD, is it just me, or does read like a cup size?) The Matsushita M2 (another propose console using dual PPC 603e chips) was vaporware.
Okay, I can understand being happy when something like NVIDIA's OpenGL (which is very Windows oriented) performs nearly as well on Linux. However, does Linux Java being slower than Win32 Java "rock?"
Actually, it seems that bash shell scripts are probably a good place to start. For those who are a little more advanced, a form of BASIC is a good idea. There is a thing on BeBeOS called BeBasic that lets you make BeOS GUI apps in BASIC. Though I'm not quite sure you could consider basic that much easier than C, it is a pretty good way to let users who have good ideas, but not much programming practice contribute to the BeOS community.
It's cool. It's the same reason that GNOME uses CORBA for embedding. It's the same reason GNOME has it's own VFS layer. It's the same reason GNOME becomes a cross platform API on top of a cross platform API on top of a cross platform API. (GNOME on top of GTK on top of POSIX) It's the same reason Windows is riddled with feature bloat. It is simply not cool to have a simple product.
Considering all the bitching that's been going on with Qt vs. the GPL? I wouldn't be suprised if developers get a little scared, since they have to develop the equivilant of Qt +a WM to use PocketLinux in a product.
I was talking BeOS from a multi-threading point of view, not as an OS, but you asked for it.
On my home PC, the thing just didn't cooperate at all. It didn't pick up the Network card, (RealTek
809), there are no drivers for it, and it messed up the graphics quite badly. The mouse cursor looked
like a multicoloured block. I have an NVIDIA TNT2.
>>>>>>
The graphics card shouldn't be a problem. I've got a TNT and it works fine. Your experiance is a bit unusual though. In my case I have a RivaTNT, a EtherFast100TX and a EtherPCI II network card, and an AWE64 soundcard. Everything was detected the first time around, I just had to put in the settings for the network, download BeNat from bebits, and I was off. From install -> network NAT server/desktop machine was about 20 minutes.
And my sound card didn't work either. I guess
that can be fixed, but I can't connect to the network to download the driver...beh.
>>>>>>
Again, your experiance is a bit unusual. Usually, though, any problems you have you can ask the beusertalk mailing list.
Anyway, when I tested the thing on my work PC, I didn't find it useful for the "tasks" that BeOS
claims it should be good at, at all. Sure, I managed to play 10 MP3's at once, but contrary to popular
belief, it DID slow the system down.
>>>>>
What kind of system do you have? I can play 10 MP3s without even hitting 100% on the processor. Which is a little unusual though. 4.5 used to get up to 12 or 15 without pegging the processor. The trick is to not start them all at the same time, but one at a time. If you just highlight 10 MP3s and hit Open, Soundplayer goes crazy trying to load them all. And watch this. Start up 24 MP3's all at the same time. Under Windows or Linux, it's time to reboot. However, in BeOS, the system slows down, but is still usable to the point where you can easy open up some application to close the MP3s. Right now, I'm running 10MP3s, and I can still browse the 'net fine.
When I tried to play a video, a 600mb MPG from a CD (which
works under Windows), it didn't open it for some reason. It just refused to open large MPG files.
>>>>>>
Are they Sonorsen encoded? Also, the built in media player was troubles with MPEG files. Look on BeBits for a new one that's much smoother. Also, I have a CD with several large (10-25 megs) I can open 5 or 6 of them without hitting 100% on the processor.
Another area where BeOS falls over is management. Sure it's got Telnet and SSH has been ported,
but why the heck? I mean, you can't manage the thing remotely at all. The FTP servers and other
servers I downloaded relied heavily on the GUI to operate. That's pretty useless.
>>>>>>>
The BeOS wasn't designed as a server OS. Still, I don't see what the management problem is. BeOS has Apache, and you can telnet in go to/etc, or/boot/home/config, and most of the settings files are there in text format.
Also, it doesn't seem to have a decent browser. NetPositive was fast, but couldn't do 80% of the pages
on the Net properly. I downloaded Opera and when I when to a Java-enabled site, it crashed the
system - yes, crashed it. The version was 3.6(I think). The system slowed down completely at first,
btu I did manage to bring up a window and kill the process. However, even though the Opera
processes were killed, the system was still too slow to use and I had to reboot it.
>>>>>>>>
Yes Netpositive is weak. As for Opera, I think the version you used was 3.6-beta7. It's still a beta, and one that was abandoned. Still, I can use it fine without any problems. (Except Java sites, mainly because BeOS doesn't yet have a JavaVM! I'm wouldn't be suprised if they didn't bother to protect against a crash if the user loaded a Java site and the OS didn't have a VM, since this was a beta version.) However, Be is working on bringing Java2 and Opera 4.0 to BeOS. Promises? Maybe, just like widespread OpenGL on Linux?
It seems like the best thing about BeOS is the GNU bash, and we all know that's from the FSF and
can be found on many other OS's. BeOS fans like be-fan over here talk about great things, but deliver
very little. Overall, and I'm not trying to put Be down - Linux or FreeBSD are better choices for the
desktop.
>>>>>>
I have a triple-boot of Slackware 7.1, BeOS 5, and WindowsNT 4. I use BeOS maybe 75% of the time. I reboot into Windows to use Visual Studio, program DirectX, and use my 3D and imaging applications. I reboot into Linux to fiddle around trying to install ALSA, recompile the kernel, compile the latest build of KDE2 (since it is only in RPM and source) Right now, I'm waiting for a new version of kernel 2.4-test because 2.4-test6 seems to have broken the NVIDIA driver. Oh yea, this is a GREAT desktop OS.
I'm not just saying that as a user who's only used Windows, Linux and FreeBSD, but as one
who's used BeOS as well.
>>>>>>>>
Well, that's your opinon. From my POV, I think WindowsNT 4.0 is probably a better desktop OS than Linux, and certainly is the best PC OS available if your doing graphics. BeOS is a much nicer overall use OS than either. And BeOS probably also appeals to a broader range of people. If you the hardcore CLI-user, BeOS has Bash, POSIX, Perl, Python, Apache, and all those wonderful text-mode programs you've come to know and loathe (not to mention application scripting throgh hey). If your a Mac-type GUI user, BeOS is super-easy, and everything can be done from the GUI. If you're a Linux/X user, you'll be happy with how the GUI and the CLI really mesh together well.
BeOS has potential, but Be need to sort out the instability, the lack of applications, (including a
good Browser - I know you can get Mozilla for it, but you need to compile it yourself unless you want
to use M7), and their management issues, which, for me, are the biggest issues.
>>>>>>>>>>>
BeOS is far from unstable. I just don't see your situation that often. Sure, you had a bad experiance with BeOS. I'm sure a lot of people had had the same with Linux. As for me, and a lot of other BeOS users, the OS is fast, stable, innovate, and works great. It just seems that the "average BeOS" experiance is closer to mine, than yours.
Please stop the DirectX vs. OpenGL thing. It's Direct3D vs. OpenGL. If I get flamed every time I refer to the kernel as the OS, all people mistaking DirectX for Direct3D should get flamed. Back to the hardware features thing.
Here is adifference between Direct3D and OpenGL. Say 5 new cards support a new feature (say cubic environment mapping.) Now, the philosophy behind Direct3D is to get feedback from developers on what features they are putting in, and support as many of those as possible. Thus, cubic environment mapping is already supported in Direct3D. Since the card makers don't want to leave out Quake, they write 5 different extensions for cubic environment mapping. This is again due to the fact that OpenGL does everything by commitie (and a slow one at that.) So, in Direct3D's case, all cards that support a feature will accelerate any game that uses that features. In OpenGL's case, many new features (new as in less than 1 or 2 years old) will go unused until a standard extension is made for them. It is not only a features difference, but a difference in the way the API is built. And Direct3D does support features that haven't been IMPLEMENTED yet. This is another design goal of DirectX (in general.) MS puts in features in the API that no cards support yet. Now games can (usually) use those features because they will be emulated (it's actually slightly more complex than that, but I don't want to get into Direct3D programming). When card manufacturers DO implement this features in hardware, there will be a number of games that already take advantage of it. So, a card manufacturer can put in cubic environment mapping, a feature nobody else has, and games that use it will automatically be accelerated, even though no cards supported that feature when the game was written. This is another major difference between OpenGL and Direct3D. OpenGL doesn't get extensions to features that nobody has yet implemented. However, this is a very good thing, because if you spend your money to buy a card with this new feature, the games you have will automatically use it.
That's competition. This page was from TT, and it's there choice. Like all the Linux commercials making fun of BillG are in good taste? Lastly, it IS true. GNOME DOES have slower repaints than KDE.
I don't see it. Better support for DHTML? In some things maybe in others NOT.
>>>>>
Read the articles from all the guy lamenting that Netscape killed web-standards, not IE. IE supported HTML4.0 earlier and better, it still supports XML better (not better than Gecko though) it has always supported DHTML better (in more things than not) it still has the fastest JavaVM available, etc. It is faster loading, faster to render (I've got DSL, I notice the TCP/IP problems of the BeOS TCP stack) faster to scroll, you name it. It also takes less memory and crashes less often.
I use Office. Fast is not in its vocabulary. As far as Word better its a matter of opinion. I've seen
Office implemented in all types of business. The only sure thing is that the older version does not
support the newer versions files. You need to reinvest every 18 months, download patches
constantly. In most cases, people using Word are slower than poeple who use electronic typewriters.
It's no longer a productivity tool. The prefrences/options change from version to version, which has
led to millions using word but few who know how to. The default option on Word is never to create
a backup of the current file so when the system goes haywire and a restart of the system is
required(not to mention the blue screen.......) all is lost. Frankly I'm wondering after all this time you
would think reboot/restart would be history. I won't get into excel, with its large file problems.
>>>>>>>
Difficulty of use coming from a LINUX USER? Let's see, the last change of the Word file format was in 1997. I have only downloaded one patch for Office 97 (and some helper dudes) As for your other complaints, your complaining about defaults. It takes no time to switch to creating a backup file, and only slightly longer to relearn the menus. For people who uses this for their job, the changes amount to, oh, maybe a week of relearning. My dad just switched from Wordperfect to Word at his workplace. Complained maybe for a few days, after a week or two he is as proficiant as he was with Wordperfect. Despite all this, there is stuff that Office can do that StarOffice and Corel Office simply cannot.
Lastly, it is standard. Like it or not, no suite provides the sheer compatibility of Word.
You see the way I see compatibility/standard is for example the way we connect appliances to the
electrical outlets. We do not have to worry about who made the plug and who made the outlet. The
toaster plugs into the same outlet as the fridge, as the hairdryer, as the lamp, etc...... Now that is
COMPATIBILITY. When I use Linux, FreeBSD, OSS, I finaly see this compatibility. When I look at
TCP/IP, SMTP, etc.. I see this compatibility. When I look a MS Office I wonder if the plug will fit in
the most recent outlet or must I upgrade once again.
One last question...why must I reboot a system? Why can't I let it run? Why is a reboot productive. If
I were Micro$oft I would be ashamed.
>>>>>>>>
Compatibility is what resulted in the cobbled together mess that is the PC;) Seriously, though, what is this affinity to Open standards. A de-facto standard is nearly as good as an Open standard, and that is what word is. Think about this. Word is just as compatible as WordPerfect or star office. Why aren't you bitching about them. With WINElib Wordperfect Suite is just as bloated and unstable as Office (probably more so) StarOffice has a lot fewer features and is much slower. What's wrong with Office? Other Office apps (those available on Linux) don't behave at all differently from Office, so where's the beef? Nearly all office apps need patches, have incompatible file formats, changes in interface, etc. What's this vehamance against Word in particular? There are a lot of people who really NEED an Office suite, and Word is pretty much the best one around.
I've never, ever had to have multiple glibc versions running on a machine. Also, you only need the
base libraries for GNOME and KDE to actually run the apps - most of the stuff is only useful if
you're using the full desktop.
>>>>>>>
Are you running Netscape? On a glibc2.1.3 machine, you need compatibility libraries. As for the libraries, Qt is 2.5 megs, kdesupport is 3.5 meg kdelibs is 5 meg. That's 9 meg. Assuming the RPM format uses compression, you're talking around 15 megs of libraries.
Not in my experience. Obviously, this kind of article is just going to lead to a flame fest all around,
but I've run RH 6.1 on a 25 Mhz 486 with 16 megs of RAM - WITH X+KDE. And it wasn't noticalbly
slower than the Win 3.1 it replaced. Try running NT4 on something like that - it ran poorly enough
on my 350 Mhz P-II with 64 megs.
>>>>>>>>>>
Obviously our experiances are different. However, Win3.1 was really bad in terms of performance, especially due to the real mode filesystem. (NT's filesystem is about 5 TIMES faster.) Also, you're comparison is uneven. KDE1.2 + X lacks a LOT of the features of NT4. My Slackware system runs GNOME 1.2, KDE 2.0b3, X4.0.1, and kernel 2.4-pre5. Then, load up the latest build of Mozilla, and you've got a system that is comparable to an NT machine. In that, it means it can run all the available software for the platform, it has an object model, and most of the features of NT's DE, and a browser (IE is always in memory if you've got on active desktop). My machine is very trimmed, 200megs before X and GNOME and KDE. (BTW. My system partition for NT4 is only 500MB, and it is presently only half filled. Apps are a different matter) That config takes up a good DEAL more RAM than NT. A lighter config, GNOME+Mozilla+X+kernel, still takes up more RAM than NT4. Linux + X + KDE1.2 also takes up (though slightly) more than NT4. At that point, it isn't even a fair comparison because NT's DE has so many more features than KDE1.2
What the HELL are you talking about? DirectX is a development API. Vendors can also write
drivers which allow DirectX to use the full abilities of their hardware - just as is done with every
other graphics API, such as OpenGL or Glide, both of which run on Linux fine. My games run much
faster when I use Glide than DirectX - if DirectX somehow magically makes hardware faster, how do
you explain that?
>>>>>>>>>
You miss the point entirely. I said that DirectX apps take much fuller advantage of the hardware than Linux apps. Secondly, it is NOT possible to write OpenGL apps that automatically take full advantage of the hardware. Let me explain. Say DirectX supports rotating bitmaps, scaling them, and blurring them. If you've got a piece of hardware that supports the first two, but not the third. The developer simply writes a driver that exposes these two features, and leaves the third to DirectX. Thus a DirectX application can use all three features, though the third feature will be slow on that particular card. However, when the user upgrades their card to one that supports all three features, DirectX will automatically use the hardware version. All this will happen transparently to the application, it will just notice that these operations perform faster. Now my point is that hardware with DirectX support tends to have a lot of these features in hardware. However, most Linux APIs don't have nearly as many features as DirectX, thus you sometimes end up with situations where there is support for a featuere in the hardware, but not in the API. For example, on your Linux machine, your soundcard's 3D sound hardware is going totally unitilized. By supporting a very broad range of features, and emulating those that aren't supported by hardware, DirectX makes sure that developers use those features, and when the user upgrades there card, apps can automatically use new acceleration features. As for OpenGL vs. DirectX, it isn't. DirectX is a whole lot more than just 3D, it is more like DirectX vs. OpenGL + ALSA + + X (for overlays and input) +SVGAlib. (BTW, the second combination doesn't come close to competing with the first.) If you're talking about D3D vs. OpenGL, read my article on OSOpinion called "Is OpenGL In Touble". In short, the method that D3D uses to support features is far superior to the method used by OpenGL. Think of it this way. Say I make a graphics card. It supports vertex tweening. Now, this feature isn't a part of OpenGL, so I write an extension to OpenGL called MY_vertex_tweening_extesion. Now what happens here, is that apps can use the vertex tweening features of my card even though it isn't part of OpenGL. However, there is a problem. The extension is propriotary. Meaning that my vertex tweening extension isn't compatible with ATI's vertex tweening extension. Thus, a developer has to write code for both (often several) cases. Now, the ARB (the people who control OpenGL) has the option to make something a standard extension. Thus, there can be a standard ARB_vertex_tweening extension. That way, I can just write code for that extension, and all hardware that supports it will automatically accelerate it. However, OpenGL moves very slowly. The core API doesn't really change that much, and extensions take a long time to come out. (For example multi-texturing came out a lot later as an extension than a feature of Direct3D.) Thus, OpenGL tends to have a lot fewer standard rendering featues than Direct3D. However, extra features don't really take that much code to add. What DirectX does is support a very wide range of features. (BTW> It gets a list of features to put in by asking graphics card makers what they're going to put into their new cards, and asking software developers what features they want to use) Thus, vertex tweening is already a part of Direct3D, and any app that uses it will automatically be accelerated on any hardware that supports it. Because extensions to OpenGL take so long to get standardized, it often happens that developers (except huge people like id, but I doubt he likes coding for each extension) often just choose not to support that features, or write their own software version. Worse, a lot of developers may just code for the cards that exist now, and future cards that support that feature will be left out.
Windows 95 is NOT built on top of DOS. It does contain a lot of cut-and pase Win16 code, but does not run on top of DOS.
However, how many Win16 apps does one run? secondly, you don't seem to quite understand how Windows multi-tasking works. Win16 apps are run inside a virtual machine, which is in itself a Win32 applications. The machine preemptivly multi-tasks all Win32 applications. The Win16 VM then cooperativly multi-tasks all Win16 applications. Thus the illusion doesn't just "vanish" when you run a 16bit application. All your 32 bit applications continue to be preemptivly multi-tasked, it's just that your 16 bit applications are cooperativly multi-tasked (against each other.) Thus, an Win32 application cannot hog the processor, and if a Win16 application does, it won't hog the machine, just the virtual machine. Since the virtual machine is a 32 bit application, it can be preempted so the result is that a Win16 application can only hog the proc from OTHER Win16 applications, not Win32 applications.
Oh and another thing. BeIA is probably going to take less time to implement. While it may cost more, many manufactuerers may just raise the price of the product slightly to beat competitors to market.
Yea, that's why I said that. Of course, BeIA has the advantage that it takes both less time and less cost to implement. For example, it is much more modular and thus quicker to customize, and it already has a GUI that can easily fitted to a developer's needs. In some cases, these will outweight the cost factor.
I don't read MS's thread hype, I read Be's;) From a desktop perspective, there are a lot of things that actually become easier when multi-threaded. In fact, MS desktop apps become better multi-threaded. Having a sperate thread per browser window, having seperate threads for each client of a display engine, having a display thread and a physics thread in games, having background threads that do autocompletion and the like in an IDE, etc. The vast majority of desktop apps really do benifet from multiple threads. The BeOS is heavily multi-threaded, and it is really easy to write multi-threaded applications for the API. Locking and such becomes almost second nature to you. If multi-threading is used where it makes sense, it actually makes the app MORE easy to write an maintain. Fortuneatly, those opportunities are everywhere in desktop apps. Either way, if multi-threading doesn't complicate an app too much, it should be implemented. (Again I'm talking from a desktop POV.) Not only do more and more people have SMP machines, but more and more computers have multiple-specialized processors. Multi-threading is the easiest way to extract more performance from those machines.
Bah-humbug. Give all the evidance you want, my evidance is this. For desktop usage, BeOS (which uses fine-grained locking and multi-threading) is appreciably faster than Linux. And ask any BeOS coder, BeOS code is not the least bit hard to design or write. Once you get into the mindset of writing reenterant code, you'll wonder how you ever managed to write that awefull no reenterant stuff. It's all in how you use multi-threading. There are some things that are stupid to multi-thread Other things (AI or graphics) become EASIER when multi-threaded. The problem lies with people that use multi-threading in a situation where it would be unnatural. However, there are a lot of situations in an OS where multi-threading makes sense. For example, the BeOS windowing system spawns a thread for each window. Not only does this improve performance but actually makes sense. All of this pales in comparison to the fact that multi-threading is still the best way to get increased performance on SMP machines. The fact that most PCs these days have a host of specialized processesors, the arguement for multi-threading becomes that much stronger. (Think of multi-threading as asynchronus I/O for your sound processor and graphics processor.)
1. Linux may not be a nightmare to install, but it is still a nightmare to configure.
I have to partly agree to this one, as it took me a few DAYS of fiddling with the XFree86Setup horror under Xfree 3.3.6 to get my monitor to work.
However, there is no reason to believe that things aren't getting better. When I upgraded to Xfree 4.01 there was no need anymore to fiddle with the scan
frequencies in a poorly documented text file.
>>>>>>
Undoubtedly things are getting better (though in the case of XFree86 configuration actually got WORSE from 3.3.6 to 4.0) but it is nowhere near Windows yet. XFree86 is a chinch to install. However, try to install ALSA with an ISA soundcard, or configure networking for multiple ethernet cards (which most distros don't do. Mandrake 7 does it, RedHat 6.1 and Slackware don't do it) get NAT working, install new drivers, etc. All of these are significantly harder in Linux than in Windows.
2) Linux multi-tasking.
You said that the windows multitasking feels smoother, though I personally doubt most people can tell the difference betweeen 20 msecs and 50 msecs.
What I am more concerned about is overall system stability which is abysmal under Windows 9x and not quite perfect under Windows NT, while Linux
systems are known to go on for years without crashing.
>>>>>>>>>>>>>>
Have you USED Windows NT? (4.0, not W2K) People CAN tell the difference between 20ms and 50ms (and whatever other system things keep NT multi-tasking smoother.) They might not be able to say "oh this is 20, and this is 50" but they can tell, "hey, switching between apps feels smoother." With NT, I can be running a ridiculous load (3D renderer, image editor, IDE, MP3s, etc) not switch between apps quickly and easily. More imporantly, there is little redraw and the system doesn't FEEL loaded. However, Linux to me feels much more like Windows98 than Windows NT. Apps just take longer to start up, longer to switch, and the system actually FEELS loaded under heavy load. It's a preception thing, and preception matters. In the early days of BeOS (when the OS was very immature) Be used to impress people with how fast the UI was. Back then the used tricks like really small quanta to make the OS "feel" fast. (Of course now that BeOS is matured, it really IS fast, without UI tricks.)
3) Linux IS too huge
Heh, I doubt Windows 2000 is much better. I agree that X is a bit of a mess and so is Mozilla, but KDE or Gnome along with the Linux kernel and modules
don't seem to use more than 10 MBs or so of RAM on my machine. This lives room for X, Netscape, and a few other things to run quite comfortably on a 64
MB system.
>>>>>>
That's the problem. Windows 2K ISN'T much better. NT4 is a LOT better. At start up, my NT 4 machine was around 18meg used. After initializing both KDE2 and the GNOME libraries my Linux machine is pushing the high 30s. NT4 + IE +plus two simple apps takes up a LOT less RAM than KDE+GNOME+X+Mozilla+Linux+two simple apps (one KDE, one GNOME)
4) Linux IS playing catch up
It may be true that Linux is in the process of implementing some functionality that has been lacking, but at least it's not quite hanging off the same ancestral
x86 MSDOS code like the "consumer" Windows versions do.
>>>>>
What's your point? Linux is playing catch up to both commerical UNIXs and Windows.
5) Other OS kernels do NOT load everything at the same time.
I have nothing against Windows' dynamically linked libraries model, except when those DLL files royally screw up your system by being replaced and
corrupted by random programs.
>>>>>>>>
Again what's your point? DLL files are almost exactly like Linux dynamic libraries (.so files) except Windows inanely installs them all in one directory. My point is that the FAQ makes it seem like Windows is this big monolithic OS that has all drivers compiled in and loads everything into non-pageable kernel memory whether or not it is needed. That's simply not true.
6) Linux DOESN'T take full advantage of hardware.
Again, there might be a little truth in this, but the main problem here are the closed standards. For example, I am forced to run on a alpha version of a
reverse-engineered CLM driver for my winmodem, which happens to be slow and a bit buggy. Yet because the driver was open source, I was able to go in and
work out an annoying bug myself (which locked up the whole system on a modem retrain) instead of having to pay $50 to M$ support just for the privilege of
dialing their number.
>>>>>>
What does OSS have to do with anything. I stated because of the design of DirectX, Windows apps take advantage of more hardware features that Linux apps.
7) Linux threads aren't all they are cracked up to be.
I personally can't argue much here as I am not an expert in the Linux vs. Windows vs. BeOS thread architecture...
8) Linux really isn't that fast, depending on what you do.
I agree with you that X is a speed bottleneck, but that is because of its client server model. Also as I said before, my Internet experience with Linux has been
somewhat slower, but probably because of the driver I use. My machine feels just as fast or faster for pretty much anything else.
>>>>>>>>
X isn't slower because of the client server model, X is slower because it is bloated and not designed with a high-power client in mind. BeOS uses a client server model as well, (in fact theoretically BeOS's display should be slower due to the use of messaging) but it's display is quite fast. GDI is decent (faster than X) but only because it is a DLL written in ASM and implanted in kernel space.
9) The Linux desktop IS clunky
I wouldn't exactly call it clunky, a little less intuitive perhaps. Overall it offers the same functionality, and much more (i.e. multiple virtual desktops) over
the standard Windows desktop. I am sure that a few years (or months) of evolution can fix that.
>>>>>>>>>>>
Never said that the Windows interace WASN'T clunky. The linux desktops do tend to be slighly clunkier than Windows one (due to less use of context help, right click menus and lot) but both pale in comparison to the Mac and (because it takes a lot of CUEs from the Mac) GUIs.
Also, you keep saying that these are problems a few more months of evolution won't fix. That may be true. However, just because something will be true in the future doesn't mean it's true now.
I have used StarOffice. I have the freaking thing installed. (All 150 megs of it.) I've also messed with the 4.x version, had problems with glibc's and had to do ridiculous things like add environment variables by hand to install it. NOt only that, I had to put up with a bug in the version packaged with RedHat 5.2 where the install script was broken.
I much prefer to use Gobe Productive on BeOS, because that does most of what I need to do. However, there are quite a few things that neither suite can do, and for those things I HAVE to reboot into Windows and start up Office. Like it or not, there are just some things that one CAN'T DO WITHOUT OFFICE. Some features that Office has that nobody else has. I don't really understand what your point is? I happen to like Office better than StarOffice. Though I like WordPerfect better (the Windows version, not the icky Linux vesion) than Word, overall, I like Office better than Corel Office, and Lotus Smartsuite. Just because it's from MS it doesn't deserve to be on Linux?
Interestingly, here is one place BeOS will be competing with Linux. Be has recently announced a deal with Compaq to use it's BeIA OS in some of its machines. Neither OS really has a clear advantage in this field. Since most of the handhelds will use non X-based GUIs, POSIX will be about the only standard that the Linux-Desktop and Linux-handheld OSs will have in common. Since BeIA has POSIX support too, application support will not be a big factor here. Linux has the advantage that it is OSS, which enables developers to customize it. Although BeIA is very modular and customizable also, Linux may have the advantage here. Linux also has the advantage that it is free. However, BeOS has the advantage that it would probably be quicker to work with, since it includes a GUI that is easily customized for a PDA-maker's needs.
The future is really pretty cloudy. It is very probable that the two will compete, because undoubtedly BeIA will scale down from Internet Appliances to handhelds, while PocketLinux will scale up from handhelds to IAs. Neither really has a technical or performance advantage, because most of the speed issues depend on what GUI the PDA-maker chooses to use. I think that the two big factors here are going to be GUI quality, and ease of implementation for the PDA maker.
To be fair, the site is fairly objective. However, I have to bop them on a few points.
1) Linux may not be a nightmare to install, but it is still a nightmare to configure. The main problem is not so much that configuration is very text oriented, but it is not consistant. Some stuff is configured through user-space programs (hdparm and ifconfig.) Other stuff is configured thourgh text files. Some stuff is configured through scripts (the old rc.modules style) others are configured via stuff like modules.conf. Often, there is little feedback if you do something wrong. I still don't know what I'm doing wrong configuring ALSA.
2) Linux multi-tasking.
The site implies that Windows uses cooperative multi-tasking. That is simply not true. Windows95 and WindowsNT all use preemptive multi-tasking and in fact multi-task SMOOTHER than Linux. It is not so much a performance thing as a "feel" thing. The default quantum in NT is around 20 milliseconds or so on workstation, 50-100 on server. The default quantum on Linux is 50 milliseconds (newly lowered in kernel 2.4). So on Linux, each app gets a longer time slice. While this may be more efficiant, it degrades interactive performance (ie the "feel" of the system.)
3) Linux IS too huge. In order to get the same experiance as one does with Windows, you have to use KDE or GNOME. Otherwise your competing a product with more features against one with less features. Also, if you don't use GNOME or KDE, some of the other "FUD" becomes true. To get a Linux system comparable to a Windows NT system, you have to have GNOME+KDE(both so you have full compatibility) +Mozilla+X+kernel. Not to mention the multiple versions of glibc and all the additional (often redundant) libraries all the apps use. In terms of memory usage, Linux blows NT4 out of the water (a bad thing) and is quite close to Windows 2000's bloat.
4) Linux IS playing catch up. Most new kernel features (journaling FS, new automounter, LVM, etc) have all been implemented on previous operating systems. Not to mention the fact how much KDE and GNOME are playing catch up.
5) Other OS kernels do NOT load everything at the same time.
I don't know how they got this? Most of Windows is built out of DLLs which can be dynamically unloaded. Most UNIXs had modular kernels long before Linux. Microkernels like BeOS can turn off entire subsystems if they are not needed.
6) Linux DOESN'T take full advantage of hardware.
Linux doesn't support DirectX, and thus automatically lacks support for a lot of hardware features that are in DirectX complient hardware. The main reason was because transparant usage of hardware was a major design consideration for DirectX. It is based on the concept to support many different hardware features, have all applications use them, and then emultate those not supported by hardware. When the hardware supports new features, all apps and the OS automatically take advantage of them. Also, X doesn't have as compelete a support for many graphics operations that are possible in DirectX.
7) Linux threads aren't all they are cracked up to be. I have seen tests show that NTs threads not only take less time to create, but switch significantly quicker. Also, the sites makes excuses for Linux's lack of threaded applications.
FACT: Multi-threaded apps are better. They may have slightly more overhead and are more complex to write, but it really pays of for those with SMP machines. It also pays of in todays systems because of the increasing number of CPUs in the system. Not only due to SMP, but the specialized chips systems use. Graphics cards can do operations independant of the CPU, so for most graphics apps, it makes a lot of sense to have an independant display thread. Thus, the main-thread can do things while the graphics card is busy working. Same thing for 3D audio. Instead of blocking the CPU waiting for the sound card to finish working, spawn another thread and have them process together. The trend is moving towards PCs with more and more independant chips, and there is no excuse for writing single threaded applications.
FACT: Theading on NT doesn't use cooperative multi-tasking. Where did they get that? Threads are preemptivly threaded just like applications.
FACT: Linux doesn't use threads nearly as often as it should. By having the kernel and libraries heavily threaded, and with fine-grained locking, performance really improves.
However, BeOS hopelessly outclasses both in the threads department. The same tests that show that NT threads switch quicker also showed that BeOS threads switch 10x quicker (that is due to the different model BeOS uses for threads. I can't find the articl at the moment, but I'll post it when I do.) Also, the kernel, servers, kits and apps are heavily multi-threaded. The API encourages apps to be multi-threaded. If you've used BeOS on SMP machines, you know how important multi-threading is.
8) Linux really isn't that fast, depending on what you do. For server tasks it is undoubtedly a speed demon, but for desktop tasks, my NT4 machine (not to mention my BeOS machines) FEELS faster. Screens have less visible redraw, apps switch quickly from one to the other. Not to mention the fact that anything media oriented does much better on Windows than on Linux. (This is partially due to the APIs. X is really not great for fast display, OSS isn't really great for complex sound, the X input system can't compare to DirectInput, there really aren't that many MIDI APIs to speak of (at least those comparable to DirectMusic) and (as of now) 3D is STILL slower than on Windows.
9) The Linux desktop IS clunky. It's very attractive, but the Linux guys need to steal some ideas from the Mac instead of Windows.
You aren't the world. What YOU do isn't indicative of what everyone does. Some people need the publishing capability of Publisher, the more rounded tools of Word, the power of Access. StarOffice doesn't offer all the features that some people need. Not to mention the fact people often need Office for the compatibilit. To those people, a port of Office means that they can stop using Windows and switch to Linux. I don't hear talk of diverting of talent, or splitting the market, or competing with existing tools whenever KDE or GNOME come up, so why should it with a port of Office?
Slashdot Mirror
Is it just me, or is the name not necessarily just superflous?
1) The P4 has very long pipes.
2) The P4 has small caches.
3) The P4 has huge bus bandwidth.
4) The regular FPU has been largely depreciated in favor of SSE2.
What does all this add up to? A chip to accelerate 3D. This feature list reads largely like the list of the Playstation 2. (Aside from the long pipelines thing.) You've got the small caches, high bandwidth, and the vector pipes. My guess is that Intel, seeing NVIDIA cramming more and more into the GPU, is trying to come back and troughly blow them out of the water. This chip might process slower per clock for many uses, but the high clock makes up for that. On the otherhand, things that are extermely regular without any branches (ahem, 3D geometry processing) will absolutely fly through this thing.
Probably less than a few percent. Consider the fact that almost all business machines are uni-proc, all consumer machines (except the DualG4) are uni-proc, the only SMP machines you have are (some) servers and workstation machines. The midrange-and-up (where you fund the bulk of multi-processor machines) and the server market are pretty tiny (in terms of machines shipped) than the consumer and business markets (I think the statistic is in the hundreds of millions of consumer machines shipped per year.)
Considering the P4 only does a single proc config...
AMD's profit margin is less than Intel's. If you've seen the kind of price decreases AMD has put up, you'll know why. You can get a 1GHz Thunderbird Athlon for around $650 on pricewatch.
/.ers realize. The Nintendo 64 magnetic drive was vaporware (it was called the 64DD, is it just me, or does read like a cup size?) The Matsushita M2 (another propose console using dual PPC 603e chips) was vaporware.
I think you've confused the term "vaporware." Vaporware is stuff that doesn't show up. It is said to come out, but never does. Given the fact that RDRAM is shipping, and the P4 is close to shipping, you can hardly term them "vaporware." Vaporware has a much narrower definition than most
Okay, I can understand being happy when something like NVIDIA's OpenGL (which is very Windows oriented) performs nearly as well on Linux. However, does Linux Java being slower than Win32 Java "rock?"
Actually, it seems that bash shell scripts are probably a good place to start. For those who are a little more advanced, a form of BASIC is a good idea. There is a thing on BeBeOS called BeBasic that lets you make BeOS GUI apps in BASIC. Though I'm not quite sure you could consider basic that much easier than C, it is a pretty good way to let users who have good ideas, but not much programming practice contribute to the BeOS community.
JAVA CAN BE COMPILED. Repeat this to yourself 5 times every day.
It's cool. It's the same reason that GNOME uses CORBA for embedding. It's the same reason GNOME has it's own VFS layer. It's the same reason GNOME becomes a cross platform API on top of a cross platform API on top of a cross platform API. (GNOME on top of GTK on top of POSIX) It's the same reason Windows is riddled with feature bloat. It is simply not cool to have a simple product.
Considering all the bitching that's been going on with Qt vs. the GPL? I wouldn't be suprised if developers get a little scared, since they have to develop the equivilant of Qt +a WM to use PocketLinux in a product.
I was talking BeOS from a multi-threading point of view, not as an OS, but you asked for it.
/etc, or /boot/home/config, and most of the settings files are there in text format.
On my home PC, the thing just didn't cooperate at all. It didn't pick up the Network card, (RealTek
809), there are no drivers for it, and it messed up the graphics quite badly. The mouse cursor looked
like a multicoloured block. I have an NVIDIA TNT2.
>>>>>>
The graphics card shouldn't be a problem. I've got a TNT and it works fine. Your experiance is a bit unusual though. In my case I have a RivaTNT, a EtherFast100TX and a EtherPCI II network card, and an AWE64 soundcard. Everything was detected the first time around, I just had to put in the settings for the network, download BeNat from bebits, and I was off. From install -> network NAT server/desktop machine was about 20 minutes.
And my sound card didn't work either. I guess
that can be fixed, but I can't connect to the network to download the driver...beh.
>>>>>>
Again, your experiance is a bit unusual. Usually, though, any problems you have you can ask the beusertalk mailing list.
Anyway, when I tested the thing on my work PC, I didn't find it useful for the "tasks" that BeOS
claims it should be good at, at all. Sure, I managed to play 10 MP3's at once, but contrary to popular
belief, it DID slow the system down.
>>>>>
What kind of system do you have? I can play 10 MP3s without even hitting 100% on the processor. Which is a little unusual though. 4.5 used to get up to 12 or 15 without pegging the processor. The trick is to not start them all at the same time, but one at a time. If you just highlight 10 MP3s and hit Open, Soundplayer goes crazy trying to load them all. And watch this. Start up 24 MP3's all at the same time. Under Windows or Linux, it's time to reboot. However, in BeOS, the system slows down, but is still usable to the point where you can easy open up some application to close the MP3s. Right now, I'm running 10MP3s, and I can still browse the 'net fine.
When I tried to play a video, a 600mb MPG from a CD (which
works under Windows), it didn't open it for some reason. It just refused to open large MPG files.
>>>>>>
Are they Sonorsen encoded? Also, the built in media player was troubles with MPEG files. Look on BeBits for a new one that's much smoother. Also, I have a CD with several large (10-25 megs) I can open 5 or 6 of them without hitting 100% on the processor.
Another area where BeOS falls over is management. Sure it's got Telnet and SSH has been ported,
but why the heck? I mean, you can't manage the thing remotely at all. The FTP servers and other
servers I downloaded relied heavily on the GUI to operate. That's pretty useless.
>>>>>>>
The BeOS wasn't designed as a server OS. Still, I don't see what the management problem is. BeOS has Apache, and you can telnet in go to
Also, it doesn't seem to have a decent browser. NetPositive was fast, but couldn't do 80% of the pages
on the Net properly. I downloaded Opera and when I when to a Java-enabled site, it crashed the
system - yes, crashed it. The version was 3.6(I think). The system slowed down completely at first,
btu I did manage to bring up a window and kill the process. However, even though the Opera
processes were killed, the system was still too slow to use and I had to reboot it.
>>>>>>>>
Yes Netpositive is weak. As for Opera, I think the version you used was 3.6-beta7. It's still a beta, and one that was abandoned. Still, I can use it fine without any problems. (Except Java sites, mainly because BeOS doesn't yet have a JavaVM! I'm wouldn't be suprised if they didn't bother to protect against a crash if the user loaded a Java site and the OS didn't have a VM, since this was a beta version.) However, Be is working on bringing Java2 and Opera 4.0 to BeOS. Promises? Maybe, just like widespread OpenGL on Linux?
It seems like the best thing about BeOS is the GNU bash, and we all know that's from the FSF and
can be found on many other OS's. BeOS fans like be-fan over here talk about great things, but deliver
very little. Overall, and I'm not trying to put Be down - Linux or FreeBSD are better choices for the
desktop.
>>>>>>
I have a triple-boot of Slackware 7.1, BeOS 5, and WindowsNT 4. I use BeOS maybe 75% of the time. I reboot into Windows to use Visual Studio, program DirectX, and use my 3D and imaging applications. I reboot into Linux to fiddle around trying to install ALSA, recompile the kernel, compile the latest build of KDE2 (since it is only in RPM and source) Right now, I'm waiting for a new version of kernel 2.4-test because 2.4-test6 seems to have broken the NVIDIA driver. Oh yea, this is a GREAT desktop OS.
I'm not just saying that as a user who's only used Windows, Linux and FreeBSD, but as one
who's used BeOS as well.
>>>>>>>>
Well, that's your opinon. From my POV, I think WindowsNT 4.0 is probably a better desktop OS than Linux, and certainly is the best PC OS available if your doing graphics. BeOS is a much nicer overall use OS than either. And BeOS probably also appeals to a broader range of people. If you the hardcore CLI-user, BeOS has Bash, POSIX, Perl, Python, Apache, and all those wonderful text-mode programs you've come to know and loathe (not to mention application scripting throgh hey). If your a Mac-type GUI user, BeOS is super-easy, and everything can be done from the GUI. If you're a Linux/X user, you'll be happy with how the GUI and the CLI really mesh together well.
BeOS has potential, but Be need to sort out the instability, the lack of applications, (including a
good Browser - I know you can get Mozilla for it, but you need to compile it yourself unless you want
to use M7), and their management issues, which, for me, are the biggest issues.
>>>>>>>>>>>
BeOS is far from unstable. I just don't see your situation that often. Sure, you had a bad experiance with BeOS. I'm sure a lot of people had had the same with Linux. As for me, and a lot of other BeOS users, the OS is fast, stable, innovate, and works great. It just seems that the "average BeOS" experiance is closer to mine, than yours.
Please stop the DirectX vs. OpenGL thing. It's Direct3D vs. OpenGL. If I get flamed every time I refer to the kernel as the OS, all people mistaking DirectX for Direct3D should get flamed. Back to the hardware features thing.
Here is adifference between Direct3D and OpenGL. Say 5 new cards support a new feature (say cubic environment mapping.) Now, the philosophy behind Direct3D is to get feedback from developers on what features they are putting in, and support as many of those as possible. Thus, cubic environment mapping is already supported in Direct3D. Since the card makers don't want to leave out Quake, they write 5 different extensions for cubic environment mapping. This is again due to the fact that OpenGL does everything by commitie (and a slow one at that.) So, in Direct3D's case, all cards that support a feature will accelerate any game that uses that features. In OpenGL's case, many new features (new as in less than 1 or 2 years old) will go unused until a standard extension is made for them. It is not only a features difference, but a difference in the way the API is built. And Direct3D does support features that haven't been IMPLEMENTED yet. This is another design goal of DirectX (in general.) MS puts in features in the API that no cards support yet. Now games can (usually) use those features because they will be emulated (it's actually slightly more complex than that, but I don't want to get into Direct3D programming). When card manufacturers DO implement this features in hardware, there will be a number of games that already take advantage of it. So, a card manufacturer can put in cubic environment mapping, a feature nobody else has, and games that use it will automatically be accelerated, even though no cards supported that feature when the game was written. This is another major difference between OpenGL and Direct3D. OpenGL doesn't get extensions to features that nobody has yet implemented. However, this is a very good thing, because if you spend your money to buy a card with this new feature, the games you have will automatically use it.
That's competition. This page was from TT, and it's there choice. Like all the Linux commercials making fun of BillG are in good taste? Lastly, it IS true. GNOME DOES have slower repaints than KDE.
How 'bout this. You shut up, and I continue to use KDE, a thinner, faster, less crappy DE, 'k?
I don't see it. Better support for DHTML? In some things maybe in others NOT.
...... Now that is
;) Seriously, though, what is this affinity to Open standards. A de-facto standard is nearly as good as an Open standard, and that is what word is. Think about this. Word is just as compatible as WordPerfect or star office. Why aren't you bitching about them. With WINElib Wordperfect Suite is just as bloated and unstable as Office (probably more so) StarOffice has a lot fewer features and is much slower. What's wrong with Office? Other Office apps (those available on Linux) don't behave at all differently from Office, so where's the beef? Nearly all office apps need patches, have incompatible file formats, changes in interface, etc. What's this vehamance against Word in particular? There are a lot of people who really NEED an Office suite, and Word is pretty much the best one around.
>>>>>
Read the articles from all the guy lamenting that Netscape killed web-standards, not IE. IE supported HTML4.0 earlier and better, it still supports XML better (not better than Gecko though) it has always supported DHTML better (in more things than not) it still has the fastest JavaVM available, etc. It is faster loading, faster to render (I've got DSL, I notice the TCP/IP problems of the BeOS TCP stack) faster to scroll, you name it. It also takes less memory and crashes less often.
I use Office. Fast is not in its vocabulary. As far as Word better its a matter of opinion. I've seen
Office implemented in all types of business. The only sure thing is that the older version does not
support the newer versions files. You need to reinvest every 18 months, download patches
constantly. In most cases, people using Word are slower than poeple who use electronic typewriters.
It's no longer a productivity tool. The prefrences/options change from version to version, which has
led to millions using word but few who know how to. The default option on Word is never to create
a backup of the current file so when the system goes haywire and a restart of the system is
required(not to mention the blue screen.......) all is lost. Frankly I'm wondering after all this time you
would think reboot/restart would be history. I won't get into excel, with its large file problems.
>>>>>>>
Difficulty of use coming from a LINUX USER? Let's see, the last change of the Word file format was in 1997. I have only downloaded one patch for Office 97 (and some helper dudes) As for your other complaints, your complaining about defaults. It takes no time to switch to creating a backup file, and only slightly longer to relearn the menus. For people who uses this for their job, the changes amount to, oh, maybe a week of relearning. My dad just switched from Wordperfect to Word at his workplace. Complained maybe for a few days, after a week or two he is as proficiant as he was with Wordperfect. Despite all this, there is stuff that Office can do that StarOffice and Corel Office simply cannot.
Lastly, it is standard. Like it or not, no suite provides the sheer compatibility of Word.
You see the way I see compatibility/standard is for example the way we connect appliances to the
electrical outlets. We do not have to worry about who made the plug and who made the outlet. The
toaster plugs into the same outlet as the fridge, as the hairdryer, as the lamp, etc
COMPATIBILITY. When I use Linux, FreeBSD, OSS, I finaly see this compatibility. When I look at
TCP/IP, SMTP, etc.. I see this compatibility. When I look a MS Office I wonder if the plug will fit in
the most recent outlet or must I upgrade once again.
One last question...why must I reboot a system? Why can't I let it run? Why is a reboot productive. If
I were Micro$oft I would be ashamed.
>>>>>>>>
Compatibility is what resulted in the cobbled together mess that is the PC
I've never, ever had to have multiple glibc versions running on a machine. Also, you only need the
base libraries for GNOME and KDE to actually run the apps - most of the stuff is only useful if
you're using the full desktop.
>>>>>>>
Are you running Netscape? On a glibc2.1.3 machine, you need compatibility libraries. As for the libraries, Qt is 2.5 megs, kdesupport is 3.5 meg kdelibs is 5 meg. That's 9 meg. Assuming the RPM format uses compression, you're talking around 15 megs of libraries.
Not in my experience. Obviously, this kind of article is just going to lead to a flame fest all around,
but I've run RH 6.1 on a 25 Mhz 486 with 16 megs of RAM - WITH X+KDE. And it wasn't noticalbly
slower than the Win 3.1 it replaced. Try running NT4 on something like that - it ran poorly enough
on my 350 Mhz P-II with 64 megs.
>>>>>>>>>>
Obviously our experiances are different. However, Win3.1 was really bad in terms of performance, especially due to the real mode filesystem. (NT's filesystem is about 5 TIMES faster.) Also, you're comparison is uneven. KDE1.2 + X lacks a LOT of the features of NT4. My Slackware system runs GNOME 1.2, KDE 2.0b3, X4.0.1, and kernel 2.4-pre5. Then, load up the latest build of Mozilla, and you've got a system that is comparable to an NT machine. In that, it means it can run all the available software for the platform, it has an object model, and most of the features of NT's DE, and a browser (IE is always in memory if you've got on active desktop). My machine is very trimmed, 200megs before X and GNOME and KDE. (BTW. My system partition for NT4 is only 500MB, and it is presently only half filled. Apps are a different matter) That config takes up a good DEAL more RAM than NT. A lighter config, GNOME+Mozilla+X+kernel, still takes up more RAM than NT4. Linux + X + KDE1.2 also takes up (though slightly) more than NT4. At that point, it isn't even a fair comparison because NT's DE has so many more features than KDE1.2
What the HELL are you talking about? DirectX is a development API. Vendors can also write
drivers which allow DirectX to use the full abilities of their hardware - just as is done with every
other graphics API, such as OpenGL or Glide, both of which run on Linux fine. My games run much
faster when I use Glide than DirectX - if DirectX somehow magically makes hardware faster, how do
you explain that?
>>>>>>>>>
You miss the point entirely. I said that DirectX apps take much fuller advantage of the hardware than Linux apps. Secondly, it is NOT possible to write OpenGL apps that automatically take full advantage of the hardware. Let me explain. Say DirectX supports rotating bitmaps, scaling them, and blurring them. If you've got a piece of hardware that supports the first two, but not the third. The developer simply writes a driver that exposes these two features, and leaves the third to DirectX. Thus a DirectX application can use all three features, though the third feature will be slow on that particular card. However, when the user upgrades their card to one that supports all three features, DirectX will automatically use the hardware version. All this will happen transparently to the application, it will just notice that these operations perform faster. Now my point is that hardware with DirectX support tends to have a lot of these features in hardware. However, most Linux APIs don't have nearly as many features as DirectX, thus you sometimes end up with situations where there is support for a featuere in the hardware, but not in the API. For example, on your Linux machine, your soundcard's 3D sound hardware is going totally unitilized. By supporting a very broad range of features, and emulating those that aren't supported by hardware, DirectX makes sure that developers use those features, and when the user upgrades there card, apps can automatically use new acceleration features. As for OpenGL vs. DirectX, it isn't. DirectX is a whole lot more than just 3D, it is more like DirectX vs. OpenGL + ALSA + + X (for overlays and input) +SVGAlib. (BTW, the second combination doesn't come close to competing with the first.) If you're talking about D3D vs. OpenGL, read my article on OSOpinion called "Is OpenGL In Touble". In short, the method that D3D uses to support features is far superior to the method used by OpenGL. Think of it this way. Say I make a graphics card. It supports vertex tweening. Now, this feature isn't a part of OpenGL, so I write an extension to OpenGL called MY_vertex_tweening_extesion. Now what happens here, is that apps can use the vertex tweening features of my card even though it isn't part of OpenGL. However, there is a problem. The extension is propriotary. Meaning that my vertex tweening extension isn't compatible with ATI's vertex tweening extension. Thus, a developer has to write code for both (often several) cases. Now, the ARB (the people who control OpenGL) has the option to make something a standard extension. Thus, there can be a standard ARB_vertex_tweening extension. That way, I can just write code for that extension, and all hardware that supports it will automatically accelerate it. However, OpenGL moves very slowly. The core API doesn't really change that much, and extensions take a long time to come out. (For example multi-texturing came out a lot later as an extension than a feature of Direct3D.) Thus, OpenGL tends to have a lot fewer standard rendering featues than Direct3D. However, extra features don't really take that much code to add. What DirectX does is support a very wide range of features. (BTW> It gets a list of features to put in by asking graphics card makers what they're going to put into their new cards, and asking software developers what features they want to use) Thus, vertex tweening is already a part of Direct3D, and any app that uses it will automatically be accelerated on any hardware that supports it. Because extensions to OpenGL take so long to get standardized, it often happens that developers (except huge people like id, but I doubt he likes coding for each extension) often just choose not to support that features, or write their own software version. Worse, a lot of developers may just code for the cards that exist now, and future cards that support that feature will be left out.
Windows 95 is NOT built on top of DOS. It does contain a lot of cut-and pase Win16 code, but does not run on top of DOS.
However, how many Win16 apps does one run? secondly, you don't seem to quite understand how Windows multi-tasking works. Win16 apps are run inside a virtual machine, which is in itself a Win32 applications. The machine preemptivly multi-tasks all Win32 applications. The Win16 VM then cooperativly multi-tasks all Win16 applications. Thus the illusion doesn't just "vanish" when you run a 16bit application. All your 32 bit applications continue to be preemptivly multi-tasked, it's just that your 16 bit applications are cooperativly multi-tasked (against each other.) Thus, an Win32 application cannot hog the processor, and if a Win16 application does, it won't hog the machine, just the virtual machine. Since the virtual machine is a 32 bit application, it can be preempted so the result is that a Win16 application can only hog the proc from OTHER Win16 applications, not Win32 applications.
Oh and another thing. BeIA is probably going to take less time to implement. While it may cost more, many manufactuerers may just raise the price of the product slightly to beat competitors to market.
Yea, that's why I said that. Of course, BeIA has the advantage that it takes both less time and less cost to implement. For example, it is much more modular and thus quicker to customize, and it already has a GUI that can easily fitted to a developer's needs. In some cases, these will outweight the cost factor.
I don't read MS's thread hype, I read Be's ;) From a desktop perspective, there are a lot of things that actually become easier when multi-threaded. In fact, MS desktop apps become better multi-threaded. Having a sperate thread per browser window, having seperate threads for each client of a display engine, having a display thread and a physics thread in games, having background threads that do autocompletion and the like in an IDE, etc. The vast majority of desktop apps really do benifet from multiple threads. The BeOS is heavily multi-threaded, and it is really easy to write multi-threaded applications for the API. Locking and such becomes almost second nature to you. If multi-threading is used where it makes sense, it actually makes the app MORE easy to write an maintain. Fortuneatly, those opportunities are everywhere in desktop apps. Either way, if multi-threading doesn't complicate an app too much, it should be implemented. (Again I'm talking from a desktop POV.) Not only do more and more people have SMP machines, but more and more computers have multiple-specialized processors. Multi-threading is the easiest way to extract more performance from those machines.
Bah-humbug. Give all the evidance you want, my evidance is this. For desktop usage, BeOS (which uses fine-grained locking and multi-threading) is appreciably faster than Linux. And ask any BeOS coder, BeOS code is not the least bit hard to design or write. Once you get into the mindset of writing reenterant code, you'll wonder how you ever managed to write that awefull no reenterant stuff. It's all in how you use multi-threading. There are some things that are stupid to multi-thread Other things (AI or graphics) become EASIER when multi-threaded. The problem lies with people that use multi-threading in a situation where it would be unnatural. However, there are a lot of situations in an OS where multi-threading makes sense. For example, the BeOS windowing system spawns a thread for each window. Not only does this improve performance but actually makes sense. All of this pales in comparison to the fact that multi-threading is still the best way to get increased performance on SMP machines. The fact that most PCs these days have a host of specialized processesors, the arguement for multi-threading becomes that much stronger. (Think of multi-threading as asynchronus I/O for your sound processor and graphics processor.)
1. Linux may not be a nightmare to install, but it is still a nightmare to configure.
I have to partly agree to this one, as it took me a few DAYS of fiddling with the XFree86Setup horror under Xfree 3.3.6 to get my monitor to work.
However, there is no reason to believe that things aren't getting better. When I upgraded to Xfree 4.01 there was no need anymore to fiddle with the scan
frequencies in a poorly documented text file.
>>>>>>
Undoubtedly things are getting better (though in the case of XFree86 configuration actually got WORSE from 3.3.6 to 4.0) but it is nowhere near Windows yet. XFree86 is a chinch to install. However, try to install ALSA with an ISA soundcard, or configure networking for multiple ethernet cards (which most distros don't do. Mandrake 7 does it, RedHat 6.1 and Slackware don't do it) get NAT working, install new drivers, etc. All of these are significantly harder in Linux than in Windows.
2) Linux multi-tasking.
You said that the windows multitasking feels smoother, though I personally doubt most people can tell the difference betweeen 20 msecs and 50 msecs.
What I am more concerned about is overall system stability which is abysmal under Windows 9x and not quite perfect under Windows NT, while Linux
systems are known to go on for years without crashing.
>>>>>>>>>>>>>>
Have you USED Windows NT? (4.0, not W2K) People CAN tell the difference between 20ms and 50ms (and whatever other system things keep NT multi-tasking smoother.) They might not be able to say "oh this is 20, and this is 50" but they can tell, "hey, switching between apps feels smoother." With NT, I can be running a ridiculous load (3D renderer, image editor, IDE, MP3s, etc) not switch between apps quickly and easily. More imporantly, there is little redraw and the system doesn't FEEL loaded. However, Linux to me feels much more like Windows98 than Windows NT. Apps just take longer to start up, longer to switch, and the system actually FEELS loaded under heavy load. It's a preception thing, and preception matters. In the early days of BeOS (when the OS was very immature) Be used to impress people with how fast the UI was. Back then the used tricks like really small quanta to make the OS "feel" fast. (Of course now that BeOS is matured, it really IS fast, without UI tricks.)
3) Linux IS too huge
Heh, I doubt Windows 2000 is much better. I agree that X is a bit of a mess and so is Mozilla, but KDE or Gnome along with the Linux kernel and modules
don't seem to use more than 10 MBs or so of RAM on my machine. This lives room for X, Netscape, and a few other things to run quite comfortably on a 64
MB system.
>>>>>>
That's the problem. Windows 2K ISN'T much better. NT4 is a LOT better. At start up, my NT 4 machine was around 18meg used. After initializing both KDE2 and the GNOME libraries my Linux machine is pushing the high 30s. NT4 + IE +plus two simple apps takes up a LOT less RAM than KDE+GNOME+X+Mozilla+Linux+two simple apps (one KDE, one GNOME)
4) Linux IS playing catch up
It may be true that Linux is in the process of implementing some functionality that has been lacking, but at least it's not quite hanging off the same ancestral
x86 MSDOS code like the "consumer" Windows versions do.
>>>>>
What's your point? Linux is playing catch up to both commerical UNIXs and Windows.
5) Other OS kernels do NOT load everything at the same time.
I have nothing against Windows' dynamically linked libraries model, except when those DLL files royally screw up your system by being replaced and
corrupted by random programs.
>>>>>>>>
Again what's your point? DLL files are almost exactly like Linux dynamic libraries (.so files) except Windows inanely installs them all in one directory. My point is that the FAQ makes it seem like Windows is this big monolithic OS that has all drivers compiled in and loads everything into non-pageable kernel memory whether or not it is needed. That's simply not true.
6) Linux DOESN'T take full advantage of hardware.
Again, there might be a little truth in this, but the main problem here are the closed standards. For example, I am forced to run on a alpha version of a
reverse-engineered CLM driver for my winmodem, which happens to be slow and a bit buggy. Yet because the driver was open source, I was able to go in and
work out an annoying bug myself (which locked up the whole system on a modem retrain) instead of having to pay $50 to M$ support just for the privilege of
dialing their number.
>>>>>>
What does OSS have to do with anything. I stated because of the design of DirectX, Windows apps take advantage of more hardware features that Linux apps.
7) Linux threads aren't all they are cracked up to be.
I personally can't argue much here as I am not an expert in the Linux vs. Windows vs. BeOS thread architecture...
8) Linux really isn't that fast, depending on what you do.
I agree with you that X is a speed bottleneck, but that is because of its client server model. Also as I said before, my Internet experience with Linux has been
somewhat slower, but probably because of the driver I use. My machine feels just as fast or faster for pretty much anything else.
>>>>>>>>
X isn't slower because of the client server model, X is slower because it is bloated and not designed with a high-power client in mind. BeOS uses a client server model as well, (in fact theoretically BeOS's display should be slower due to the use of messaging) but it's display is quite fast. GDI is decent (faster than X) but only because it is a DLL written in ASM and implanted in kernel space.
9) The Linux desktop IS clunky
I wouldn't exactly call it clunky, a little less intuitive perhaps. Overall it offers the same functionality, and much more (i.e. multiple virtual desktops) over
the standard Windows desktop. I am sure that a few years (or months) of evolution can fix that.
>>>>>>>>>>>
Never said that the Windows interace WASN'T clunky. The linux desktops do tend to be slighly clunkier than Windows one (due to less use of context help, right click menus and lot) but both pale in comparison to the Mac and (because it takes a lot of CUEs from the Mac) GUIs.
Also, you keep saying that these are problems a few more months of evolution won't fix. That may be true. However, just because something will be true in the future doesn't mean it's true now.
I have used StarOffice. I have the freaking thing installed. (All 150 megs of it.) I've also messed with the 4.x version, had problems with glibc's and had to do ridiculous things like add environment variables by hand to install it. NOt only that, I had to put up with a bug in the version packaged with RedHat 5.2 where the install script was broken.
I much prefer to use Gobe Productive on BeOS, because that does most of what I need to do. However, there are quite a few things that neither suite can do, and for those things I HAVE to reboot into Windows and start up Office. Like it or not, there are just some things that one CAN'T DO WITHOUT OFFICE. Some features that Office has that nobody else has. I don't really understand what your point is? I happen to like Office better than StarOffice. Though I like WordPerfect better (the Windows version, not the icky Linux vesion) than Word, overall, I like Office better than Corel Office, and Lotus Smartsuite. Just because it's from MS it doesn't deserve to be on Linux?
Interestingly, here is one place BeOS will be competing with Linux. Be has recently announced a deal with Compaq to use it's BeIA OS in some of its machines. Neither OS really has a clear advantage in this field. Since most of the handhelds will use non X-based GUIs, POSIX will be about the only standard that the Linux-Desktop and Linux-handheld OSs will have in common. Since BeIA has POSIX support too, application support will not be a big factor here. Linux has the advantage that it is OSS, which enables developers to customize it. Although BeIA is very modular and customizable also, Linux may have the advantage here. Linux also has the advantage that it is free. However, BeOS has the advantage that it would probably be quicker to work with, since it includes a GUI that is easily customized for a PDA-maker's needs.
The future is really pretty cloudy. It is very probable that the two will compete, because undoubtedly BeIA will scale down from Internet Appliances to handhelds, while PocketLinux will scale up from handhelds to IAs. Neither really has a technical or performance advantage, because most of the speed issues depend on what GUI the PDA-maker chooses to use. I think that the two big factors here are going to be GUI quality, and ease of implementation for the PDA maker.
To be fair, the site is fairly objective. However, I have to bop them on a few points.
1) Linux may not be a nightmare to install, but it is still a nightmare to configure. The main problem is not so much that configuration is very text oriented, but it is not consistant. Some stuff is configured through user-space programs (hdparm and ifconfig.) Other stuff is configured thourgh text files. Some stuff is configured through scripts (the old rc.modules style) others are configured via stuff like modules.conf. Often, there is little feedback if you do something wrong. I still don't know what I'm doing wrong configuring ALSA.
2) Linux multi-tasking.
The site implies that Windows uses cooperative multi-tasking. That is simply not true. Windows95 and WindowsNT all use preemptive multi-tasking and in fact multi-task SMOOTHER than Linux. It is not so much a performance thing as a "feel" thing. The default quantum in NT is around 20 milliseconds or so on workstation, 50-100 on server. The default quantum on Linux is 50 milliseconds (newly lowered in kernel 2.4). So on Linux, each app gets a longer time slice. While this may be more efficiant, it degrades interactive performance (ie the "feel" of the system.)
3) Linux IS too huge. In order to get the same experiance as one does with Windows, you have to use KDE or GNOME. Otherwise your competing a product with more features against one with less features. Also, if you don't use GNOME or KDE, some of the other "FUD" becomes true. To get a Linux system comparable to a Windows NT system, you have to have GNOME+KDE(both so you have full compatibility) +Mozilla+X+kernel. Not to mention the multiple versions of glibc and all the additional (often redundant) libraries all the apps use. In terms of memory usage, Linux blows NT4 out of the water (a bad thing) and is quite close to Windows 2000's bloat.
4) Linux IS playing catch up. Most new kernel features (journaling FS, new automounter, LVM, etc) have all been implemented on previous operating systems. Not to mention the fact how much KDE and GNOME are playing catch up.
5) Other OS kernels do NOT load everything at the same time.
I don't know how they got this? Most of Windows is built out of DLLs which can be dynamically unloaded. Most UNIXs had modular kernels long before Linux. Microkernels like BeOS can turn off entire subsystems if they are not needed.
6) Linux DOESN'T take full advantage of hardware.
Linux doesn't support DirectX, and thus automatically lacks support for a lot of hardware features that are in DirectX complient hardware. The main reason was because transparant usage of hardware was a major design consideration for DirectX. It is based on the concept to support many different hardware features, have all applications use them, and then emultate those not supported by hardware. When the hardware supports new features, all apps and the OS automatically take advantage of them. Also, X doesn't have as compelete a support for many graphics operations that are possible in DirectX.
7) Linux threads aren't all they are cracked up to be. I have seen tests show that NTs threads not only take less time to create, but switch significantly quicker. Also, the sites makes excuses for Linux's lack of threaded applications.
FACT: Multi-threaded apps are better. They may have slightly more overhead and are more complex to write, but it really pays of for those with SMP machines. It also pays of in todays systems because of the increasing number of CPUs in the system. Not only due to SMP, but the specialized chips systems use. Graphics cards can do operations independant of the CPU, so for most graphics apps, it makes a lot of sense to have an independant display thread. Thus, the main-thread can do things while the graphics card is busy working. Same thing for 3D audio. Instead of blocking the CPU waiting for the sound card to finish working, spawn another thread and have them process together. The trend is moving towards PCs with more and more independant chips, and there is no excuse for writing single threaded applications.
FACT: Theading on NT doesn't use cooperative multi-tasking. Where did they get that? Threads are preemptivly threaded just like applications.
FACT: Linux doesn't use threads nearly as often as it should. By having the kernel and libraries heavily threaded, and with fine-grained locking, performance really improves.
However, BeOS hopelessly outclasses both in the threads department. The same tests that show that NT threads switch quicker also showed that BeOS threads switch 10x quicker (that is due to the different model BeOS uses for threads. I can't find the articl at the moment, but I'll post it when I do.) Also, the kernel, servers, kits and apps are heavily multi-threaded. The API encourages apps to be multi-threaded. If you've used BeOS on SMP machines, you know how important multi-threading is.
8) Linux really isn't that fast, depending on what you do. For server tasks it is undoubtedly a speed demon, but for desktop tasks, my NT4 machine (not to mention my BeOS machines) FEELS faster. Screens have less visible redraw, apps switch quickly from one to the other. Not to mention the fact that anything media oriented does much better on Windows than on Linux. (This is partially due to the APIs. X is really not great for fast display, OSS isn't really great for complex sound, the X input system can't compare to DirectInput, there really aren't that many MIDI APIs to speak of (at least those comparable to DirectMusic) and (as of now) 3D is STILL slower than on Windows.
9) The Linux desktop IS clunky. It's very attractive, but the Linux guys need to steal some ideas from the Mac instead of Windows.
You aren't the world. What YOU do isn't indicative of what everyone does. Some people need the publishing capability of Publisher, the more rounded tools of Word, the power of Access. StarOffice doesn't offer all the features that some people need. Not to mention the fact people often need Office for the compatibilit. To those people, a port of Office means that they can stop using Windows and switch to Linux. I don't hear talk of diverting of talent, or splitting the market, or competing with existing tools whenever KDE or GNOME come up, so why should it with a port of Office?