Centralization of game patch updates is interesting in that it means that game manufacturers may become inspired to put out shoddy first releases so that people need to go through the Update server to get the fixes that make things work... and if they didn't buy the title... Well, think about it.
Wouldn't it be easier, not to mention perhaps piss out your real customers less, to simply add online activation? No need to introduce bugs for the hell of it, nor ship too early. That way you get all players, not just those who have a low tolerance to bugs.
When it comes to package managers, SuSE also has much better network updates and doesn't require a paid subscription like Red Hat. The paid subscription is major bummer indeed.
Hmm, well I use SuSE 8 at home, but Red Hat at work, both by choice. When GNOME2 came out, I decided to give Red Hat 8 a try, and was very impressed. One of the things I liked about Red Hat was the RHN - the fact is that SuSEs online update thing hardly ever worked for me (and I know I'm not alone in that), and if there was a way to receive email notifications I never saw it.
In general package management is one of the weakest parts of SuSE IMO.
That assumes the two formats are simply different ways of describing the same thing, in which case, why not have a standard? The more likely situation is that Word has features other word processors do not, or implements the same ideas in very different ways. At that point, it's not just a quick XSLT anymore, it might involve far more advanced mapping and processing.
No, it simply allows multiple apps to use/dev/dsp. If two apps try and open the same device but get resource busy or something, then your card doesn't support hardware mixing (or your card does but drivers don't, very rare situation).
Linux is NEVER going to hit the #2 spot among those that need a professionally design GUI and consistancy and ease of use. Apple on the other hand is taking great steps to make certain they ARE the top of the list for usability by folks that need this purpose.
[snip]
That's quite amusing. Pretty much every audio app I've ever tried invented it's own utterly non standard GUI, sometimes just for the hell of it. If you'd done any real audio work, you'd know that ALL the main sequencers and plugins for them are full of GUIs skinned to look like sequencer racks, knobs (literally), bitmapped keypads and so on.
You know what? I never, ever, hear pro audio guys whining about how Cubase VST doesn't always use the standard widget toolkit of the OS, or how their soft synth is skinned to look like a rack mount.
So, you are the one talking "Bull Fucking Shit", not only is GUI consistancy way way overrated, but there's even a great deal of evidence these days that Apple couldn't give a rats ass about GUI consistancy - it's own apps regularly invent their own widgets, even duplicating the standard ones (which of course introduces bizarre ui quirks). Don't even go near the font preview pane, or.. dare I say it... brushed metal.
So if you're going to try the "Linux will never make it on the desktop because the widgets look different" line, at least try and sound credible about it. Maybe some people seriously care about this. Pro audio people clearly do not.
Er, I think perhaps you don't understand the difference between software mixing and hardware mixing. Software mixing is what is used when the hardware doesn't support it, Linux w/ OSS has been able to utilise this nearly right from the start.
In kernel mixing is where the kernel actually does the mixing calculations itself. That functionality doesn't actually need to be in the kernel, so they don't want it there.
Anyway, this is all moot, it seems that the ALSA guys have come up with a way to use direct writes to the soundcards DSP buffer to do software mixing. Maybe sound servers will just fade into obscurity?
OK, I CAN do that right now, using ESD, but it's a kludge that I'd like to see going away.
Or you can buy a soundcard that does hardware mixing and free up some CPU cycles at the same time. Both OSS and ALSA have dealt with cards that can do hardware mixing/resampling for some time now, for instance I can run many sound apps at once on my machine at work, all using OSS, because my card isn't a dirt cheap one.
Unfortunately, because Windows has provided "backup" software mix/resample functionality for so long, many manufacturers are simply doing without to get cheaper than their competitors. It's like the winmodem situation:(
On Windows, I believe DirectSound does software mixing in the kernel.... the Linux guys don't want all that kind of crud in the kernel and for good reason. So we need to mix in userland.
Last time I checked up on this (a few weeks ago) there was a big discussion going on kde-multimedia about this very issue. KDE is really the key point here, as now GNOME is moving to GStreamer they are basically isolated from what sound server is used.
The main sticking points seemed to be: JACK is cool for pro audio, but doesn't have network transparency and is Linux only. aRts just blows goats, and needs to be phased out. MAS == Unknown?? GStreamer is being blocked by a few developers who aren't happy with GObject. Then there's this thing called CSL which is supposed to wrap the whole mess up into YAAA (yet another audio api).
Basically, the situation is highly confused, and I don't know if we'll get anything good out of it:(
Oh, and just to make things even more fun, it seems that at some point ALSA may get the ability to route its audio via JACK, so apps that are unaware of the sound server in use could end up being mixed by JACK.
Personally I'd favour JACK (or Jack) here, because firstly it's been designed by the linux audio community for low latency etc, so clearly real audio apps will be using it. Having to switch sound servers because you want to fire up a sample editor is stupid. Secondly, it's light and small enough to be accepted by most people, ie it's not a CORBA driven multimedia framework.
The main problem seems to be lack of network transparency, which isn't really of great concern to most users at this time and could be added to Jack anyway.....
I've lost track of the number of times I've had to do the "upgrade tango" and install a dozen different packages just to satisfy the dependencies for a program I needed
That's why we have/need dep resolvers like apt. I rarely, if ever, hear Debian users complaining that dependancies are too complex. They don't need to care.
A better solution would be to replace automake with a totally new build system. We've been hacking around the deficiences of make for years, and the time when compatability with lame commercial unices form of make was an issue is long gone.
Something like SCONs perhaps, although I'm not sure python is the best language for this. Although it's possible, easy even, to write really ugly bash, it's a very good language for filing system manipulations, which is a large part of build management. There was another build system based on bash that was a LOT easier than autotools, but I can't remember what it was called!:(
In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes. Why can't someone make something like this for Linux?
A few reasons. Firstly, these programs are tremendously complex under the hood. Almost all generic ones (even light ones like NSIS) include their own scripting language. InstallShield 6 and up has used DCOM to provide remote procedure calls between the install script and the engine (ikernel.exe if you've ever wondered what that is). They do a lot of messing around under the hood in order to make things just work.
Even then, they are too primitive for Linux. For instance, they have only basic concepts of dependancies. The lack of proper dependancy management almost brought Windows to its knees in the mid-nineties. Simply packaging every dependancy inside one self-extracting archive is simply not possible on Linux in any scalable fashion, so we have to build dependancy resolvers like apt. Windows installers tend to be GUI only. And so on.
Now, systems like apt are pretty cool. When they work, they work really well. The problem is, that they tend to be built by distro projects, and then they are relatively tied to that distro. Apt as used on Debian for instance, is not the same as apt4rpm. URPMI is Mandrake, and emerge is basically tied to Gentoo, though I'm sure it could be generalised.
So, the real solution is not to build Windows style setup.exe files. The real solution is to make something like apt, but that can be easily used by everybody, so you rarely if ever come across software that doesn't use it.
There are two approaches to solving that problem. We're trying both at once. The first is to invent a new system, independant of the existing ones. See my sig. The second is to try and standardise key interfaces in a standards body, so that apt/urpmi/emerge and others can interoperate, and so you can plug distro-neutral packages into that framework. See here. Note - most of the activity so far related to that group has been off-list, hopefully there will be action starting in a few days.
I like using Linux, but even as a seasoned IT pro, the directory structure and "what goes where" of a *nix system still bugs me.
Agreed. The FHS is a laughably weak standard, with multiple potentially correct interpretations for parts of it.
Note that I don't have any real problem with names like usr, etc, opt - they are essentially meaningless except to programmers, which is how it should be, for users localised VFS systems which abstract and represent the data in the filestore are the way forward IMO.
Of course, that's assuming good old Hans Reiser doesn't tip the whole thing on its head with ReiserFS, right?;)
What Corel did, and I really find this unforgivable, was they got the brainiac idea to "sync" the two versions of the code base (X and window) by using wine! As a result wordperfect 2000 was basically an unusable piece of crap.
Apparently, I seem to recall reading this somewhere (interview?), there was an unreleased service pack which improved this by a huge amount. Basically, as has already been pointed out, Corel suffer attention deficit disorder. Their port was released before any of the developers thought it was ready.
On the other hand, they did pour resources into Wine, fixing many bugs, hiring some of the core developers, hosting the websites and so on. Gav State, who now runs TransGaming, originally worked for Corel.
I'd like to note that WineLib apps aren't necessarily hugely sucky. I've used some really slick ones. The problem is that they are (currently) quite hard to do well. Up until recently, they were a nightmare to even get building (much easier now).
In particular, expect to see a lot more of them in future, especially for specialist stuff. Probably not word processors, but for ie CAD software, business software, any non-consumer software basically. Every so often, there is a patch dump on wine-patches from a developer or team of developers who have been porting their app to Linux using WineLib and have fixed a few issues along the way.
I don't really see the problem. I pay taxes. Those taxes are used at least in part to buy big guns. I wish they weren't, but I can't stop that. It's just a part of living in society - we give some of the results of our work away, and it might be used for purposes of which we disapprove.
Far more likely is that somebody writes some free software, and then it's used in a proprietary product (but the GPL doesn't protect you because it's bundled, not linked, or whatever). That'd piss me off immensely, and although I could immediately stop it for future versions by amending the license, it would then not be free software.
Take that $250,000 and offer it to the developers if they will sign a contract to stop working on anything non-Microsoft. Those that refuse this offer will get a $250,000 bounty put on their heads. Either way, taking out the top 40,000 Linux developers will certainly put a fatal dent in the Linux roadmap.
Sure, until the next generation, eager to code cool stuff and maybe get a huge payoff to stop, replace them.
If Echelon is used fairly and honestly in these types of situations, then I will not complain one bit about the extraordinary secrecy of its network.
I think the main problem people have with Echelon is that the European Commision investigation into it concluded the US was using it for corporate/economic sabotage, for instance shortly after an executive of some big aerospace company talked about a bid they were making on a phone, a large american firm who was also making a bid changed their numbers to be slightly less than what the european one was bidding.
So, the worry is that when there aren't any terrorists to catch, it will be and has been used for other things.
You have said, "The main sticking point seems to be GObject, but I've yet to find a KDEer elucidate what is so bad about it, especially considering it was designed with language bindings in mind." and then you went on to state that GObject is scary.
Only scary for people who use it, or implement GObjects. That's why I don't get why KDE folks don't like it, people like Tim Jansen make bindings so they never have to touch it. So why is GObject a problem? It's a behind the scenes thing. That's what I don't get.
Regardless, your post does not in anyway explain how GObject makes it easier to reuse code then QObject.
GObject - LGPL licensing. Written in C, with mature binding frameworks to other languages. In contrast, the KDE->C bindings are very primitive, and nobody uses them. Designed from the ground up for binding to other languages - this was not a concern of the QObject designers. Qt is huge, GLib is not. That's a few.
Your Jabber client example has no relation at all to what we are talking about.
It has every relation, because it was about code sharing, which is what this boils down to.
As for the licensing of KParts that you take issue with I'd like to note your long and tortured hair pulling about Apple using an LGPL'd shared lib for the new browser. http://dot.kde.org/1041971213/
That's entirely irrelevant. I wasn't concerned about the technology, or even the licensing. I was concerned about peoples "apple can do no wrong" attitude, which I made very clear on several occasions. I wasn't against Apple reusing code, I was against people saying "Apple is so great!" when their long term goals are not the same as ours. It has no relevance to this discussion, which is about the technicalities of code sharing - I want to be able to easily share code with you guys, and the Wine team, and GNOME, and 3rd party products as well. So far, GObject is the best we have to that, too bad, we could do a lot better IMHO.
It doesn't really matter because I don't wish to convince you or any other GNOME developer to use QObject in GNOME. Have some respect and grant us the same understanding.
I don't want to force GObject on you for kicks, I don't really care what you use, as long as it's compatable with the rest of the world.
What frustrates me is people making a big issue of the fact that say GStreamer is based on GLib, even in the presence of good KDE bindings. Presented with a strong multimedia framework, designed for re-use, with active maintainers and developers who want to make things easy for KDE, why is what language it's written in even an issue? It should be a no brainer. But it's not, and that's a sad thing indeed.
Ok, now you admit that GObject is scary. No more posts on why C is just as good as C++ for this stuff.
You are, once again, completely missing my point. As you appear to consider me a foe for being concerned about the world outside of KDE, I'm not expecting you to really listen, but nonetheless I must make these points.
I have not said, OOP in GObject C is inherantly better than OOP in Qt/C++. I said it was more practical for the real world, because it makes it easier to reuse code. Big difference.
[sigh] Let me show you something. Let's take what is, IMHO, the best Jabber client for Windows, RhymBox, and break it down into its component parts:
Internet Explorer. Used to render the GUI and for much of the application logic (ie it's an IE DHTML application). Language: unknown.
MSXML: provides XML and XSLT facilities. Language: unknown.
ATE Jabber Engine. Language, unknown but appears to be at least in part written in Visual Basic. Until recently it used JabberCOM, written in Delphi, an OOP variant of Pascal.
Front end code: Langauage: JavaScript.
Backend code: better integration between the front end and Windows. Language: C++.
WSH: various scripting objects. Language: Unknown.
Virtually all pure (ie not written to be portable) Windows jabber clients use either JabberCOM or ATE as their jabber engine. There is little code duplication in this field.
Q: On Linux, how many Jabber or Jabber-capable clients reimplement their jabber engine?
A: All of them.
Despite the fact that code on Windows is predominantly closed source, RhymBox is way more modular, and reinvents the wheel far far less than is the norm on Linux, even for highly modular apps. In contrast, on a platform overflowing with freely available code, we have massive flamewars because framework foo is written in the "wrong" language.
What went wrong? What is the missing part of the picture here? Why do we blow goats at sharing all this code we write, and why do Windows developers do it all the time, and take it for granted?
They have COM. We have nothing like it. KParts fails the test on grounds of language and political neutrality, not to mention licensing (which is in fact a problem, despite the fact that you constantly deny this[1]).
I know you can bind stuff from QObject or GObject into other languages. That's not good enough. Firstly, it's at least partly manual. Secondly, it's one way - you can use KParts in Python, but you can't write them. You can write new plugins for GObject based systems in C++ if you so wish, but they cannot then be reused by C code (or other bindings).
The problem we have is that the usefulness of an object model is directly related to how much stuff uses it. Nobody wants to use an object model, no matter how cool it is, if there are no objects available through it. COM is ugly, but everything uses it, so by definition it is miles better than QObject, CORBA or anything else we have for that matter.
[1] The licensing issue is a red herring. People say, "nobody forces the GPL on you" - except if I have to use that in order to access some code, regardless of how that code is actually licensed, then you could say it is forced on me. That's not good enough, even if you ignore proprietary developers entirely.
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.
KParts and CORBA are worlds apart. KParts is for instance basically a wrapper around C++ class loading. It's basically limited to C++ (for implementing them). As I said before, network transparency (which has indeed been done with bonobo/corba) is neat and sometimes useful, in the same way that X transparency is neat and sometimes useful, but the biggest advantage is proper inter-process IPC based on an open and standard protocol. You don't have to use GNOME, nor even ORBit to use it, in much the same way that you don't have to use XFree or GTK to write X apps.
KParts, for us, solve the other half of the problem with regards to object embedding.
Well, sorry, I can't agree. KParts solves nothing unless you believe the world is only made up of Qt/KDE/C++ apps. It's not usable outside that area (ie by most stuff). In fact, Waldo Bastian was originally opposed to KParts when it was first being developed, on the grounds that it was basically a proprietary technology, regardless of how closed the code was. I can dig up the marc link if you like.
I think you're getting distracted by the network thing - "network transparent" really means it has a marshalling protocol, which is useful for all kinds of things, even in process calls (ie com between threading contexts).
So, maybe in future when we have this as-yet unknown "hub" system, it'll be inproc only.... that'd be a shame, in much the same way that dropping network transparency from X would be a shame, but it wouldn't be critical because we'd have DBUS or whatever to make up for it. Mostly however a language and desktop neutral set of rules and interfaces are necessary. Oh, lookie lookie, there is such a thing, it's COM, and then network transparency was bolted on later.
while it should be theoretically possible to write KParts in other languages....
I remain to be convinced about that. It basically involves loading Qt/C++ classes iirc. I'd be interested to know how you can create a KPart in a generic way (ie implementing my own interfaces) in another language without evil hacks.
You make a lot of good points. Let me try to address them.
Well, it's still not possible for me to access those distributed objects from the command line.
Well, in fact you can query them, but in general if you're poking objects from the command line this is more a case of scripting IPC than objects.
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).
If the media player exposed a CORBA/Bonobo object (i believe rhythmbox does), and if there was a bash "poke me" CORBA client (i don't think there is), then there'd be nothing really stopping you. But CORBA isn't so hot for DCOP style simple scripting - the recent threads on desktop-devel-list contain more about that.
As far as the 'distributed' nature of CORBA: Can you show me how to take advantage of this?
By distributed, I don't necessarily mean distributed between different physical computers. If you look at DCOM on Windows, it's most often used to marshal calls between different processes or threading contexts. It's rarely, if ever, used for network transparency. But as the technologies are practically identical.....
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.)
Most stuff in GNOME is C, because C is easy and that's what the developers know and like (just like, why is the media play in KDE in c++, when really that kind of thing is better off in python imo).
There aren't any Bonobo objects defined in Python (although there are some used) as far as I'm aware, simply because the GNOME CORBA efforts are seriously starved of manpower. It's a technology with much potential, after all, look at DCOM/ActiveX on Windows, which is very similar in ideas, but little usage. Partly that's due to it being complex, and due to lack of good working documentation. I only "got" CORBA after reading an (old) Bonobo/Python tutorial. I realised how easy it was to load and use objects, without having to care what they were written in. It was COM, but for Linux, and better! Unfortunately, the hill it has to climb for general acceptance is too steep. Eventually I'll let go, and realise that politically we probably have to start again with a neutral solution. We'd end up reimplementing CORBA under a different name, and it wouldn't be standards-based, but maybe it'd be better as well.
I'd note that a bigger problem is lack of good dependancy management. I'm firmly of the opinion that most desktop apps should be written in Python/Ruby/C# - not C++ nor C. The main problem is that for instance, Straw, an RSS reader using the GNOME/GTK python bindings, has a list of dependancies that is positively scary. The GNOME parts aren't so bad, but it needs bindings for all kinds of wierd database libraries and so on that have to be built separately. So, many people don't use it, cos they can't install it. That's one thing I'm trying to work on. Objects would have the same problem.
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.
Partly that's because KDE is C++ only. I think these C vs C++ arguments are pretty silly, neither of them are all that great for desktop apps, even games! Try frozen-bubble. It's written in Perl/SDL. Easy peasy.
How long do you suppose it takes a new GNOME developer to get up-to-speed on using ORBit?
Much longer, but it's apples and oranges. You can use CORBA to do DCOP style scripting, and also distributed (ie process/network-transparent) objects. You can't really use DCOP for such objects, not without huge, enormous pain. The whole DBUS vs CORBA thread in gnome is about that distinction.
In other words, Open Source is about destroying wealth... or specifically about preventing those who create the intellectual property from profiting from it.
That's confusing a lot of different economic concepts together. The first one is, "what is wealth?". There are quite a few definitions, let's take the simplest one. Wealth is how much money you have.
Clearly however, if you produce a creative work (the term intellectual property has been generalised and loaded down, so i'll try and avoid using it), one that can be used in the process of making money, you have two options - either sell it, in which case you generate money for yourself but potentially remove the availability of that work for people who cannot or will not pay the price, or it can be given away for nothing, in which case anybody can use it.
So, clearly we have two sides of the balance. The global wealth generated through the web is high. Large volumes of trade take place on it, both directly and indirectly, not to mention the benefits for society and culture as a whole. Most of the web runs on Apache. So, the global wealth generated by Apache is pretty high. If the creators of Apache had decided to sell it instead, clearly it wouldn't be as widely used, and so the wealth it generated would be far less. And today of course, many of those people are employed to hack on Apache (and were originally employed by ISPs etc to do so from the start), so they ended up receiving a slice of that global wealth as well.
So, I don't think it's right to think of wealth in terms of only how much you directly earned from selling it. Wealth is more complicated than that.
The second issue I have with your statement is that it's about preventing the creator from profiting from it. This is clearly untrue, see Cygnus Solutions, JBoss group Red Hat and so on for people who profit from (their knowledge of) free software. There are many other examples.
Part of my perspective comes from working in finance industry where I routinely encounter people making 7 figure salaries for doing nothing more than offering opinions.
I suggest you read the writings of Bernard Lietaers or George Soros. These former players are of the opinion that the worlds financial system is unsustainable, and that it's going to crash. These guys know what they're talking about, and I trust their opinions. If and when such a crash happens, overvalued opinions will be brought back into line with what they're actually worth. But anyway, that's OT.
These people love open source, because they can take *YOUR* work and use it to make more money. That way they can continue to have their 7 figure salary and not worry about sharing it with you.
Unfortunately not everything can be shared in this way. The software industry is sort of unusual in this respect, in that it's based on property rather than services. Everybody who writes free software knows that at some point, it'll probably be used in the persuit of profit. That's almost unavoidable.
I just don't understand why this self-destructive behavior is so appealing to some people.
Well a) because it's not self-destructive if you're smart about it, and b) because it seems the right thing to do. Just because it doesn't happen for everything in todays system, doesn't make it "less right".
Even if you were a KDE developer I would find such a statement extremely silly. I mean you are a GNOME developer and now you are worrying because KDE doesn't want to use GObject?
I am not a GNOME developer, merely an interested observer.
Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree.
Except they'd have good points, like harder to make language bindings and licensing. And for what it's worth, GNOME already has a C++ dependancy in the form of FAM, and if Ephy gets into the core (which the gnome project seems to be keen on), that'd be a core app written in C++. So, really, you can't draw comparisons here.
Yeah, I know GObject is scary. GObject with CORBA is even more scary! But it's the best thing we've got in terms of code sharing. QObject simply isn't shareable, not without huge pain that makes GObject look like a walk in the park. Not only just C++ lovelies, but licensing and such as well.
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:
Well, ORBit is something like 2-3x faster than DCOP iirc. ORBit still has painful C apis, but that's just a property of OOP in C I think, CORBA in for instance Python or some similarly high level dynamic language is pretty painless.
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.
Yes, I know. Unfortunately, the KDE guys wrote off CORBA completely, rather than writing off the implementation (mico) as being unsuitable for desktop usage. It's like people with X. "Oh no, it's hard to get anti-aliased fonts in X!!" or whatever, when what they really mean is "I don't like XFree the implementation". And so today we have ORBit, which is pretty light and fast. Is it perfect? Nooooo, no way. CORBA is still complicated. But with that complexity comes features - like the ability to write an object in one language/environment, and use it in others, both inproc and outproc.
I think we're confusing two things. You can use CORBA for DCOP style "poke me" IPC, but something like DCOP/DBUS seems to be better. You can also use it for distributed objects, something that KDE has nothing for. KParts is tied to Qt/KDE/C++/inproc only. DCOP is not suitable for distributed objects.
I'm talking mostly about distributed objects. They interest me. DCOP style scripting is cool too.
(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.)
Except it doesn't. Sure Bonobo has issues, but then it's more ambitious. See how useful COM/ActiveX is on Windows? That could have been CORBA on Linux. Now - now we have nothing, and are reduced to bickering about whether objects in C are good or bad:( [sigh]
Slashdot Mirror
Wouldn't it be easier, not to mention perhaps piss out your real customers less, to simply add online activation? No need to introduce bugs for the hell of it, nor ship too early. That way you get all players, not just those who have a low tolerance to bugs.
Hmm, well I use SuSE 8 at home, but Red Hat at work, both by choice. When GNOME2 came out, I decided to give Red Hat 8 a try, and was very impressed. One of the things I liked about Red Hat was the RHN - the fact is that SuSEs online update thing hardly ever worked for me (and I know I'm not alone in that), and if there was a way to receive email notifications I never saw it.
In general package management is one of the weakest parts of SuSE IMO.
That assumes the two formats are simply different ways of describing the same thing, in which case, why not have a standard? The more likely situation is that Word has features other word processors do not, or implements the same ideas in very different ways. At that point, it's not just a quick XSLT anymore, it might involve far more advanced mapping and processing.
Presumably because they already have an investment in hardware that they don't want to blow.
No, it simply allows multiple apps to use /dev/dsp. If two apps try and open the same device but get resource busy or something, then your card doesn't support hardware mixing (or your card does but drivers don't, very rare situation).
That's quite amusing. Pretty much every audio app I've ever tried invented it's own utterly non standard GUI, sometimes just for the hell of it. If you'd done any real audio work, you'd know that ALL the main sequencers and plugins for them are full of GUIs skinned to look like sequencer racks, knobs (literally), bitmapped keypads and so on.
You know what? I never, ever, hear pro audio guys whining about how Cubase VST doesn't always use the standard widget toolkit of the OS, or how their soft synth is skinned to look like a rack mount.
So, you are the one talking "Bull Fucking Shit", not only is GUI consistancy way way overrated, but there's even a great deal of evidence these days that Apple couldn't give a rats ass about GUI consistancy - it's own apps regularly invent their own widgets, even duplicating the standard ones (which of course introduces bizarre ui quirks). Don't even go near the font preview pane, or .. dare I say it ... brushed metal.
So if you're going to try the "Linux will never make it on the desktop because the widgets look different" line, at least try and sound credible about it. Maybe some people seriously care about this. Pro audio people clearly do not.
In kernel mixing is where the kernel actually does the mixing calculations itself. That functionality doesn't actually need to be in the kernel, so they don't want it there.
Anyway, this is all moot, it seems that the ALSA guys have come up with a way to use direct writes to the soundcards DSP buffer to do software mixing. Maybe sound servers will just fade into obscurity?
Or you can buy a soundcard that does hardware mixing and free up some CPU cycles at the same time. Both OSS and ALSA have dealt with cards that can do hardware mixing/resampling for some time now, for instance I can run many sound apps at once on my machine at work, all using OSS, because my card isn't a dirt cheap one.
Unfortunately, because Windows has provided "backup" software mix/resample functionality for so long, many manufacturers are simply doing without to get cheaper than their competitors. It's like the winmodem situation :(
Last time I checked up on this (a few weeks ago) there was a big discussion going on kde-multimedia about this very issue. KDE is really the key point here, as now GNOME is moving to GStreamer they are basically isolated from what sound server is used.
The main sticking points seemed to be: JACK is cool for pro audio, but doesn't have network transparency and is Linux only. aRts just blows goats, and needs to be phased out. MAS == Unknown?? GStreamer is being blocked by a few developers who aren't happy with GObject. Then there's this thing called CSL which is supposed to wrap the whole mess up into YAAA (yet another audio api).
Basically, the situation is highly confused, and I don't know if we'll get anything good out of it :(
Oh, and just to make things even more fun, it seems that at some point ALSA may get the ability to route its audio via JACK, so apps that are unaware of the sound server in use could end up being mixed by JACK.
Personally I'd favour JACK (or Jack) here, because firstly it's been designed by the linux audio community for low latency etc, so clearly real audio apps will be using it. Having to switch sound servers because you want to fire up a sample editor is stupid. Secondly, it's light and small enough to be accepted by most people, ie it's not a CORBA driven multimedia framework.
The main problem seems to be lack of network transparency, which isn't really of great concern to most users at this time and could be added to Jack anyway.....
That's why we have/need dep resolvers like apt. I rarely, if ever, hear Debian users complaining that dependancies are too complex. They don't need to care.
Something like SCONs perhaps, although I'm not sure python is the best language for this. Although it's possible, easy even, to write really ugly bash, it's a very good language for filing system manipulations, which is a large part of build management. There was another build system based on bash that was a LOT easier than autotools, but I can't remember what it was called! :(
A few reasons. Firstly, these programs are tremendously complex under the hood. Almost all generic ones (even light ones like NSIS) include their own scripting language. InstallShield 6 and up has used DCOM to provide remote procedure calls between the install script and the engine (ikernel.exe if you've ever wondered what that is). They do a lot of messing around under the hood in order to make things just work.
Even then, they are too primitive for Linux. For instance, they have only basic concepts of dependancies. The lack of proper dependancy management almost brought Windows to its knees in the mid-nineties. Simply packaging every dependancy inside one self-extracting archive is simply not possible on Linux in any scalable fashion, so we have to build dependancy resolvers like apt. Windows installers tend to be GUI only. And so on.
Now, systems like apt are pretty cool. When they work, they work really well. The problem is, that they tend to be built by distro projects, and then they are relatively tied to that distro. Apt as used on Debian for instance, is not the same as apt4rpm. URPMI is Mandrake, and emerge is basically tied to Gentoo, though I'm sure it could be generalised.
So, the real solution is not to build Windows style setup.exe files. The real solution is to make something like apt, but that can be easily used by everybody, so you rarely if ever come across software that doesn't use it.
There are two approaches to solving that problem. We're trying both at once. The first is to invent a new system, independant of the existing ones. See my sig. The second is to try and standardise key interfaces in a standards body, so that apt/urpmi/emerge and others can interoperate, and so you can plug distro-neutral packages into that framework. See here. Note - most of the activity so far related to that group has been off-list, hopefully there will be action starting in a few days.
Agreed. The FHS is a laughably weak standard, with multiple potentially correct interpretations for parts of it.
Note that I don't have any real problem with names like usr, etc, opt - they are essentially meaningless except to programmers, which is how it should be, for users localised VFS systems which abstract and represent the data in the filestore are the way forward IMO.
Of course, that's assuming good old Hans Reiser doesn't tip the whole thing on its head with ReiserFS, right? ;)
Apparently, I seem to recall reading this somewhere (interview?), there was an unreleased service pack which improved this by a huge amount. Basically, as has already been pointed out, Corel suffer attention deficit disorder. Their port was released before any of the developers thought it was ready.
On the other hand, they did pour resources into Wine, fixing many bugs, hiring some of the core developers, hosting the websites and so on. Gav State, who now runs TransGaming, originally worked for Corel.
I'd like to note that WineLib apps aren't necessarily hugely sucky. I've used some really slick ones. The problem is that they are (currently) quite hard to do well. Up until recently, they were a nightmare to even get building (much easier now).
In particular, expect to see a lot more of them in future, especially for specialist stuff. Probably not word processors, but for ie CAD software, business software, any non-consumer software basically. Every so often, there is a patch dump on wine-patches from a developer or team of developers who have been porting their app to Linux using WineLib and have fixed a few issues along the way.
Far more likely is that somebody writes some free software, and then it's used in a proprietary product (but the GPL doesn't protect you because it's bundled, not linked, or whatever). That'd piss me off immensely, and although I could immediately stop it for future versions by amending the license, it would then not be free software.
Sure, until the next generation, eager to code cool stuff and maybe get a huge payoff to stop, replace them.
Oh and BTW, what do you mean by a bounty?
I think the main problem people have with Echelon is that the European Commision investigation into it concluded the US was using it for corporate/economic sabotage, for instance shortly after an executive of some big aerospace company talked about a bid they were making on a phone, a large american firm who was also making a bid changed their numbers to be slightly less than what the european one was bidding.
So, the worry is that when there aren't any terrorists to catch, it will be and has been used for other things.
Only scary for people who use it, or implement GObjects. That's why I don't get why KDE folks don't like it, people like Tim Jansen make bindings so they never have to touch it. So why is GObject a problem? It's a behind the scenes thing. That's what I don't get.
Regardless, your post does not in anyway explain how GObject makes it easier to reuse code then QObject.
GObject - LGPL licensing. Written in C, with mature binding frameworks to other languages. In contrast, the KDE->C bindings are very primitive, and nobody uses them. Designed from the ground up for binding to other languages - this was not a concern of the QObject designers. Qt is huge, GLib is not. That's a few.
Your Jabber client example has no relation at all to what we are talking about.
It has every relation, because it was about code sharing, which is what this boils down to.
As for the licensing of KParts that you take issue with I'd like to note your long and tortured hair pulling about Apple using an LGPL'd shared lib for the new browser. http://dot.kde.org/1041971213/
That's entirely irrelevant. I wasn't concerned about the technology, or even the licensing. I was concerned about peoples "apple can do no wrong" attitude, which I made very clear on several occasions. I wasn't against Apple reusing code, I was against people saying "Apple is so great!" when their long term goals are not the same as ours. It has no relevance to this discussion, which is about the technicalities of code sharing - I want to be able to easily share code with you guys, and the Wine team, and GNOME, and 3rd party products as well. So far, GObject is the best we have to that, too bad, we could do a lot better IMHO.
It doesn't really matter because I don't wish to convince you or any other GNOME developer to use QObject in GNOME. Have some respect and grant us the same understanding.
I don't want to force GObject on you for kicks, I don't really care what you use, as long as it's compatable with the rest of the world.
What frustrates me is people making a big issue of the fact that say GStreamer is based on GLib, even in the presence of good KDE bindings. Presented with a strong multimedia framework, designed for re-use, with active maintainers and developers who want to make things easy for KDE, why is what language it's written in even an issue? It should be a no brainer. But it's not, and that's a sad thing indeed.
You are, once again, completely missing my point. As you appear to consider me a foe for being concerned about the world outside of KDE, I'm not expecting you to really listen, but nonetheless I must make these points.
I have not said, OOP in GObject C is inherantly better than OOP in Qt/C++. I said it was more practical for the real world, because it makes it easier to reuse code. Big difference.
[sigh] Let me show you something. Let's take what is, IMHO, the best Jabber client for Windows, RhymBox, and break it down into its component parts:
Virtually all pure (ie not written to be portable) Windows jabber clients use either JabberCOM or ATE as their jabber engine. There is little code duplication in this field.
Q: On Linux, how many Jabber or Jabber-capable clients reimplement their jabber engine?
A: All of them.
Despite the fact that code on Windows is predominantly closed source, RhymBox is way more modular, and reinvents the wheel far far less than is the norm on Linux, even for highly modular apps. In contrast, on a platform overflowing with freely available code, we have massive flamewars because framework foo is written in the "wrong" language.
What went wrong? What is the missing part of the picture here? Why do we blow goats at sharing all this code we write, and why do Windows developers do it all the time, and take it for granted?
They have COM. We have nothing like it. KParts fails the test on grounds of language and political neutrality, not to mention licensing (which is in fact a problem, despite the fact that you constantly deny this[1]).
I know you can bind stuff from QObject or GObject into other languages. That's not good enough. Firstly, it's at least partly manual. Secondly, it's one way - you can use KParts in Python, but you can't write them. You can write new plugins for GObject based systems in C++ if you so wish, but they cannot then be reused by C code (or other bindings).
The problem we have is that the usefulness of an object model is directly related to how much stuff uses it. Nobody wants to use an object model, no matter how cool it is, if there are no objects available through it. COM is ugly, but everything uses it, so by definition it is miles better than QObject, CORBA or anything else we have for that matter.
[1] The licensing issue is a red herring. People say, "nobody forces the GPL on you" - except if I have to use that in order to access some code, regardless of how that code is actually licensed, then you could say it is forced on me. That's not good enough, even if you ignore proprietary developers entirely.
KParts and CORBA are worlds apart. KParts is for instance basically a wrapper around C++ class loading. It's basically limited to C++ (for implementing them). As I said before, network transparency (which has indeed been done with bonobo/corba) is neat and sometimes useful, in the same way that X transparency is neat and sometimes useful, but the biggest advantage is proper inter-process IPC based on an open and standard protocol. You don't have to use GNOME, nor even ORBit to use it, in much the same way that you don't have to use XFree or GTK to write X apps.
Well, sorry, I can't agree. KParts solves nothing unless you believe the world is only made up of Qt/KDE/C++ apps. It's not usable outside that area (ie by most stuff). In fact, Waldo Bastian was originally opposed to KParts when it was first being developed, on the grounds that it was basically a proprietary technology, regardless of how closed the code was. I can dig up the marc link if you like.
I think you're getting distracted by the network thing - "network transparent" really means it has a marshalling protocol, which is useful for all kinds of things, even in process calls (ie com between threading contexts).
So, maybe in future when we have this as-yet unknown "hub" system, it'll be inproc only.... that'd be a shame, in much the same way that dropping network transparency from X would be a shame, but it wouldn't be critical because we'd have DBUS or whatever to make up for it. Mostly however a language and desktop neutral set of rules and interfaces are necessary. Oh, lookie lookie, there is such a thing, it's COM, and then network transparency was bolted on later.
I remain to be convinced about that. It basically involves loading Qt/C++ classes iirc. I'd be interested to know how you can create a KPart in a generic way (ie implementing my own interfaces) in another language without evil hacks.
Well, in fact you can query them, but in general if you're poking objects from the command line this is more a case of scripting IPC than objects.
If the media player exposed a CORBA/Bonobo object (i believe rhythmbox does), and if there was a bash "poke me" CORBA client (i don't think there is), then there'd be nothing really stopping you. But CORBA isn't so hot for DCOP style simple scripting - the recent threads on desktop-devel-list contain more about that.
By distributed, I don't necessarily mean distributed between different physical computers. If you look at DCOM on Windows, it's most often used to marshal calls between different processes or threading contexts. It's rarely, if ever, used for network transparency. But as the technologies are practically identical.....
Most stuff in GNOME is C, because C is easy and that's what the developers know and like (just like, why is the media play in KDE in c++, when really that kind of thing is better off in python imo).
There aren't any Bonobo objects defined in Python (although there are some used) as far as I'm aware, simply because the GNOME CORBA efforts are seriously starved of manpower. It's a technology with much potential, after all, look at DCOM/ActiveX on Windows, which is very similar in ideas, but little usage. Partly that's due to it being complex, and due to lack of good working documentation. I only "got" CORBA after reading an (old) Bonobo/Python tutorial. I realised how easy it was to load and use objects, without having to care what they were written in. It was COM, but for Linux, and better! Unfortunately, the hill it has to climb for general acceptance is too steep. Eventually I'll let go, and realise that politically we probably have to start again with a neutral solution. We'd end up reimplementing CORBA under a different name, and it wouldn't be standards-based, but maybe it'd be better as well.
I'd note that a bigger problem is lack of good dependancy management. I'm firmly of the opinion that most desktop apps should be written in Python/Ruby/C# - not C++ nor C. The main problem is that for instance, Straw, an RSS reader using the GNOME/GTK python bindings, has a list of dependancies that is positively scary. The GNOME parts aren't so bad, but it needs bindings for all kinds of wierd database libraries and so on that have to be built separately. So, many people don't use it, cos they can't install it. That's one thing I'm trying to work on. Objects would have the same problem.
Partly that's because KDE is C++ only. I think these C vs C++ arguments are pretty silly, neither of them are all that great for desktop apps, even games! Try frozen-bubble. It's written in Perl/SDL. Easy peasy.
Much longer, but it's apples and oranges. You can use CORBA to do DCOP style scripting, and also distributed (ie process/network-transparent) objects. You can't really use DCOP for such objects, not without huge, enormous pain. The whole DBUS vs CORBA thread in gnome is about that distinction.
That's confusing a lot of different economic concepts together. The first one is, "what is wealth?". There are quite a few definitions, let's take the simplest one. Wealth is how much money you have.
Clearly however, if you produce a creative work (the term intellectual property has been generalised and loaded down, so i'll try and avoid using it), one that can be used in the process of making money, you have two options - either sell it, in which case you generate money for yourself but potentially remove the availability of that work for people who cannot or will not pay the price, or it can be given away for nothing, in which case anybody can use it.
So, clearly we have two sides of the balance. The global wealth generated through the web is high. Large volumes of trade take place on it, both directly and indirectly, not to mention the benefits for society and culture as a whole. Most of the web runs on Apache. So, the global wealth generated by Apache is pretty high. If the creators of Apache had decided to sell it instead, clearly it wouldn't be as widely used, and so the wealth it generated would be far less. And today of course, many of those people are employed to hack on Apache (and were originally employed by ISPs etc to do so from the start), so they ended up receiving a slice of that global wealth as well.
So, I don't think it's right to think of wealth in terms of only how much you directly earned from selling it. Wealth is more complicated than that.
The second issue I have with your statement is that it's about preventing the creator from profiting from it. This is clearly untrue, see Cygnus Solutions, JBoss group Red Hat and so on for people who profit from (their knowledge of) free software. There are many other examples.
Part of my perspective comes from working in finance industry where I routinely encounter people making 7 figure salaries for doing nothing more than offering opinions.
I suggest you read the writings of Bernard Lietaers or George Soros. These former players are of the opinion that the worlds financial system is unsustainable, and that it's going to crash. These guys know what they're talking about, and I trust their opinions. If and when such a crash happens, overvalued opinions will be brought back into line with what they're actually worth. But anyway, that's OT.
These people love open source, because they can take *YOUR* work and use it to make more money. That way they can continue to have their 7 figure salary and not worry about sharing it with you.
Unfortunately not everything can be shared in this way. The software industry is sort of unusual in this respect, in that it's based on property rather than services. Everybody who writes free software knows that at some point, it'll probably be used in the persuit of profit. That's almost unavoidable.
I just don't understand why this self-destructive behavior is so appealing to some people.
Well a) because it's not self-destructive if you're smart about it, and b) because it seems the right thing to do. Just because it doesn't happen for everything in todays system, doesn't make it "less right".
I am not a GNOME developer, merely an interested observer.
Come on! How about you go and ask the gnome development list to use QObject and then report back how irritated you are with the small but vocal minority that might disagree.
Except they'd have good points, like harder to make language bindings and licensing. And for what it's worth, GNOME already has a C++ dependancy in the form of FAM, and if Ephy gets into the core (which the gnome project seems to be keen on), that'd be a core app written in C++. So, really, you can't draw comparisons here.
Yeah, I know GObject is scary. GObject with CORBA is even more scary! But it's the best thing we've got in terms of code sharing. QObject simply isn't shareable, not without huge pain that makes GObject look like a walk in the park. Not only just C++ lovelies, but licensing and such as well.
Well, ORBit is something like 2-3x faster than DCOP iirc. ORBit still has painful C apis, but that's just a property of OOP in C I think, CORBA in for instance Python or some similarly high level dynamic language is pretty painless.
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.
Yes, I know. Unfortunately, the KDE guys wrote off CORBA completely, rather than writing off the implementation (mico) as being unsuitable for desktop usage. It's like people with X. "Oh no, it's hard to get anti-aliased fonts in X!!" or whatever, when what they really mean is "I don't like XFree the implementation". And so today we have ORBit, which is pretty light and fast. Is it perfect? Nooooo, no way. CORBA is still complicated. But with that complexity comes features - like the ability to write an object in one language/environment, and use it in others, both inproc and outproc.
I think we're confusing two things. You can use CORBA for DCOP style "poke me" IPC, but something like DCOP/DBUS seems to be better. You can also use it for distributed objects, something that KDE has nothing for. KParts is tied to Qt/KDE/C++/inproc only. DCOP is not suitable for distributed objects.
I'm talking mostly about distributed objects. They interest me. DCOP style scripting is cool too.
(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.)
Except it doesn't. Sure Bonobo has issues, but then it's more ambitious. See how useful COM/ActiveX is on Windows? That could have been CORBA on Linux. Now - now we have nothing, and are reduced to bickering about whether objects in C are good or bad :( [sigh]