I wouldn't worry about problems with the game if I were you. I have basically every game that Loki has released and they all perform as well as or better then their Windows releases (Loki is known in their newgroups to point out the bugs that they know of but can't fix so that the game remains compatible with the windows version).
The only warning I would give you is that alot of the games Loki released are extremely addictive. =)
Remember, these aren't the requirements that Loki thought up, these are the requirements of the game according to the original developers. I personally like games and my buddy has been playing Tribes 2 for a week now and it looks great. I like being able to play games on my Linux box, it just means i need to have the hardware to do it. And in reference to games like Diablo, last time I checked, Loki tried and Blizzard said no. Not much you can do about that.
Re:Ximian taking over GNOME development?
on
Bonobo 1.0 released
·
· Score: 1
Well, Bonobo was originally Miquel's project (he's maintainer, or was last i checked). And Ximian is a company that he co-founded. So, you can sorta say that when the maintainer of Bonobo started Ximian, Ximian "took over" Bonobo.
I'm not exactly sure why you linked to that article, but I personally found it to be pretty bad. His ideas were pretty good, but the evidence he provides is awful. The part you directly linked to about Sun was better than some of it, but it also selectively ignores alot of things
That's a Redhat problem. They support approx 1500 packages (I'm guessing). Debian supports about 4500 packages. So with Debian, you have a better chance of getting a Debian approved package for a piece of software. When you download Joe Schmoe's gnome toaster RPM it probably won't be as well integrated and tested as if Redhat made it. Maybe Redhat should let contributers help them maintain their distro? Who knows, but when you get stock packages straight from the distro maintainer, they are all up to snuff (from what I've seen).
You didn't respond to the point he made. This is an rpm problem it's a problem of using packages on Redhat 6.x that are designed for Rehdat 7.x. I have come across this problem as well, and that is why I switched to Debian for my personal machine. Apt-get install has yet to cause a serious problem. And updating sources.list and running apt-get dist-upgrade to go from 2.1 to 2.2 was much easier then dealing with Redhat's installer.
This is also why a company would buy a support contract from Redhat. When these problems come up, you call up your Redhat support dude and worse comes to worse, they'd probably provide you with a package for an older version of their distro.
> Not to mention the whole problem with their authorization servers going down. They're down fairly often for a few hours here and there. It's not a large percentage, but that's unimportant. For that period of time paying users aren't able to play.
I'm sorry, but that just isn't true. If the game can't connect to the authorization server, it lets you play. There are also serveral articles from id guys talking about this because people were worried about 10 years from now if the auth server was down.
That's not a very fair comment. Red carpet is real running software. They just don't want to release it till it's completely ready. If you had been at LinuxWorld, NYC you could have played with it yourself (and yes, it's very impressive, and yes it's under the GPL).
I know this is a troll, but I have to respond. I just hope you know that MS *bought* Visual Basic, IE and most of Office. Furthermore, BASIC is hardly a Microsoft creation, thats like saying that GNU created the C language becuase of GCC.
And XMS is a dirty hack for DOS to understand more then 640k of ram. Notice Linux, FreeBSD and SCO don't use XMS and have no problem addressing all the RAM you have.
If you want to complain about drag and drop you should at least recognize that GNOME is using the xdnd protocol, KDE wrote their own. So all motif apps and xt apps should dnd with GNOME fine. Get the KDE people to work with the X standard.
Embedding panel applets in each others panels would require using the same component model. I don't think either the GNOME or KDE people are going to switch anytime soon. And furthermore, who cares? Who actually has both panels running at the same time? And which applets exist for one but not the other (and if you want it, write, don't bitch at other people to write software for you).
The menues and mime parts are a pain.
For the themeing stuff, again, GNOME uses GTK, KDE uses QT. Why don't motif apps use GTK or QT themes? Cause they are different widget sets. This is life. And if you ever really used different widget sets under windows, you would know that there isn't a perfect blend. You're examples don't cut it either. MFC and VCL are basically the same things... wrappers over Win32. Try using QT on windows and see what I'm talking about.
I won't disagree what working together isn't a good thing, but when you different people who want different things, it isn't always possible. And 95% of end users aren't ever going to switch anyways. I personally use GNOME over KDE and I don't think there is one KDE app installed on my system. So I don't worry about it. And I think you'll find that gonna be the case more often then not.
You're suggestions have nothing to do with the GUI. A file dialog should look as similar as possible for 90% or apps. Why? So that there is consitancy (something that usability study after usability study shows true... read the old Mac UI Design guide). And the filesystem is part of the OS, not the GUI. How could the GNOME or KDE projects make the Linux filesystem flat? All they can do is try and display in a nice fashion the filesystem that they are running on.
If this were a thread about how Windows like MacOS X is, if it didn't support Win32 I'd say not very. Since this is a thread about how Unix like MacOS X is, I'd say not using tools that are standard on just about *every other Unix* makes it less Unix like then Linux. The same statement goes for xml config files. I have nothing against config files in xml, but taking standard config files and turning them into xml makes them different from *every other Unix's config files*.
If you read the thread, you'd see i was talking about how unix like macos x vs linux is. Name one other unix system that uses xml config files? Just one? They took standard unix utilities changed them so they acted *less* like the other unix's. That was my point.
Furthermore, you may have heard of devices such as the Tivo... an embedded device that uses Linux as it's OS. You can debate whether you think Linux is a good solution (I think WinCE and Pocket PC are awful when compared to Palm, but that's besides the point).
The only nitpick I have about what you said is this:
***
The Cocoa (formerly Yellowbox/Openstep) development framework by itself is a find.
***
Now, the keyword there is (formerly Yellowbox/Openstep). How is it that a former OS that basically failed (mostly due to Steve Jobs, no fault of the OS) being reincarnated as MacOS X and having basically the same development tools as before is a find?
I'm not posting this as a flame, I just want to know how people think MacOS X will do better then NextStep considering the same person who drove Next under is at the helm at Apple.
And anyone that doesn't believe that Job's drove Next under can criticize this post, but look it up before you call it FUD. Next machine's where beautiful and before there time. But they also cost a mint and Job's didn't (and still doesn't) keep up with competitors (anyone who thinks that colored plastic is moving computers forward has a problem... and no, there really isn't anything interesting in a Mac. Yes PowerPC is a nice architecture... nicer then x86... but Alpha's and Ultra Sparc's are nicer still).
The masses have shown they like Apple products? Maybe the iMac sold well, but I'd have to say the number of x86 boxes in use today dwarfs the number of Macs. The "masses" don't care what machine they use, they just want to surf the web, check their email and *not* spend more then $300-$500 on a computer.
I'd have to disagree with you. Yes, MacOS X's pedigree is more Unixy (is that a word) then linux's, but Linux is more of a *nix. Little things like not using X make it non-standard (besides the *steps, name a Unix that hasn't used some incarnation of X post the Sun vs The World(tm) desktop war). I'm sure if I poked around it a bit more, I'd find more things to nit-pick, but I think I heard something about a good number of config files moved to XML? If so, that's pretty far away from any of the current *nix's.
Furthermore, x86 MacOS X is really laughable at best. Linux runs on "real" server processors like alpha's, ultra sparcs and mips. And linux can run in large scale SMP or cluster configurations (we all know Beowulf and there was an article somewhere about Linux booting on a 32 proc Compaq Alpha system). Not to mention S390's. These are all server platforms that as far as I know MacOS X will never see. Mach may be cross platform, but I'd like to see how hard it is to move the rest of the crap they put on top if it to different platforms. It would also be fun to see MacOS X scaled down to the pda's and embedded systems. These are all areas that Linux excels in and has been proven as a good solution. It would take a bit to convince me that Apple's first *nix since A/UX is gonna cut the mustard on any of those tasks.
And I'm also not saying Linux is the best for all of those tasks, but it's a far cry better then MacOS X is today, and that's the point of this discussion.
I would have to differ with your opinion of cut and paste. If I want to cut and paste from one app to another, select and middle click is wonderful. And letting each app have it's own clipboard is also a nice feature. Why does a Mac overright my netscape url when I select copy in BBEdit? Emacs and Netscape in Linux conveniently don't share clipboards unless you explictly use select middle click.
The photoshop argument is fine and dandy except Apple is targeting iMacs and iBooks and all that towards people who will never use Photoshop. If all your machine is really good at is Photoshop (and albeit, I know that isn't true, but Apple's benchmarks certainly make it look that way) then you shouldn't be targetting it at people who don't use Photoshop.
Check your facts and read what I wrote. Look up how the thread scheduling functions work on Win95, Win98, WinME, NT4 and 2000 differ. That is merely one example but if you've ever tried to write a complicated multithreaded program, you know that scheduling can be important. And the fact that said scheduling interface is either non existant (stub functions on most of the 9x series) and works or doesn't work depending on service pack (NT and 2000) means that you need to test on every version. That is merely one example, and if you don't believe me, look it up.
Apache runs on almost every version of Unix and most versions of Windows. And the way they do that is with the preprocessor. Without ifdef's and being careful of what functions you call, you'll get burned on Windows.
WINE really isn't an emulator. Win32 is just a wrapper on top of the kernel32.dll system calls and provides some level of compatibility between Win9x and NT (two very different kernels). WINE is just taking Win32 and moving it to a new kernel. You can say all you want to about micro-kernels and whatnot, but it's all pretty much irrelevant since Win9x uses Win32 and DOS is a monolithic kernel. Furthermore, the only difference between a micro-kernel and a monolithic kernel is whether a "system call" is in user space or kernel space. Monolithic kernel, kernel space, micro-kernel, user space. None of this has any bearing, however, on Win32. Please check your facts next time.
And... MS apps do use "undocumented features." Some of them are actual system calls (which are supposedly undocumented because you are supposed to program through Win32, but for some reason MS does). Some of Win32 is also undocumented and if you don't want to believe me read the WINE and Samba mailing lists to see all the fun stuff they dig up.
And lastly... Win32 is horribly incompatible with itself. If you are trying to do anything the slightest bit non-standard you need to test on every revision of Windows. MS likes to change Win32 and kernel32.dll in every update and each one breaks some features and adds others in. For example, look at the thread scheduling functions in NT4 and how they winked in and out of usability between service packs. Just because the system call is still there doesn't make it backwards compatible. It also needs to *work the same as it did before*. And MS is horrible about that. If you'd like further proof, try using the same thread scheduling functions under Win9x and see how far it gets you (and 9x is Win32 so if you're correct about backwards compatibility, it whould work fine). I personally would have to say that Unix or VMS have a much longer history of backwards compatibility then Windows.
On the console or in X? it's already available in X (it's called xinerama or something like that).
The kernel supports 2 cards just fine, it just happens to only display stuff using one of them. =)
Actually, it doesn't have code "specifically to embed Gecko". Nautilus is just a big Bonobo container. It just picks a component to use depending on they type of thing you are trying to view (and last I checked, the component it chooses is configurable). That's how Nautilus does view as music and how Sun showed Nautilus with OpenOffice embedded.
There's only one problem with that. People like myself can't afford to buy a console for one game. Sony has the most third party support of any console system right now. I buy a PS2 and I'll get Metal Gear Solid 2, Final Fantasy X and XI, etc. As of right now Nintendo has themselves and Rare. $200 is too much to play Zelda, again.
Slashdot Mirror
Ask Loki. They ported Heavy Gear Solid 2 to Linux and it was a DX game. From what I've heard, it's more stable under Linux with OpenGL too.
I wouldn't worry about problems with the game if I were you. I have basically every game that Loki has released and they all perform as well as or better then their Windows releases (Loki is known in their newgroups to point out the bugs that they know of but can't fix so that the game remains compatible with the windows version).
The only warning I would give you is that alot of the games Loki released are extremely addictive. =)
Remember, these aren't the requirements that Loki thought up, these are the requirements of the game according to the original developers. I personally like games and my buddy has been playing Tribes 2 for a week now and it looks great. I like being able to play games on my Linux box, it just means i need to have the hardware to do it. And in reference to games like Diablo, last time I checked, Loki tried and Blizzard said no. Not much you can do about that.
Well, Bonobo was originally Miquel's project (he's maintainer, or was last i checked). And Ximian is a company that he co-founded. So, you can sorta say that when the maintainer of Bonobo started Ximian, Ximian "took over" Bonobo.
I'm not exactly sure why you linked to that article, but I personally found it to be pretty bad. His ideas were pretty good, but the evidence he provides is awful. The part you directly linked to about Sun was better than some of it, but it also selectively ignores alot of things
That's a Redhat problem. They support approx 1500 packages (I'm guessing). Debian supports about 4500 packages. So with Debian, you have a better chance of getting a Debian approved package for a piece of software. When you download Joe Schmoe's gnome toaster RPM it probably won't be as well integrated and tested as if Redhat made it. Maybe Redhat should let contributers help them maintain their distro? Who knows, but when you get stock packages straight from the distro maintainer, they are all up to snuff (from what I've seen).
You didn't respond to the point he made. This is an rpm problem it's a problem of using packages on Redhat 6.x that are designed for Rehdat 7.x. I have come across this problem as well, and that is why I switched to Debian for my personal machine. Apt-get install has yet to cause a serious problem. And updating sources.list and running apt-get dist-upgrade to go from 2.1 to 2.2 was much easier then dealing with Redhat's installer.
This is also why a company would buy a support contract from Redhat. When these problems come up, you call up your Redhat support dude and worse comes to worse, they'd probably provide you with a package for an older version of their distro.
> Not to mention the whole problem with their authorization servers going down. They're down fairly often for a few hours here and there. It's not a large percentage, but that's unimportant. For that period of time paying users aren't able to play.
I'm sorry, but that just isn't true. If the game can't connect to the authorization server, it lets you play. There are also serveral articles from id guys talking about this because people were worried about 10 years from now if the auth server was down.
That's not a very fair comment. Red carpet is real running software. They just don't want to release it till it's completely ready. If you had been at LinuxWorld, NYC you could have played with it yourself (and yes, it's very impressive, and yes it's under the GPL).
I know this is a troll, but I have to respond. I just hope you know that MS *bought* Visual Basic, IE and most of Office. Furthermore, BASIC is hardly a Microsoft creation, thats like saying that GNU created the C language becuase of GCC.
And XMS is a dirty hack for DOS to understand more then 640k of ram. Notice Linux, FreeBSD and SCO don't use XMS and have no problem addressing all the RAM you have.
If you want to complain about drag and drop you should at least recognize that GNOME is using the xdnd protocol, KDE wrote their own. So all motif apps and xt apps should dnd with GNOME fine. Get the KDE people to work with the X standard.
... wrappers over Win32. Try using QT on windows and see what I'm talking about.
Embedding panel applets in each others panels would require using the same component model. I don't think either the GNOME or KDE people are going to switch anytime soon. And furthermore, who cares? Who actually has both panels running at the same time? And which applets exist for one but not the other (and if you want it, write, don't bitch at other people to write software for you).
The menues and mime parts are a pain.
For the themeing stuff, again, GNOME uses GTK, KDE uses QT. Why don't motif apps use GTK or QT themes? Cause they are different widget sets. This is life. And if you ever really used different widget sets under windows, you would know that there isn't a perfect blend. You're examples don't cut it either. MFC and VCL are basically the same things
I won't disagree what working together isn't a good thing, but when you different people who want different things, it isn't always possible. And 95% of end users aren't ever going to switch anyways. I personally use GNOME over KDE and I don't think there is one KDE app installed on my system. So I don't worry about it. And I think you'll find that gonna be the case more often then not.
You're suggestions have nothing to do with the GUI. A file dialog should look as similar as possible for 90% or apps. Why? So that there is consitancy (something that usability study after usability study shows true ... read the old Mac UI Design guide). And the filesystem is part of the OS, not the GUI. How could the GNOME or KDE projects make the Linux filesystem flat? All they can do is try and display in a nice fashion the filesystem that they are running on.
If this were a thread about how Windows like MacOS X is, if it didn't support Win32 I'd say not very. Since this is a thread about how Unix like MacOS X is, I'd say not using tools that are standard on just about *every other Unix* makes it less Unix like then Linux. The same statement goes for xml config files. I have nothing against config files in xml, but taking standard config files and turning them into xml makes them different from *every other Unix's config files*.
If you read the thread, you'd see i was talking about how unix like macos x vs linux is. Name one other unix system that uses xml config files? Just one? They took standard unix utilities changed them so they acted *less* like the other unix's. That was my point.
... an embedded device that uses Linux as it's OS. You can debate whether you think Linux is a good solution (I think WinCE and Pocket PC are awful when compared to Palm, but that's besides the point).
Furthermore, you may have heard of devices such as the Tivo
The only nitpick I have about what you said is this:
... and no, there really isn't anything interesting in a Mac. Yes PowerPC is a nice architecture ... nicer then x86 ... but Alpha's and Ultra Sparc's are nicer still).
***
The Cocoa (formerly Yellowbox/Openstep) development framework by itself is a find.
***
Now, the keyword there is (formerly Yellowbox/Openstep). How is it that a former OS that basically failed (mostly due to Steve Jobs, no fault of the OS) being reincarnated as MacOS X and having basically the same development tools as before is a find?
I'm not posting this as a flame, I just want to know how people think MacOS X will do better then NextStep considering the same person who drove Next under is at the helm at Apple.
And anyone that doesn't believe that Job's drove Next under can criticize this post, but look it up before you call it FUD. Next machine's where beautiful and before there time. But they also cost a mint and Job's didn't (and still doesn't) keep up with competitors (anyone who thinks that colored plastic is moving computers forward has a problem
The masses have shown they like Apple products? Maybe the iMac sold well, but I'd have to say the number of x86 boxes in use today dwarfs the number of Macs. The "masses" don't care what machine they use, they just want to surf the web, check their email and *not* spend more then $300-$500 on a computer.
I'd have to disagree with you. Yes, MacOS X's pedigree is more Unixy (is that a word) then linux's, but Linux is more of a *nix. Little things like not using X make it non-standard (besides the *steps, name a Unix that hasn't used some incarnation of X post the Sun vs The World(tm) desktop war). I'm sure if I poked around it a bit more, I'd find more things to nit-pick, but I think I heard something about a good number of config files moved to XML? If so, that's pretty far away from any of the current *nix's.
Furthermore, x86 MacOS X is really laughable at best. Linux runs on "real" server processors like alpha's, ultra sparcs and mips. And linux can run in large scale SMP or cluster configurations (we all know Beowulf and there was an article somewhere about Linux booting on a 32 proc Compaq Alpha system). Not to mention S390's. These are all server platforms that as far as I know MacOS X will never see. Mach may be cross platform, but I'd like to see how hard it is to move the rest of the crap they put on top if it to different platforms. It would also be fun to see MacOS X scaled down to the pda's and embedded systems. These are all areas that Linux excels in and has been proven as a good solution. It would take a bit to convince me that Apple's first *nix since A/UX is gonna cut the mustard on any of those tasks.
And I'm also not saying Linux is the best for all of those tasks, but it's a far cry better then MacOS X is today, and that's the point of this discussion.
I would have to differ with your opinion of cut and paste. If I want to cut and paste from one app to another, select and middle click is wonderful. And letting each app have it's own clipboard is also a nice feature. Why does a Mac overright my netscape url when I select copy in BBEdit? Emacs and Netscape in Linux conveniently don't share clipboards unless you explictly use select middle click.
The photoshop argument is fine and dandy except Apple is targeting iMacs and iBooks and all that towards people who will never use Photoshop. If all your machine is really good at is Photoshop (and albeit, I know that isn't true, but Apple's benchmarks certainly make it look that way) then you shouldn't be targetting it at people who don't use Photoshop.
Check your facts and read what I wrote. Look up how the thread scheduling functions work on Win95, Win98, WinME, NT4 and 2000 differ. That is merely one example but if you've ever tried to write a complicated multithreaded program, you know that scheduling can be important. And the fact that said scheduling interface is either non existant (stub functions on most of the 9x series) and works or doesn't work depending on service pack (NT and 2000) means that you need to test on every version. That is merely one example, and if you don't believe me, look it up.
Apache runs on almost every version of Unix and most versions of Windows. And the way they do that is with the preprocessor. Without ifdef's and being careful of what functions you call, you'll get burned on Windows.
WINE really isn't an emulator. Win32 is just a wrapper on top of the kernel32.dll system calls and provides some level of compatibility between Win9x and NT (two very different kernels). WINE is just taking Win32 and moving it to a new kernel. You can say all you want to about micro-kernels and whatnot, but it's all pretty much irrelevant since Win9x uses Win32 and DOS is a monolithic kernel. Furthermore, the only difference between a micro-kernel and a monolithic kernel is whether a "system call" is in user space or kernel space. Monolithic kernel, kernel space, micro-kernel, user space. None of this has any bearing, however, on Win32. Please check your facts next time.
... MS apps do use "undocumented features." Some of them are actual system calls (which are supposedly undocumented because you are supposed to program through Win32, but for some reason MS does). Some of Win32 is also undocumented and if you don't want to believe me read the WINE and Samba mailing lists to see all the fun stuff they dig up.
... Win32 is horribly incompatible with itself. If you are trying to do anything the slightest bit non-standard you need to test on every revision of Windows. MS likes to change Win32 and kernel32.dll in every update and each one breaks some features and adds others in. For example, look at the thread scheduling functions in NT4 and how they winked in and out of usability between service packs. Just because the system call is still there doesn't make it backwards compatible. It also needs to *work the same as it did before*. And MS is horrible about that. If you'd like further proof, try using the same thread scheduling functions under Win9x and see how far it gets you (and 9x is Win32 so if you're correct about backwards compatibility, it whould work fine). I personally would have to say that Unix or VMS have a much longer history of backwards compatibility then Windows.
And
And lastly
On the console or in X? it's already available in X (it's called xinerama or something like that).
The kernel supports 2 cards just fine, it just happens to only display stuff using one of them. =)
Actually, it doesn't have code "specifically to embed Gecko". Nautilus is just a big Bonobo container. It just picks a component to use depending on they type of thing you are trying to view (and last I checked, the component it chooses is configurable). That's how Nautilus does view as music and how Sun showed Nautilus with OpenOffice embedded.
I wouldn't call something you can download and use vaporware. Even if it's not at version 1.0, it's there and you can use it today.
There's only one problem with that. People like myself can't afford to buy a console for one game. Sony has the most third party support of any console system right now. I buy a PS2 and I'll get Metal Gear Solid 2, Final Fantasy X and XI, etc. As of right now Nintendo has themselves and Rare. $200 is too much to play Zelda, again.