It's not that a command-line interface to a CORBA stub is impossible - far from it, or so I'd hope.
It's that GNOME has no such standard command-line tool to access the stubs, and (apparently) no such standards for the stubs to comply to. There's no standard CORBA stub interfaces for their apps. So navigating through trees of CORBA stubs in GNOME apps from the command-line is currently impossible, or so I understand.
Well, it's still not possible for me to access those distributed objects from the command line.
I can tell my media player (Kiwi) to go to the next song with this command from a script, or the command line, or from another app:
dcop kiwi KiwiIFace nextTrack
Talking with a few GNOME developers, it seems that something this simple, this useful, is still not possible in GNOME (Please, correct me if it is! I hate being misinformed).
As far as the 'distributed' nature of CORBA: Can you show me how to take advantage of this? I can't find any documentation on the Net about it, and the APIs in CORBA are hopelessly complicated (even for me to understand, and I'm a developer...). If my Gnumeric object is on another machine, how will Evolution embed that Gnumeric object locally to show a spreadsheet? Is that even possible? IIUC, it's supposed to be, but I've yet to see it done.
The language-neutrality I'll give you, but in response to that: How many useful Bonobo parts are being implemented in Python? How about ruby? Or Perl? Or maybe Smalltalk, or Java? No? Why are they all in C, if the language doesn't matter? (Again, correct me if I'm wrong - but I've yet to see a Bonobo part implemented in C++, let alone any scripting language.)
In short, I find that the KDE technology gives us flexibility that we don't see in GNOME, and it works plenty fast enough for our uses, while also being easily accessible to new developers.
When I was adding new DCOP functions to Kiwi (having never used DCOP before) it took me all of twenty minutes to figure it out; once I had figured it out, adding the second DCOP function took five minutes. How long do you suppose it takes a new GNOME developer to get up-to-speed on using ORBit?
I don't know if you have ever been involved with KDE development, but I've been following it for 5 years now (maybe longer... I don't remember exactly when I started building from CVS).
Let me tell you what. Maybe it's not endemic of every CORBA implementation (hell, maybe even ORBit is unaffected by this) but MICO in particular is slow. When I say SLOW, I mean:
slow to compile
slow to run
slow to get up-to-speed with, API-wise
Before the actual KDE 2 release, before DCOP and KParts were ever invented, KDE used to use MICO for its CORBA implementation. We had cool technology called KOM/OpenParts, which was completely 100% based on CORBA. And it was slower than hell.
It took hours to compile KDE from CVS back then - kdelibs + kdebase was a 6-hour job on a top-of-the-line machine. It took minutes for Konqueror to start, and it was buggy as all hell, even after six months of bugfixing (including, iirc, a few patches being sent to the MICO guys to fix bugs in MICO as well).
Finally, after all of the problems with MICO had been enumerated, a couple of our developers claimed that they could come up with something better in a weekend. Were they being arrogant? Sure. Were they cocky? Absolutely. But were they right? Surprisingly, yes. (Actually, I seem to remember the initial DCOP implementation taking 4 days, but that's really just a long weekend.;)
As soon as DCOP and KParts were released, development on the 2.0 branch ramped up exponentially. We released 2.0 within months, as opposed to still being years away due to the incredible slowness and bugginess and complexity inherent in using CORBA for desktop communcation.
And the technology introduced back then is still going strong today. KDE 3.1 still has the same DCOP command-line tool, the DCOP API is still the same, and almost all of the programs' DCOP interfaces haven't changed. I doubt that any single one of these would be true had we stayed with CORBA.
(Sorry for the rant, but you have NO IDEA how much CORBA sucked for us, and I am 100% sure that it would suck equally as much, if not incredibly more, today.)
Uh... Harmony's been dead for a while now, unless someone forgot to tell me about its rebirth.
IIRC, it was officially over and done with when Qt went GPL, but it may have even happened when they adopted the QPL - my memory of the licensing issue is fuzzy, since it's never really mattered too much to me.
Well, this isn't about moving everything to use glib instead of the Qt-based equivalent data types at all (which is what several of the developers on kde-core-devel seemed to think) but simply about moving the copy of glib out of arts and into kdesupport. This way, we only have to keep kdesupport in sync with the latest glib stuff, and arts itself doesn't require updates when glib bugfixes are implemented.
This is just my take on it, though - I may be misinformed or just plain wrong, but that's how I understand it. As I said, this has nothing to do with porting KDE to glib or anything like that, merely making the dependency tree slightly more sane and cleaning up arts a bit.
I think that a lot of the problem with GObject is (in most KDE developers' minds) is that we feel it's a hack for C to help make OO programming available, where OO is much more readily available in other languages.
The OO paradigm wasn't around when C was designed, and C certainly is an awkward language to use OO in.
It's the difference between saying:
QPushButton *button = new QPushButton("Hello, world!");
In one case, you have clearly defined language-level constructs and rules about what happens when you use said constructs; using the 'new' keyword on any object means that the language will automatically call the constructor for the object in question.
So instead of having to write a x_button_new_with_specific_property function, you define a class with the properties, and the proper constructors (because C++ has rules about how constructors get called, instead of forcing the programmer to remember a name mapping for every _new function with every possible permutation of the _with_property names at the end).
I support GObject personally insofar as it is used for the language bindings, because programming GTK in ruby or python should be easy and fun and take full advantage of the OO properties of those languages; but for use in C? Thanks, but no thanks.
There's a relatively large thread going on in the kde-core-devel mailinglist about such interoperability efforts that you guys might be interested in, too... check out this thread for the whole story.
The short version is - arts, the KDE sound daemon, uses glib code internally, but the maintainer wanted to move the glib code to rely on an externally-installed glib (instead of maintaining a copy of glib in the arts distribution). Lots of developer confusion over this has ensued, but a lot of interesting discussion has also resulted. Check it out.
Heh. And yet in your sig, you link to ReactOS. Hmmm.
Did you actually read the article? This has nothing to do with foreground processes, and everything to do with making things more responsive for processes that are going to relinquish their locks more quickly. The only reason X is brought up as a demo is because (being a monolithic and single-process beast) it's easiest to notice when X is lagging behind a bit because of the (previous) sucky heuristics.
The double-whammy of Ingo's patch combined with Linus's little 6-liner is quite impressive. I've got a make -j3 running in my background right now, while I'm running KDE and using the XFree-supplied 'nv' driver (instead of the NVidia supplied one... haven't yet checked to see if NVidia has ported their driver to work with 2.5.x, or if it Just Does [TM]). I can move windows about with better responsiveness than my Win2K install gives me when it's just finished a huge task (compilation of a large project, exiting out of Counter-Strike). This is a very welcome improvement.
As a side note: Isn't it funny how the users with the higher Slashdot IDs seem to be more MS-friendly than those of us who've been here a while (with a few notable low-UID exceptions).
Couldn't you also use it to set style="display: none" instead? That'd take the ad right out, instead of leaving an ugly little 1-pixel box there (which I would probably notice, because I'm a bastard with a real attention to details like that).
Right. How about you try again? With the MySQL vhost backend for Postfix?
It doesn't work. The MySQL backend includes a column for the 'HOME' variable, but it horribly breaks Courier, which makes it useless. Messages stop showing up. End of story.
I can't set up per-user mail filtering with different tools (some of my users like maildrop, some still have working procmailrc recipes that they don't want to ever have to touch again, and that means not converting to maildrop), the MySQL backend is shitty and doesn't support per-user procmailrc files anyway (for vhosting setups, which is the only place it's really useful).
qmail really is the shit. It's a bit more finicky to install, yes, but the documentation for installation is good, and I've never had to touch a running qmail server except for the rare occasion when it ran out of disk space. qmail is very much a 'set-up and forget' technology; I have qmail servers that I haven't needed to patch for ANY sort of exploits for years.
Postfix is only slightly more flexible in some ways (for example, the MySQL backend) but those ways aren't difficult to integrate into qmail; it's just that nobody's bothered to do it yet. Also, djb's daemontools suite makes running Courier bearable.
Public FTP servers usually have the restriction that the user enter a valid email address, which the BSA's spidering/searching software faked in order to gain access.
Hell, isn't that illegal under the DMCA? They're circumventing a protection measure to gain access to digitally protected work. Heh. That'd be awesome, if someone would sue the BSA for breaching the DMCA...
Also, here in the US, it's very common to be charged a flat fee for internet service, such that one would pay (say) $400 a month for a guaranteed pipeline of 3Mbits (numbers are made up, but you get the idea.) Whereas, in other parts of the world, billing is much more commonly based on the amount of data transferred. Which means that if I host a server here, I pay for the line to it - no matter if the machine is accessed once or two million times in a month, whereas in other countries (especially Europe, including Germany), the difference between once and two million accesses is quite large, and may result in higher bills due to more data transfer.
My point is that the BSA wasted bandwidth, needlessly scared a sysadmin at a German university, and may have even violated the DMCA in doing so. Again... Wow, that was stupid of them.
"I've got an idea! Let's write scripts that will automatically log in on FTP servers, waste bandwidth, cost people money, and also do a shitty job looking for pirated software!"
Yeah, that's really bright. If I were operating any servers that had been raped by the BSA's scripts like this, I'd be extremely pissed off. They should realize that bandwidth isn't exactly free, especially not in countries != US.
I think his point is that, while Microsoft may not intentionally sell or otherwise barter user information (selling it to spammers, etc), their lack of security and the general shoddiness of their products, combined with the fact that even they don't keep all of their own servers up-to-date (see Slammer, recently, and Nimda/Code Red, previously), means that you can't trust your information's safety/privacy once it's on Microsoft's servers.
Not because Microsoft will do bad things with it, but because they haven't taken the appropriate measures to stop others from getting it and then doing bad things with it.
With Microsoft's track record for security, I wouldn't be surprised to read that someone had broken into their Passport servers and downloaded all of the Passport users' information. That's the point. Microsoft's intentions for your personal information may not be evil, but their complete apathy when it comes to guarding it is.
IE:mac has a ton of problems (slow speed, general bugginess, non-native "feel" under OS 9 OR Jaguar), but you can NOT fault its CSS compliance.
Aside from Safari (still in development and getting better every day), Konqueror (in CVS, much more compliant than even the 3.1 release), and Mozilla, IE:mac has some of the best CSS rendering available on any platform period.
It's one of the few redeeming qualities (if not the only one... hell, it's the only one that I can think of.)
They tried that, back in the days when Gil Amelio was running things, in case you don't remember.
It almost drove them out of business.
No, Apple's doing exactly what they should, and they're being extremely successful with it.
The thing is, the style of their machines is one of the selling points - it resonates with the art crowd, as well as the very rich, as well as the "I'm totally computer-illiterate and I don't care" crowd who just wants a machine that works. Their hardware isn't cycle-for-cycle competitive with x86 machines, so putting it in ugly boxes and charging less would kill them. End of story.
Take a look at their history sometime. Interesting stuff.
I could learn Linux. But you know what? I've used it enough to know it's not worth the effort. Why learn a cheap imitation of Windows that does less than Windows in a less userfriendly way when I could use Windows and do everything I want and more easily?
LOL
Wow, that's a good one. Because Microsoft isn'tcopying features from us, right? Because DOS is dead, and anything with a command-line is just DOS in disguise, right?
Hint: There are times when the command-line is flat-out better than any other interface. Period. And even Microsoft, evil bastards that they are, understands this.
The Linux desktop might not be better for the average user just yet, but we're not giving up and going home because we didn't win today. Tomorrow we'll be back, and there will be more. And the day after that, and so on. Maybe we'll never really "win" but we're a lot closer now than we were last year, and I've been able to say that for 4 consecutive years now. So I'm sleeping pretty easy at night.
Slashdot Mirror
I personally would be 100% in favor of this.
It's not that a command-line interface to a CORBA stub is impossible - far from it, or so I'd hope.
It's that GNOME has no such standard command-line tool to access the stubs, and (apparently) no such standards for the stubs to comply to. There's no standard CORBA stub interfaces for their apps. So navigating through trees of CORBA stubs in GNOME apps from the command-line is currently impossible, or so I understand.
I can tell my media player (Kiwi) to go to the next song with this command from a script, or the command line, or from another app:Talking with a few GNOME developers, it seems that something this simple, this useful, is still not possible in GNOME (Please, correct me if it is! I hate being misinformed).
As far as the 'distributed' nature of CORBA: Can you show me how to take advantage of this? I can't find any documentation on the Net about it, and the APIs in CORBA are hopelessly complicated (even for me to understand, and I'm a developer...). If my Gnumeric object is on another machine, how will Evolution embed that Gnumeric object locally to show a spreadsheet? Is that even possible? IIUC, it's supposed to be, but I've yet to see it done.
The language-neutrality I'll give you, but in response to that: How many useful Bonobo parts are being implemented in Python? How about ruby? Or Perl? Or maybe Smalltalk, or Java? No? Why are they all in C, if the language doesn't matter? (Again, correct me if I'm wrong - but I've yet to see a Bonobo part implemented in C++, let alone any scripting language.)
In short, I find that the KDE technology gives us flexibility that we don't see in GNOME, and it works plenty fast enough for our uses, while also being easily accessible to new developers.
When I was adding new DCOP functions to Kiwi (having never used DCOP before) it took me all of twenty minutes to figure it out; once I had figured it out, adding the second DCOP function took five minutes. How long do you suppose it takes a new GNOME developer to get up-to-speed on using ORBit?
Let me tell you what. Maybe it's not endemic of every CORBA implementation (hell, maybe even ORBit is unaffected by this) but MICO in particular is slow. When I say SLOW, I mean:
Before the actual KDE 2 release, before DCOP and KParts were ever invented, KDE used to use MICO for its CORBA implementation. We had cool technology called KOM/OpenParts, which was completely 100% based on CORBA. And it was slower than hell.
It took hours to compile KDE from CVS back then - kdelibs + kdebase was a 6-hour job on a top-of-the-line machine. It took minutes for Konqueror to start, and it was buggy as all hell, even after six months of bugfixing (including, iirc, a few patches being sent to the MICO guys to fix bugs in MICO as well).
Finally, after all of the problems with MICO had been enumerated, a couple of our developers claimed that they could come up with something better in a weekend. Were they being arrogant? Sure. Were they cocky? Absolutely. But were they right? Surprisingly, yes. (Actually, I seem to remember the initial DCOP implementation taking 4 days, but that's really just a long weekend.
As soon as DCOP and KParts were released, development on the 2.0 branch ramped up exponentially. We released 2.0 within months, as opposed to still being years away due to the incredible slowness and bugginess and complexity inherent in using CORBA for desktop communcation.
And the technology introduced back then is still going strong today. KDE 3.1 still has the same DCOP command-line tool, the DCOP API is still the same, and almost all of the programs' DCOP interfaces haven't changed. I doubt that any single one of these would be true had we stayed with CORBA.
(Sorry for the rant, but you have NO IDEA how much CORBA sucked for us, and I am 100% sure that it would suck equally as much, if not incredibly more, today.)
Uh... Harmony's been dead for a while now, unless someone forgot to tell me about its rebirth.
IIRC, it was officially over and done with when Qt went GPL, but it may have even happened when they adopted the QPL - my memory of the licensing issue is fuzzy, since it's never really mattered too much to me.
Well, this isn't about moving everything to use glib instead of the Qt-based equivalent data types at all (which is what several of the developers on kde-core-devel seemed to think) but simply about moving the copy of glib out of arts and into kdesupport. This way, we only have to keep kdesupport in sync with the latest glib stuff, and arts itself doesn't require updates when glib bugfixes are implemented.
This is just my take on it, though - I may be misinformed or just plain wrong, but that's how I understand it. As I said, this has nothing to do with porting KDE to glib or anything like that, merely making the dependency tree slightly more sane and cleaning up arts a bit.
The OO paradigm wasn't around when C was designed, and C certainly is an awkward language to use OO in.
It's the difference between saying:and:In one case, you have clearly defined language-level constructs and rules about what happens when you use said constructs; using the 'new' keyword on any object means that the language will automatically call the constructor for the object in question.
So instead of having to write a x_button_new_with_specific_property function, you define a class with the properties, and the proper constructors (because C++ has rules about how constructors get called, instead of forcing the programmer to remember a name mapping for every _new function with every possible permutation of the _with_property names at the end).
I support GObject personally insofar as it is used for the language bindings, because programming GTK in ruby or python should be easy and fun and take full advantage of the OO properties of those languages; but for use in C? Thanks, but no thanks.
There's a relatively large thread going on in the kde-core-devel mailinglist about such interoperability efforts that you guys might be interested in, too... check out this thread for the whole story.
The short version is - arts, the KDE sound daemon, uses glib code internally, but the maintainer wanted to move the glib code to rely on an externally-installed glib (instead of maintaining a copy of glib in the arts distribution). Lots of developer confusion over this has ensued, but a lot of interesting discussion has also resulted. Check it out.
Heh. And yet in your sig, you link to ReactOS. Hmmm.
Did you actually read the article? This has nothing to do with foreground processes, and everything to do with making things more responsive for processes that are going to relinquish their locks more quickly. The only reason X is brought up as a demo is because (being a monolithic and single-process beast) it's easiest to notice when X is lagging behind a bit because of the (previous) sucky heuristics.
The double-whammy of Ingo's patch combined with Linus's little 6-liner is quite impressive. I've got a make -j3 running in my background right now, while I'm running KDE and using the XFree-supplied 'nv' driver (instead of the NVidia supplied one... haven't yet checked to see if NVidia has ported their driver to work with 2.5.x, or if it Just Does [TM]). I can move windows about with better responsiveness than my Win2K install gives me when it's just finished a huge task (compilation of a large project, exiting out of Counter-Strike). This is a very welcome improvement.
As a side note: Isn't it funny how the users with the higher Slashdot IDs seem to be more MS-friendly than those of us who've been here a while (with a few notable low-UID exceptions).
Couldn't you also use it to set style="display: none" instead? That'd take the ad right out, instead of leaving an ugly little 1-pixel box there (which I would probably notice, because I'm a bastard with a real attention to details like that).
Just a thought. Checking out privoxy now.
Neat, thanks for the link (was searching the gtk-sharp list, but didn't see it).
Don't suppose we could see that 300-line C# code, could we? I'd be interested to see how easy it is. :)
-clee
Right. How about you try again? With the MySQL vhost backend for Postfix?
It doesn't work. The MySQL backend includes a column for the 'HOME' variable, but it horribly breaks Courier, which makes it useless. Messages stop showing up. End of story.
Because with the mysql vhost backend, Postfix doesn't allow per-user .forwards.
Postfix sucks.
I can't set up per-user mail filtering with different tools (some of my users like maildrop, some still have working procmailrc recipes that they don't want to ever have to touch again, and that means not converting to maildrop), the MySQL backend is shitty and doesn't support per-user procmailrc files anyway (for vhosting setups, which is the only place it's really useful).
qmail really is the shit. It's a bit more finicky to install, yes, but the documentation for installation is good, and I've never had to touch a running qmail server except for the rare occasion when it ran out of disk space. qmail is very much a 'set-up and forget' technology; I have qmail servers that I haven't needed to patch for ANY sort of exploits for years.
Postfix is only slightly more flexible in some ways (for example, the MySQL backend) but those ways aren't difficult to integrate into qmail; it's just that nobody's bothered to do it yet. Also, djb's daemontools suite makes running Courier bearable.
Public FTP servers usually have the restriction that the user enter a valid email address, which the BSA's spidering/searching software faked in order to gain access.
Hell, isn't that illegal under the DMCA? They're circumventing a protection measure to gain access to digitally protected work. Heh. That'd be awesome, if someone would sue the BSA for breaching the DMCA...
Also, here in the US, it's very common to be charged a flat fee for internet service, such that one would pay (say) $400 a month for a guaranteed pipeline of 3Mbits (numbers are made up, but you get the idea.) Whereas, in other parts of the world, billing is much more commonly based on the amount of data transferred. Which means that if I host a server here, I pay for the line to it - no matter if the machine is accessed once or two million times in a month, whereas in other countries (especially Europe, including Germany), the difference between once and two million accesses is quite large, and may result in higher bills due to more data transfer.
My point is that the BSA wasted bandwidth, needlessly scared a sysadmin at a German university, and may have even violated the DMCA in doing so. Again... Wow, that was stupid of them.
"I've got an idea! Let's write scripts that will automatically log in on FTP servers, waste bandwidth, cost people money, and also do a shitty job looking for pirated software!"
Yeah, that's really bright. If I were operating any servers that had been raped by the BSA's scripts like this, I'd be extremely pissed off. They should realize that bandwidth isn't exactly free, especially not in countries != US.
I think his point is that, while Microsoft may not intentionally sell or otherwise barter user information (selling it to spammers, etc), their lack of security and the general shoddiness of their products, combined with the fact that even they don't keep all of their own servers up-to-date (see Slammer, recently, and Nimda/Code Red, previously), means that you can't trust your information's safety/privacy once it's on Microsoft's servers.
Not because Microsoft will do bad things with it, but because they haven't taken the appropriate measures to stop others from getting it and then doing bad things with it.
With Microsoft's track record for security, I wouldn't be surprised to read that someone had broken into their Passport servers and downloaded all of the Passport users' information. That's the point. Microsoft's intentions for your personal information may not be evil, but their complete apathy when it comes to guarding it is.
Angry much?
You should read this link.
IE:mac has a ton of problems (slow speed, general bugginess, non-native "feel" under OS 9 OR Jaguar), but you can NOT fault its CSS compliance.
Aside from Safari (still in development and getting better every day), Konqueror (in CVS, much more compliant than even the 3.1 release), and Mozilla, IE:mac has some of the best CSS rendering available on any platform period.
It's one of the few redeeming qualities (if not the only one... hell, it's the only one that I can think of.)
They tried that, back in the days when Gil Amelio was running things, in case you don't remember.
It almost drove them out of business.
No, Apple's doing exactly what they should, and they're being extremely successful with it.
The thing is, the style of their machines is one of the selling points - it resonates with the art crowd, as well as the very rich, as well as the "I'm totally computer-illiterate and I don't care" crowd who just wants a machine that works. Their hardware isn't cycle-for-cycle competitive with x86 machines, so putting it in ugly boxes and charging less would kill them. End of story.
Take a look at their history sometime. Interesting stuff.
According to MicroSoft, anyone who implements the .NET interpreter will be able to run .NET software.
Therefore, despite their refusal to release source, they might end up being portable anyway.
Kind of like StarCraft works on Linux (through wine), even though Blizzard will never write a Linux version.
Closed source doesn't necessarily mean that the application will ONLY run on one OS. Keep that in mind.
I could learn Linux. But you know what? I've used it enough to know it's not worth the effort. Why learn a cheap imitation of Windows that does less than Windows in a less userfriendly way when I could use Windows and do everything I want and more easily?
LOL
Wow, that's a good one. Because Microsoft isn't copying features from us, right? Because DOS is dead, and anything with a command-line is just DOS in disguise, right?
Hint: There are times when the command-line is flat-out better than any other interface. Period. And even Microsoft, evil bastards that they are, understands this.
The Linux desktop might not be better for the average user just yet, but we're not giving up and going home because we didn't win today. Tomorrow we'll be back, and there will be more. And the day after that, and so on. Maybe we'll never really "win" but we're a lot closer now than we were last year, and I've been able to say that for 4 consecutive years now. So I'm sleeping pretty easy at night.