Was your consistent use of 'ia64' a typo, and you really meant AMD64?
You do know that IA64 and AMD64 are pretty much completely incompatible, right? The only thing that they share is that they both execute x86 code, but the AMD64 does a much better job at it.
The problem goes a lot farther than aesthetics (although they did a good job of screwing those up, too.)
The problem is that RedHat has no qualms about releasing prerelease software and labelling it as "release". Granted, fontconfig adoption might have taken slightly longer than it has if RedHat had not pushed it so heavily in their distro, but the problem lies in things like RedHat using their own custom patches to a stable Qt version to add fontconfig/Xft2 support, and installing prerelease glibc versions that KDE hasn't been tested on, and other various immature practices.
The fact that they use incorrectly-sized icons, and then the icons don't scale properly, and make KDE look like ass, is only icing on the cake. Also, the fact that their Bluecurve desktop theme is really crappy doesn't help either.
And just for when you say "Well, why don't you do better?" - I have. See my homepage - I write KDE styles, and even though I've only released one, I have a few more that I'm currently working on. (As well as a few applications that are in various stages of development.)
So the complaints against RedHat's KDE are slightly deeper than "They use ugly icons!". And the fact that they choose a butt-ugly theme for KDE by default means that KDE looks butt-ugly by default, which is a serious usability nightmare.
I personally don't care if you're a GNOMEr or a KDEr, but RedHat has some serious quality assurance/control issues, and it's not just limited to KDE. KDE just happens to be a high-profile example.
I'd just like to point out that if you have any C++ experience whatsoever, learning Qt will take you much less time than "months". You can be productive with Qt within several days of starting to use it, if not several _hours_.
This is for the K8/Sledgehammer/Opteron architecture - NetBSD runs in full 64-bit mode on it.
Re:It's not cost-effective to roll your own.
on
.Mac Alternatives?
·
· Score: 1
Yeah, but you have to deal with the limits that Apple gives you. What if you want ssh access? What if you want more than 500MB of space to store stuff? What if you want to upgrade the hard drive in the server? What if you like running your own servers and you don't really need the silly iDisk?.Mac makes a lot of sense for a lot of people, but for some of us, it's not the right answer, and that's ok. The fact that Apple's using open standards is enough for me, anyway.
Internet Explorer runs with Adminstrator privileges. So does Windows Media Player. And Microsoft Office. Including Outlook. The "finer-grained ACLs" on Windows NT-based OSes don't mean shit when the programs all get to run setuid root.
No, because if SCO/Caldera distributed the changes in the GPLed version of the source, they were giving permission implicitly for the code to be included - and if they're still selling it, which they are, then any and all of the code that "infringes" and is also included in their version of Linux is freely redistributable. I'm not a lawyer, but my uncle is. We've had a very lengthy discussion about this.
Personally, I would be surprised if IBM didn't bury SCO with something on the order of 517 patents that SCO has been infringing on of theirs - I honestly think that the only reason it's taking IBM so long to formulate their response is that they have that many patents to check and make sure SCO is infringing that it could take a little while to enumerate them and write them down. But that's just me.
Point 1: Any systems that Apple ships with a PPC970 in them will get "World class performance" on a par with a P4, if not handily spanking it.
Point 2: IBM makes all of the G3s that Apple currently ships. You buy an iBook? You get an IBM G3 inside. You buy an older iMac? IBM G3. So it's not like Apple would be moving to a new untested company who hadn't proven themselves to be capable CPU producers.
Point 3: The PowerPC 970 was designed with the same HyperTransport support as the Opteron. The same exact system. IBM is planning on making 4-way and 8-way PPC970 boxen to sell. Apple could easily do the same, and we're talking about performance that wouldn't just "compete" but blow away anything else except possibly the Opteron. Also, keep in mind that Altivec really does turn the tables in a LOT of cases... SSE2 is nice, but it hasn't shown itself to be nearly as easy/nice to code to, nor has it shown the startling difference with regards to performance that Altivec has.
All in all, my prediction is that a move to PPC970 is all but inevitable. Opteron would be interesting, but Apple is in the middle of a software changeover right now... there are still a few million MacOS Classic users to convert to Jaguar/Panther, you know. You tell all of your current users that their brand-new PPC hardware is actually obsolete, because new hardware will be x86-64 and all future applications will be x86-64, and you've just successfully cannibalized your own market and signed your death warrant.
Oh, and Konq is getting a ton of other neat features in 3.2 as well.:)
Not to mention a significant decrease in load time and a huge boost in performance. KHTML is now as fast as or faster than Gecko in my day-to-day browsing tests (usually beating it, but there are probably still a few oddball cases where Gecko might be a bit better/faster. I don't see them though.)
The article was at Ars Technica, and it was about the Counter-Strike server, not the actual video game.
However, the 30% speed improvement was NOT over an Athlon. They took the 32-bit binaries, benchmarked them on the Opteron, and then they recompiled the code for the x86-64 target (without changing a single line) and benchmarked it again, and there was a 30% speed improvement.
That's pretty impressive if you ask me. Granted, the server side does most of the physics logic and such, and not graphics, but I'm optimistic about just how much the increase in raw CPU power is going to help gaming out.
Actually, the last time that I played around with ZSNES (at least 3 or 4 months ago) X3 did, in fact, work. (It's one of my favorite games of all time, so I always check to see if it's playable:)
And yes, I do own the original cartridge. It's sitting here in my SNES, plugged into my TV. However, my laptop is a lot more portable than my TV and SNES, so... yay emulation!
The difference is that we didn't write an ORB, because we didn't need CORBA. We wrote DCOP because we needed lightweight, fast IPC, which was only one of the many features of CORBA - and on a desktop, you won't be using most of the features of CORBA.
And what exactly is the benefit of having interoperability with the stock Java ORB in GNOME? What does that provide to the end-user? What components are being implemented in the Java ORB that are useful to us users?
DCOP hasn't lost. It's still insanely useful for IPC and offers that IPC to users in ways that it's never been possible to use before.
Even if the backend for DCOP gets ripped out and replaced with D-BUS, DCOP hasn't lost, just gotten better. Since you haven't bothered to answer the question either, I'm going to assume that Mike was just trolling. The entire reason that we WROTE DCOP was because CORBA was ridiculously slow.
Slow to grok, slow to compile, and even slower to run. CORBA has plenty of neato advantages and features, but speed has never been one of them. DCOP was conceived to be a fast lightweight IPC mechanism for X-based desktops.
DCOP is no more bound to X11 than KDE or Konqueror[1] is. The only reason it was bound to it is because the message-passing backend was implemented using libICE - but that backend can be ripped out and replaced, say with D-BUS, and no applications will even need to be recompiled.
-clee
[1]: Note that Konqueror runs on the Linux framebuffer, and KHTML itself has been ported to a few non-X11 systems such as AtheOS/Syllable and MacOS X. Qt runs on Windows and MacOS X in addition to X11 desktops.
Do you have specific benchmarks, or real data to back this up? I'm kinda curious, because I was under the impression that the only thing limiting DCOP's speed was ICE on X11 (libICE specifically). Do you have any links?
Well, it took slightly longer, but that also includes the packaging, the screenshotting, the uploading, and so on and so forth. You can download the new dotNET tarball from here or just go to KDE-look or c133.org and download from there.
Please, in the future, if you have any more such feature requests - don't hesitate to send me an email!
I'd be willing to work for a company and do either consulting for a Windows-to-Linux shift or actually help with the shift. Drop me a line if you're serious.
I like C++ better. That's subjective, but I think that it's an easier way to make things work right.
He noted that there's really little difference between having constructors in a language, and making constructor functions instead; I disagree, but in the case of his argument saying that the function names were self-documenting, I pointed out that that's more necessary since the GTK+ documentation is rather lacking, and Qt's documentation is widely regarded as incredible.
That's all. I'm not changing the argument, just adding thoughts about documentation which are somewhat orthogonal to the discussion about language features.
If that's true, then PLEASE, point me to a single Bonobo object implemented in Python.
Or Ruby.
Or Java.
Or SmallTalk. Or OCaml, LISP, Scheme, or Perl. Any one of them.
Where are they? Where is the "Implementing a Bonobo object in Python" tutorial? Where's the documentation? Where are the examples, the real-life apps using them?
That's my point. They don't exist, so pointing at KDE/KParts and saying "You have to use C++ for KParts!" is silly, because you have to use C for Bonobo (to implement, anyway. Unless I'm wrong - which, if I am, please do tell me.:)
Ah, but having documentation for the APIs makes all the difference.
Self-documenting function names might be neat, but that's a nasty kludge for not having a well-designed API, IMHO. The Qt API docs are the best I've ever seen from ANY project, bar none. So you know exactly which constructors exist for QPushButton, what types they take, etc - there's no question about it, and you don't have to do any weird casting in order to get it to work right (which is necessary in C a lot of the time).
I've never used Eiffel, so I won't comment on that, but I really like the way that C++ constructors work; in any case, I agree that it's mostly a matter of syntax and semantics, but I think that the C++ way of doing it (having a 'new' keyword, class constructors, etc) is better and cleaner. Again, this is all very subjective, so you're free to disagree, but for new programmers... well, it depends on what language they learn first.:)
Keep in mind that KDE also has bindings for Python, Ruby, Java, Perl, and (Qt so far) even C#. We're not exactly lagging behind in the bindings race. Unless you consider Scheme and OCaml bindings to be important, of course... but then, I've heard that GNOME's bindings for these languages have lagged behind and not been updated as consistently as their more popular ones. YMMV.
I made reference to the real problem in another thread, but here goes:
Sure, I could write GNOME stuff in Python or Ruby or Scheme - but how many Bonobo objects are written in these languages? How reusable is my code going to be if I do this? Not very, I suspect. That's the whole crux of the matter.
That, and all of the language bindings are at a different state; the Python bindings are farther along than the Java ones; the Ruby ones still have a bit of maturing to do, last I checked, and the C# ones are brand-new (although they look to be surprisingly complete, which is neat). Still, I don't see anyone implementing any Bonobo objects in any languages other than C, which to me signifies that it's either impossible or not worth it.
I would check out gtkmm, except that I'm already very well-versed in Qt, and it'd be a waste of my time to learn GTK+. (That, and I personally think that Qt has a cleaner, better, nicer API, but again, that's semantics and a very subjective thing; most C coders, I presume, would much prefer to learn GTK+ than to have to learn C++ to use Qt).
Well, see, CORBA is (as far as I understand) used for both IPC and object embedding.
In KDE, we've made a pretty wide distinction between the two, such that you can have IPC without needing object embedding; DCOP is our IPC mechanism, and as I've said, it works fairly well (and DBUS seems to have garnered a bit of interest among a few of our developers, so we may move DCOP to a DBUS backend at some point too).
For the object embedding part (the 'distributed object model' stuff that you CORBA guys seem so fond of) is exactly what KParts is for. From what I grok of GNOME, Bonobo is the GNOME version of KParts; although it might be that Bonobo has a couple of benefits that KParts don't, being that it has all of the CORBA tech behind it.
KParts, for us, solve the other half of the problem with regards to object embedding. Konqueror knows how to embed a KPart for viewing (say) a spreadsheet, or an HTML document, or a dozen other things. It knows how, thanks to KParts and XMLGUI, to merge the UI elements, so that if you're browsing your filesystem, you don't see menu options to increase/decrease the font size or a toolbar icon for indicating the HTTPS status of the connection.
KParts tech is also local-machine only, which may possibly be a disadvantage, but I still haven't seen any viable way to remotely access a Bonobo/CORBA object. And while it should be theoretically possible to write KParts in other languages, I haven't seen it done yet (just like I haven't seen anyone write any Bonobo objects in Python;) But for us, IPC is completely separate from object embedding, and I think that it makes sense that way.
Slashdot Mirror
Hi!
:)
Welcome to Slashdot.
You must be new!
Was your consistent use of 'ia64' a typo, and you really meant AMD64?
You do know that IA64 and AMD64 are pretty much completely incompatible, right? The only thing that they share is that they both execute x86 code, but the AMD64 does a much better job at it.
The problem goes a lot farther than aesthetics (although they did a good job of screwing those up, too.)
The problem is that RedHat has no qualms about releasing prerelease software and labelling it as "release". Granted, fontconfig adoption might have taken slightly longer than it has if RedHat had not pushed it so heavily in their distro, but the problem lies in things like RedHat using their own custom patches to a stable Qt version to add fontconfig/Xft2 support, and installing prerelease glibc versions that KDE hasn't been tested on, and other various immature practices.
The fact that they use incorrectly-sized icons, and then the icons don't scale properly, and make KDE look like ass, is only icing on the cake. Also, the fact that their Bluecurve desktop theme is really crappy doesn't help either.
And just for when you say "Well, why don't you do better?" - I have. See my homepage - I write KDE styles, and even though I've only released one, I have a few more that I'm currently working on. (As well as a few applications that are in various stages of development.)
So the complaints against RedHat's KDE are slightly deeper than "They use ugly icons!". And the fact that they choose a butt-ugly theme for KDE by default means that KDE looks butt-ugly by default, which is a serious usability nightmare.
I personally don't care if you're a GNOMEr or a KDEr, but RedHat has some serious quality assurance/control issues, and it's not just limited to KDE. KDE just happens to be a high-profile example.
I'd just like to point out that if you have any C++ experience whatsoever, learning Qt will take you much less time than "months". You can be productive with Qt within several days of starting to use it, if not several _hours_.
Please keep that in mind.
First off, his name is Clippy. Clippy is the DEVIL.
/me cries in the corner.
Second off, of course we have an answer to that. We've combined our most evil text editor (vi) with an annoying assistant... BEHOLD! VIGOR!
Yeah, it's evil. Yes. Evil.
This is for the K8/Sledgehammer/Opteron architecture - NetBSD runs in full 64-bit mode on it.
Yeah, but you have to deal with the limits that Apple gives you. What if you want ssh access? What if you want more than 500MB of space to store stuff? What if you want to upgrade the hard drive in the server? What if you like running your own servers and you don't really need the silly iDisk? .Mac makes a lot of sense for a lot of people, but for some of us, it's not the right answer, and that's ok. The fact that Apple's using open standards is enough for me, anyway.
Wrong.
Internet Explorer runs with Adminstrator privileges. So does Windows Media Player. And Microsoft Office. Including Outlook. The "finer-grained ACLs" on Windows NT-based OSes don't mean shit when the programs all get to run setuid root.
No, because if SCO/Caldera distributed the changes in the GPLed version of the source, they were giving permission implicitly for the code to be included - and if they're still selling it, which they are, then any and all of the code that "infringes" and is also included in their version of Linux is freely redistributable. I'm not a lawyer, but my uncle is. We've had a very lengthy discussion about this.
Personally, I would be surprised if IBM didn't bury SCO with something on the order of 517 patents that SCO has been infringing on of theirs - I honestly think that the only reason it's taking IBM so long to formulate their response is that they have that many patents to check and make sure SCO is infringing that it could take a little while to enumerate them and write them down. But that's just me.
Point 1: Any systems that Apple ships with a PPC970 in them will get "World class performance" on a par with a P4, if not handily spanking it.
Point 2: IBM makes all of the G3s that Apple currently ships. You buy an iBook? You get an IBM G3 inside. You buy an older iMac? IBM G3. So it's not like Apple would be moving to a new untested company who hadn't proven themselves to be capable CPU producers.
Point 3: The PowerPC 970 was designed with the same HyperTransport support as the Opteron. The same exact system. IBM is planning on making 4-way and 8-way PPC970 boxen to sell. Apple could easily do the same, and we're talking about performance that wouldn't just "compete" but blow away anything else except possibly the Opteron. Also, keep in mind that Altivec really does turn the tables in a LOT of cases... SSE2 is nice, but it hasn't shown itself to be nearly as easy/nice to code to, nor has it shown the startling difference with regards to performance that Altivec has.
All in all, my prediction is that a move to PPC970 is all but inevitable. Opteron would be interesting, but Apple is in the middle of a software changeover right now... there are still a few million MacOS Classic users to convert to Jaguar/Panther, you know. You tell all of your current users that their brand-new PPC hardware is actually obsolete, because new hardware will be x86-64 and all future applications will be x86-64, and you've just successfully cannibalized your own market and signed your death warrant.
Oh, and Konq is getting a ton of other neat features in 3.2 as well. :)
Not to mention a significant decrease in load time and a huge boost in performance. KHTML is now as fast as or faster than Gecko in my day-to-day browsing tests (usually beating it, but there are probably still a few oddball cases where Gecko might be a bit better/faster. I don't see them though.)
Well, of course.
It wouldn't be Slashdot if it were any other way, would it?
(Konq has been my main browser since before KDE 2 was released, but that's another matter.)
KHTML will rule the world someday! You'll see! You'll all see! MWAHAHAHA!
ummm.... maybe I should go back to bed.
The article was at Ars Technica, and it was about the Counter-Strike server, not the actual video game.
However, the 30% speed improvement was NOT over an Athlon. They took the 32-bit binaries, benchmarked them on the Opteron, and then they recompiled the code for the x86-64 target (without changing a single line) and benchmarked it again, and there was a 30% speed improvement.
That's pretty impressive if you ask me. Granted, the server side does most of the physics logic and such, and not graphics, but I'm optimistic about just how much the increase in raw CPU power is going to help gaming out.
Actually, the last time that I played around with ZSNES (at least 3 or 4 months ago) X3 did, in fact, work. (It's one of my favorite games of all time, so I always check to see if it's playable :)
And yes, I do own the original cartridge. It's sitting here in my SNES, plugged into my TV. However, my laptop is a lot more portable than my TV and SNES, so... yay emulation!
The difference is that we didn't write an ORB, because we didn't need CORBA. We wrote DCOP because we needed lightweight, fast IPC, which was only one of the many features of CORBA - and on a desktop, you won't be using most of the features of CORBA.
And what exactly is the benefit of having interoperability with the stock Java ORB in GNOME? What does that provide to the end-user? What components are being implemented in the Java ORB that are useful to us users?
What?
DCOP hasn't lost. It's still insanely useful for IPC and offers that IPC to users in ways that it's never been possible to use before.
Even if the backend for DCOP gets ripped out and replaced with D-BUS, DCOP hasn't lost, just gotten better. Since you haven't bothered to answer the question either, I'm going to assume that Mike was just trolling. The entire reason that we WROTE DCOP was because CORBA was ridiculously slow.
Slow to grok, slow to compile, and even slower to run. CORBA has plenty of neato advantages and features, but speed has never been one of them. DCOP was conceived to be a fast lightweight IPC mechanism for X-based desktops.
DCOP is no more bound to X11 than KDE or Konqueror[1] is. The only reason it was bound to it is because the message-passing backend was implemented using libICE - but that backend can be ripped out and replaced, say with D-BUS, and no applications will even need to be recompiled.
-clee
[1]: Note that Konqueror runs on the Linux framebuffer, and KHTML itself has been ported to a few non-X11 systems such as AtheOS/Syllable and MacOS X. Qt runs on Windows and MacOS X in addition to X11 desktops.
Oh?
Do you have specific benchmarks, or real data to back this up? I'm kinda curious, because I was under the impression that the only thing limiting DCOP's speed was ICE on X11 (libICE specifically). Do you have any links?
Well, it took slightly longer, but that also includes the packaging, the screenshotting, the uploading, and so on and so forth. You can download the new dotNET tarball from here or just go to KDE-look or c133.org and download from there.
Please, in the future, if you have any more such feature requests - don't hesitate to send me an email!
Congratulations! You have just convinced me to make the rounded corners a configurable parameter.
Give me about ten minutes.
-clee
I'd be willing to work for a company and do either consulting for a Windows-to-Linux shift or actually help with the shift. Drop me a line if you're serious.
I like C++ better. That's subjective, but I think that it's an easier way to make things work right.
He noted that there's really little difference between having constructors in a language, and making constructor functions instead; I disagree, but in the case of his argument saying that the function names were self-documenting, I pointed out that that's more necessary since the GTK+ documentation is rather lacking, and Qt's documentation is widely regarded as incredible.
That's all. I'm not changing the argument, just adding thoughts about documentation which are somewhat orthogonal to the discussion about language features.
If that's true, then PLEASE, point me to a single Bonobo object implemented in Python.
:)
Or Ruby.
Or Java.
Or SmallTalk. Or OCaml, LISP, Scheme, or Perl. Any one of them.
Where are they? Where is the "Implementing a Bonobo object in Python" tutorial? Where's the documentation? Where are the examples, the real-life apps using them?
That's my point. They don't exist, so pointing at KDE/KParts and saying "You have to use C++ for KParts!" is silly, because you have to use C for Bonobo (to implement, anyway. Unless I'm wrong - which, if I am, please do tell me.
Ah, but having documentation for the APIs makes all the difference.
:)
Self-documenting function names might be neat, but that's a nasty kludge for not having a well-designed API, IMHO. The Qt API docs are the best I've ever seen from ANY project, bar none. So you know exactly which constructors exist for QPushButton, what types they take, etc - there's no question about it, and you don't have to do any weird casting in order to get it to work right (which is necessary in C a lot of the time).
I've never used Eiffel, so I won't comment on that, but I really like the way that C++ constructors work; in any case, I agree that it's mostly a matter of syntax and semantics, but I think that the C++ way of doing it (having a 'new' keyword, class constructors, etc) is better and cleaner. Again, this is all very subjective, so you're free to disagree, but for new programmers... well, it depends on what language they learn first.
Keep in mind that KDE also has bindings for Python, Ruby, Java, Perl, and (Qt so far) even C#. We're not exactly lagging behind in the bindings race. Unless you consider Scheme and OCaml bindings to be important, of course... but then, I've heard that GNOME's bindings for these languages have lagged behind and not been updated as consistently as their more popular ones. YMMV.
I made reference to the real problem in another thread, but here goes:
Sure, I could write GNOME stuff in Python or Ruby or Scheme - but how many Bonobo objects are written in these languages? How reusable is my code going to be if I do this? Not very, I suspect. That's the whole crux of the matter.
That, and all of the language bindings are at a different state; the Python bindings are farther along than the Java ones; the Ruby ones still have a bit of maturing to do, last I checked, and the C# ones are brand-new (although they look to be surprisingly complete, which is neat). Still, I don't see anyone implementing any Bonobo objects in any languages other than C, which to me signifies that it's either impossible or not worth it.
I would check out gtkmm, except that I'm already very well-versed in Qt, and it'd be a waste of my time to learn GTK+. (That, and I personally think that Qt has a cleaner, better, nicer API, but again, that's semantics and a very subjective thing; most C coders, I presume, would much prefer to learn GTK+ than to have to learn C++ to use Qt).
Well, see, CORBA is (as far as I understand) used for both IPC and object embedding.
;) But for us, IPC is completely separate from object embedding, and I think that it makes sense that way.
In KDE, we've made a pretty wide distinction between the two, such that you can have IPC without needing object embedding; DCOP is our IPC mechanism, and as I've said, it works fairly well (and DBUS seems to have garnered a bit of interest among a few of our developers, so we may move DCOP to a DBUS backend at some point too).
For the object embedding part (the 'distributed object model' stuff that you CORBA guys seem so fond of) is exactly what KParts is for. From what I grok of GNOME, Bonobo is the GNOME version of KParts; although it might be that Bonobo has a couple of benefits that KParts don't, being that it has all of the CORBA tech behind it.
KParts, for us, solve the other half of the problem with regards to object embedding. Konqueror knows how to embed a KPart for viewing (say) a spreadsheet, or an HTML document, or a dozen other things. It knows how, thanks to KParts and XMLGUI, to merge the UI elements, so that if you're browsing your filesystem, you don't see menu options to increase/decrease the font size or a toolbar icon for indicating the HTTPS status of the connection.
KParts tech is also local-machine only, which may possibly be a disadvantage, but I still haven't seen any viable way to remotely access a Bonobo/CORBA object. And while it should be theoretically possible to write KParts in other languages, I haven't seen it done yet (just like I haven't seen anyone write any Bonobo objects in Python