This leads to toolkit darwinism, which has left us with essentially GTK and QT as the two dominant toolkits. Imagine if X had been shipped with Motif as its native toolkit? Who the hell would use that in 2003?
Come now. Windows has shipped with a standard widget toolkit since its very first version, yet it has definately evolved since then.
Don't assume that had X got a built in toolkit, it would never have evolved. Given the extensibility of X it probably would have evolved nicely, in fact.
However, likewise you shouldn't assume that if X had a built in toolkit everything would use it. Of course, this would not be the case. Mozilla would still use XUL. OpenOffice would still use the VCL. Wine would still use its clone of win32 widgets. Some apps would still reinvent widgets for whatever reason (just as they do on Windows and MacOS X).
Toolkit compatability is best dealt with by standards, IMHO, rather than just moving them around....
Actually, your analogy is a good one. Government (and pseudo-government) agencies control the toll-roads. They will keep you off of it. And bypassing their controls will eventually get you some
Not in England. The roads are open to all, as long as you follow the highway code. There's no nonsense about people using "unofficial cars".
IM isn't exactly like your God-given right.
Neither is driving to work, but most people would get pretty annoyed if random car models started getting banned from the roads.
Take a few steps back, breath slowly, volunteer for an open-source IM network.
I co-admin theoretic.com, one of the oldest jabber servers around. I've been using Jabber since the days when 1.2 was still in testing. I've shown it to pretty much every friend who is in the slightest bit technical. Only two of them use it, on and off. The rest still use MSN. So please don't lecture me about how open source IM networks are going to cure the world, because I've got the t-shirt and can tell you that they only matter to people like us.
Look at the average user of free software. They most likely use a mix of free and non-free software. They usually pick the best tool for the job and go with it.
I'd check that statement if I were you. Most Linux users I know don't have any non-free software on their machine. The only non-free software I have on mine are various bits on win32 shareware and stuff that I use for testing and developing Wine - I don't actually *use* them.
I have a game too. Games don't really work as free software, but then you could probably argue that the underlying motivations for free software don't apply to games anyway, as they tend to be oneshot entertainments.
In fact he did once have at least one girlfriend, called Alix. She was a UNIX admin (surprise), and once remarked that it'd be cool if somebody named a UNIX kernel after her.
That's why the Hurd was originally going to be called Alix. Unfortunately some fool who was actually working on it decided a girls name wasn't geeky enough and that a dual-recursive acronym would be far better.
I think there is still a little part of the Hurd that is called Alix, but I don't remember which bit.
MSN has publicly announced that there will be licensing for their protocol - which is great by me. That ensurance that I'm using completely legal software is always a plus.
Hmm, wait. Since when do Microsoft licenses have any relation whatsoever to the law? They can claim only people with red hair can connect to MSN if they like, it alters the legal status of other people connecting to their network not one bit.
IM is not owned by any company yet, let alone MSFT. An Open alternative has a good position to beat the proprietary opposition, especially as it is quite divided already. Open Standards are the "in" thing right now.
Unfortunately, here on Earth, many people use IM to talk to non-geek friends who probably don't understand why you can't just use the "official client" anyway.
Really, posts saying "it's their network, they can do as they please" piss me off. It's like saying, "hey, this company owns the road network around where you live, they can do what they like! If they decide to ban your old Mini from the roads, just move somewhere else where they don't own the roads".
In other words, it's not a realistic proposition. I'd love to abandon MSN, but I can't without all my friends wondering why I don't talk to them anymore. Of course I could simply not use IM anymore to talk to these people (but as some live abroad it's not practical to phone so really I'd lose them), in much the same way that I could move to another country to avoid a company that bans my car from their roads.
These companies do have monopolies, they have monopolies on my friends IM accounts, and they knew perfectly well when they started giving this stuff away for free that this is what would happen.
I have no problem whatsoever with freeloading on their networks, I didn't want to use them in the first place, and if I need to break into their networks then I will do so (at the same time as trying to convince my friends to use Jabber).
Here's the situation with installing stuff on linux. Developers are hellbent against statically compiling things (in many cases for good reason).
Right. Let's just get this out of the way first - static linking is not the solution (not least because not all dependencies can be statically linked anyway).
So the "download a package and click on the icon" scenario will only work if clicking on that icon starts a program that does dependency checking, downloads dependencies off the internet, and then installs
That's exactly whay autopackage does. Well, almost. At the moment we don't do network retrieval, so if you're missing a dependency you have to drop it into the same directory as the thing you're trying to install. We're getting there though, slowly. It works for any reasonably sane distro (if it doesn't, it's a bug, so let us know).
This would be better, but not optimal, because you have to start downloading the package, wait for package to download, then start the install, then wait for the libraries to down load and install.
Correct. However, walk before you can run and all that.
It would be better to have act,act,wait,wait - same amount of time overall, but free's up the user to do something else (ie, workflow is controled by the user, not the computer).
autopackage has only one button for most of the install, "Hide", which [shudder] minimizes it to the tray. A suboptimal solution, but one we hope will encourage users to do something useful, like play games, while waiting for their program to install. In future, hidden mode will be the default.
Here's an idea. It is simular to how streaming integrates with the browser. Say we create a redirection file type whose contents is just the name (or url) of a debian package.
That works OK, but I think I have a better idea. Let's create a browser plugin that understands the Linux.desktop file format, can render PNG and SVG icons (not all that hard, the shlibs to do this are already installed for most users running kde or gnome) and so on. It displays an application launcher icon, just like the file manager would do, or the panel, or the menu....
Now the icon is drawn in grayscale. The user won't know what that means at first, but it shouldn't take too many encounters with this system for it to click - if it's grayscale, you're going to have to wait when you click it (because it's not locally installed). Users can click the launcher, and a pretty animation appears over it to let the user know something is happening. In a few seconds the installer UI appears, and asks (for instance), whether they have the root password, which subcomponents they want etc.
It only takes a few seconds for this screen to appear even on dialup because autopackage has a split design - the metadata that controls the install can be separated from the package payload and downloaded separately (well nearly, still a few bugs there). So, you just need to hang around for a few seconds, click "OK" and the window disappears - the icon gradually fades to colour as the package is installed.
All dependencies are calculated and retrieved behind the users back, while they get on with something else.
The install finishes. The program runs. They can of course drag the icon to their panel, menu, desktop, file manager, whatever. They can drop it onto a friends Gaim chat window, it appears the other end (as grayscale), the friend clicks it and the right package for them is downloaded.
Er, no. Glib makes programming C actually somewhat sane. It's still a pain in the ass, but sometimes it's the best choice.
Programmers have been writing utility libraries to help them since the dawn of time. Jody is right, it's pretty damn depressing when some people take fright at a utility library because it has a "g" in the name.
There aren't any compelling arguments against glib that I've seen. If glib isn't portable to your platform alreay then it's almost certainly easy to do. The other "arguments" I've seen basically revolve around the use of underscore_style, a style that's also used in the Linux kernel and parts of the STL, and the fact that it's C.
These people chose their language, and built tools to make their lives easier. If you, or other people, can't deal with that, then it's really pretty sad. You just end up making more work for yourselves...
Th en do a killall gnome-terminal to force it to reload the fonts configuration. You can now choose MiscFixed 10 as the terminal font, which gives you clear, crisp non-AA fonts.
Er, as a Wine hacker I think that's a terrible idea. You'd spend just as much time debugging Wine as it'd take to just write the program properly in the first place. I really would try the latest versions of GTK on Windows, they are pretty good these days. With GTK Wimp doing the skinning, and the last few wierd event/painting bugs fixed, it works pretty well.
I'm NOT saying that it's a bad thing that more people use Linux, just that the next 10,000 users of RH's pre-packaged, duh-whats-a-compiler will be substantially less of a pure good thing for MY Linux experience than the the first 1,000 kernel contributors were
What an incredibly arrogant attitude. I am not a kernel hacker, and if I can avoid it, probably never will be. When I first started using Linux, I didn't know C, yet today I hack on Wine, which is used by a metric ton of people, and am busy writing and designing autopackage, which from the feedback we're getting seems to be something that people want. It'll make it easier for luser types to use Linux.
Oh, and guess what. I use Red Hat 9, because I prefer getting stuff done to dicking about with my WM configuration. So sue me.
By your logic, I should never have been allowed in, because these people might *gasp* hassle you for tech support.
Let me make you aware of something. If it weren't for those legions of "lusers" out there, buying their Dell PCs and surfing MSN with Internet Explorer, it's highly unlikely most of us could afford a PC at all. The only reason I can have my own computer is because I can put together a decent little box for less than 500, and the only reason I can do that is because economies of scale caused by mass market acceptance make it cheap for me.
If those people didn't use computers, there would be no mass market, no economies of scale, and I wouldn't have a computer at all! I'd never have been able to learn C, hack Wine or write my software.
So, feel free to spit and vilify people who don't match up to your supposed guru-ness (though I really doubt you are as good a developer as you think you are), I for one will continue to enjoy cheap hardware and free software, and I won't bitch when newbies ask me questions. That's fair game, in my books.
Oh come on, please stop trolling with that garbage.
NZHeretic, you STILL don't explain why a GTK# desktop application NEEDS to use SOAP or web services, you just assume it does!
You also appear to be making the flawed assumption that it's possible to patent something that is otherwise unpatentable by covering the "interoperation" of components - yet again you do not deem it important to explain this point.
But there are other ways to reach the same end. Python + a UI toolkit is a biggie.
I think Python/PyGTK/PyGlade is great. But let's be realistic:
Python has no option for compilation, not to native code nor something that will be JITted. This has performance implications - yes, I know about Psycho.
Python has no optional static typing. There are PEPs for it, but as far as I know, so far none have been implemented.
The Python class libraries are inconsistant in style.
The Python syntax looks a bit wierd at first, to new developers.
Now Python has many other plus points, and I somewhat suspect the battle for the future of open source developers hearts (at least on Linux) will be between Python and Mono/C#. But, right now, for larger projects it's looking somewhat weak. It *could* be a viable competitor with some more work, but right seems to be mostly confined to smaller projects, or developers who don't feel the need for the safety net of type safety.
If they manage to get.Net/C# and all that to be the business standard, with your help, won't that make it easier for them to turn against the one remaining target?
I doubt it. They are a big company and OS vs server/class platform basically fall into different areas. The energy they are expending against Linux is certainly greater than what they are expending against Sun already.
Even if it is Linux that becomes the favoured platform for.Net, do you think that will stop MS from boasting to the heavens how great their new framework is? And all the pointy haired bosses will buy more MS stock and products...
The PHBs will buy into whatever is succesful and they think has a future in the market. If Microsofts tools are so much better than the open source equivalents, well, more power to them. We'll just have to do better.
If anything Mono will help avoid people being locked into.NET and therefore Windows. Now which would you prefer - the PHBs to buy Microsoft because they have to, or because they make the best tools? Hint: one is far easier to compete with than the other.
I'm sure Sun are no angels, but I happen to like both Linux and Java, so...
Right, they aren't. In case you hadn't noticed, up until recently it wasn't even possible to get the JVM for Linux without going through a massive EULA, downloading the >10mb file from a non-resumable location and so on.
Look at it this way, at least with.NET you'll have a decent free software implementation to work with.
My impression is that you are still perpetrating the CLR/Dotnet bait-and-switch policy, where the status of the CLR in terms of standardization and patent encumberances is used to misleadingly imply that the whole of Dotnet is similarly standardized and (supposedly) unencumbered by patents.
No, reread what he wrote. Miguel quite clearly stated, and he even has a pretty map to show it even more clearly, which parts are free of patents and which parts are not. This is common knowledge. It's in the FAQ.
Meanwhile, which parts of Java are patented? I dunno. I've never seen a map of it. Maybe none, maybe all.
In other words, you have not been able to progress or resolve the fundamental issue here in over two years, when similar discussions took place here and in other forums.
If by "the fundamental issue" you mean patent exemption from the entirety of the framework, then I guess they haven't. That's too bad, but it's worth remembering that any patents Microsoft do hold will almost certainly not be specific enough to only apply to.NET - the equivalent SOAP libraries for Python, Java, C, whatever, might well be covered too.
However, until such time as the IP risk has been adequately addressed, we would appreciate it if you refrained from further misleading the OSS community in this regard.
Who is "we"? I'm not feeling misled at the moment. All software carries risk of patents, indeed, there are so many that I've probably violated many in my life already.
To be frank, given that the closest the open source community has got to something like C# is perhaps Python, which isn't compiled and has no static typing, it's looking like the best alternative right now.
I haven't used Mono yet, and probably won't for some time, but at the moment as an open source developer I've looked at the risks of patents and decided that the risk is acceptable. Certainly as we have to clone.NET anyway for application compatability, the point is somewhat moot. Wine has been OK for a decade, so hopefully the same will be true of Mono.
How about every company that has written software for Windows? Microsoft first and foremost don't make money from backstabbing, they make money from selling people tools. If.NET runs on Linux, well, they may well see that as a Plan B for when the Windows cash cow gets whacked by Linux. If they are still the Number 1 vendor of.NET tools, resources, training and so on they still have a place in the market.
Because only a subset of.NET is halfopen, a great bit of.NET software won't run on linux anyways, which reduces the weight of one of the arguments for Mono significantly.
Look at the Wine project. Do you really think the fact that some APIs aren't ISO standards are going to stop people getting compatability? No, me neither.
Considering that a commercial QT license is not that expensive for businesses developing software compared to the labour cost
... sounds like you've been reading KDE News too much. Given a choice of two powerful toolkits, one that is fully supported in a clean, modern language (ie not C++) and is available for free, and the other which is not, there's really little competition. If you think.NET competes with Qt, you clearly have never worked in a language like C# or Java.
Am I? I've found that pkgconfig has a hell of a time trying to locate.pc files unless they are in/usr/lib/pkgconfig
It also reads an environment variable. Or, you could *shock* read the source and alter it, if you want other paths too.
But the tricks I know about there involve ugly symlink kludges all over the place pointing into and out of/usr, and still compiles will end up breaking if include files aren't found in/usr/include (solution: more links to kludge things, that don't really belong in any package but end up needed by them all).
Like I said, you're doing something wrong. I've never needed such cludges. Why don't you raise these issues on the Gnome mailing lists, maybe somebody can help you?
Not exactly what I'd call "clean", but GNOME zealots love it anyway. Can't get most of them to acknowledge the basic design flaws though.
So far I've not seen any evidence of "basic design flaws", only somebody who hasn't got things set up right, sorry.
Should GTK2 be installed into/opt/gnome? How about glib?
As they aren't a part of Gnome, probably not, but then Gnome isn't a monolithic set of libraries. Why draw arbitrary distinctions in the sand like that? That is what/usr is for. SuSE have this habit of putting KDE and GNOME in/opt, and I'm not sure why, when I used SuSE it just caused me grief for apparently no good reason.
The only way to make that work for non-gurus is putting all the stuff under/usr, and hoping they use --prefix=/usr because/usr/local won't mix well either.
Well, I have Gnome installed in/usr, and have compiled stuff that depends on it to/usr/local just fine, I'm not sure what doesn't mix well there.... it seems you are deliberately making things hard on yourself.
The reason it's split into lots of little packages is because distro packagers have explicitly said they prefer it that way, indeed I remember a debate about it on IRC one time when fcrozat, who works for Mandrake, said he found the smaller packages far more convenient because it made it simpler to push security updates. With one large package, you have to push the whole thing each and every time, which isn't so great for dialup users. While you may have disliked it for your distro, that's not the feedback they were getting from most.
If you can't get Gnome building into/opt, then you did something wrong. I've used Garnome to build and install gnome into many, many different prefixes, include/opt/gnome2, ~/.gargnome, ~/Source/garnome and so on. I'm not a Gnome hacker, nor a distro developer, I'm just a user, so if I can do it, why can't you?
Slashdot Mirror
Come now. Windows has shipped with a standard widget toolkit since its very first version, yet it has definately evolved since then.
Don't assume that had X got a built in toolkit, it would never have evolved. Given the extensibility of X it probably would have evolved nicely, in fact.
However, likewise you shouldn't assume that if X had a built in toolkit everything would use it. Of course, this would not be the case. Mozilla would still use XUL. OpenOffice would still use the VCL. Wine would still use its clone of win32 widgets. Some apps would still reinvent widgets for whatever reason (just as they do on Windows and MacOS X).
Toolkit compatability is best dealt with by standards, IMHO, rather than just moving them around....
Not in England. The roads are open to all, as long as you follow the highway code. There's no nonsense about people using "unofficial cars".
IM isn't exactly like your God-given right.
Neither is driving to work, but most people would get pretty annoyed if random car models started getting banned from the roads.
Take a few steps back, breath slowly, volunteer for an open-source IM network.
I co-admin theoretic.com, one of the oldest jabber servers around. I've been using Jabber since the days when 1.2 was still in testing. I've shown it to pretty much every friend who is in the slightest bit technical. Only two of them use it, on and off. The rest still use MSN. So please don't lecture me about how open source IM networks are going to cure the world, because I've got the t-shirt and can tell you that they only matter to people like us.
Well, if you accept the JSFs estimate of 10 million Jabber users that is. I find that figure slightly optimistic.
I'd check that statement if I were you. Most Linux users I know don't have any non-free software on their machine. The only non-free software I have on mine are various bits on win32 shareware and stuff that I use for testing and developing Wine - I don't actually *use* them.
I have a game too. Games don't really work as free software, but then you could probably argue that the underlying motivations for free software don't apply to games anyway, as they tend to be oneshot entertainments.
That's why the Hurd was originally going to be called Alix. Unfortunately some fool who was actually working on it decided a girls name wasn't geeky enough and that a dual-recursive acronym would be far better.
I think there is still a little part of the Hurd that is called Alix, but I don't remember which bit.
Hmm, wait. Since when do Microsoft licenses have any relation whatsoever to the law? They can claim only people with red hair can connect to MSN if they like, it alters the legal status of other people connecting to their network not one bit.
Remember. EULAs are not the law.
Unfortunately, here on Earth, many people use IM to talk to non-geek friends who probably don't understand why you can't just use the "official client" anyway.
Really, posts saying "it's their network, they can do as they please" piss me off. It's like saying, "hey, this company owns the road network around where you live, they can do what they like! If they decide to ban your old Mini from the roads, just move somewhere else where they don't own the roads".
In other words, it's not a realistic proposition. I'd love to abandon MSN, but I can't without all my friends wondering why I don't talk to them anymore. Of course I could simply not use IM anymore to talk to these people (but as some live abroad it's not practical to phone so really I'd lose them), in much the same way that I could move to another country to avoid a company that bans my car from their roads.
These companies do have monopolies, they have monopolies on my friends IM accounts, and they knew perfectly well when they started giving this stuff away for free that this is what would happen.
I have no problem whatsoever with freeloading on their networks, I didn't want to use them in the first place, and if I need to break into their networks then I will do so (at the same time as trying to convince my friends to use Jabber).
Right. Let's just get this out of the way first - static linking is not the solution (not least because not all dependencies can be statically linked anyway).
So the "download a package and click on the icon" scenario will only work if clicking on that icon starts a program that does dependency checking, downloads dependencies off the internet, and then installs
That's exactly whay autopackage does. Well, almost. At the moment we don't do network retrieval, so if you're missing a dependency you have to drop it into the same directory as the thing you're trying to install. We're getting there though, slowly. It works for any reasonably sane distro (if it doesn't, it's a bug, so let us know).
This would be better, but not optimal, because you have to start downloading the package, wait for package to download, then start the install, then wait for the libraries to down load and install.
Correct. However, walk before you can run and all that.
It would be better to have act,act,wait,wait - same amount of time overall, but free's up the user to do something else (ie, workflow is controled by the user, not the computer).
autopackage has only one button for most of the install, "Hide", which [shudder] minimizes it to the tray. A suboptimal solution, but one we hope will encourage users to do something useful, like play games, while waiting for their program to install. In future, hidden mode will be the default.
Here's an idea. It is simular to how streaming integrates with the browser. Say we create a redirection file type whose contents is just the name (or url) of a debian package.
That works OK, but I think I have a better idea. Let's create a browser plugin that understands the Linux .desktop file format, can render PNG and SVG icons (not all that hard, the shlibs to do this are already installed for most users running kde or gnome) and so on. It displays an application launcher icon, just like the file manager would do, or the panel, or the menu....
Now the icon is drawn in grayscale. The user won't know what that means at first, but it shouldn't take too many encounters with this system for it to click - if it's grayscale, you're going to have to wait when you click it (because it's not locally installed). Users can click the launcher, and a pretty animation appears over it to let the user know something is happening. In a few seconds the installer UI appears, and asks (for instance), whether they have the root password, which subcomponents they want etc.
It only takes a few seconds for this screen to appear even on dialup because autopackage has a split design - the metadata that controls the install can be separated from the package payload and downloaded separately (well nearly, still a few bugs there). So, you just need to hang around for a few seconds, click "OK" and the window disappears - the icon gradually fades to colour as the package is installed.
All dependencies are calculated and retrieved behind the users back, while they get on with something else.
The install finishes. The program runs. They can of course drag the icon to their panel, menu, desktop, file manager, whatever. They can drop it onto a friends Gaim chat window, it appears the other end (as grayscale), the friend clicks it and the right package for them is downloaded.
It's like appfolders, except it doesn't suck.
Programmers have been writing utility libraries to help them since the dawn of time. Jody is right, it's pretty damn depressing when some people take fright at a utility library because it has a "g" in the name.
There aren't any compelling arguments against glib that I've seen. If glib isn't portable to your platform alreay then it's almost certainly easy to do. The other "arguments" I've seen basically revolve around the use of underscore_style, a style that's also used in the Linux kernel and parts of the STL, and the fact that it's C.
These people chose their language, and built tools to make their lives easier. If you, or other people, can't deal with that, then it's really pretty sad. You just end up making more work for yourselves...
Quick tip for the terminal thing, add these two lines to your /etc/fonts/fonts.conf file:
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
Th en do a killall gnome-terminal to force it to reload the fonts configuration. You can now choose MiscFixed 10 as the terminal font, which gives you clear, crisp non-AA fonts.
Er, as a Wine hacker I think that's a terrible idea. You'd spend just as much time debugging Wine as it'd take to just write the program properly in the first place. I really would try the latest versions of GTK on Windows, they are pretty good these days. With GTK Wimp doing the skinning, and the last few wierd event/painting bugs fixed, it works pretty well.
Don't worry about mod points. A nice comment agreeing with me is great. A nice comment saying I might have changed somebodies mind is just the best ;)
Actually his real first name is Robert, Havoc is his middle name (iirc). Nope, I dunno why he flipped it ;)
What an incredibly arrogant attitude. I am not a kernel hacker, and if I can avoid it, probably never will be. When I first started using Linux, I didn't know C, yet today I hack on Wine, which is used by a metric ton of people, and am busy writing and designing autopackage, which from the feedback we're getting seems to be something that people want. It'll make it easier for luser types to use Linux.
Oh, and guess what. I use Red Hat 9, because I prefer getting stuff done to dicking about with my WM configuration. So sue me.
By your logic, I should never have been allowed in, because these people might *gasp* hassle you for tech support.
Let me make you aware of something. If it weren't for those legions of "lusers" out there, buying their Dell PCs and surfing MSN with Internet Explorer, it's highly unlikely most of us could afford a PC at all. The only reason I can have my own computer is because I can put together a decent little box for less than 500, and the only reason I can do that is because economies of scale caused by mass market acceptance make it cheap for me.
If those people didn't use computers, there would be no mass market, no economies of scale, and I wouldn't have a computer at all! I'd never have been able to learn C, hack Wine or write my software.
So, feel free to spit and vilify people who don't match up to your supposed guru-ness (though I really doubt you are as good a developer as you think you are), I for one will continue to enjoy cheap hardware and free software, and I won't bitch when newbies ask me questions. That's fair game, in my books.
NZHeretic, you STILL don't explain why a GTK# desktop application NEEDS to use SOAP or web services, you just assume it does!
You also appear to be making the flawed assumption that it's possible to patent something that is otherwise unpatentable by covering the "interoperation" of components - yet again you do not deem it important to explain this point.
I think Python/PyGTK/PyGlade is great. But let's be realistic:
Now Python has many other plus points, and I somewhat suspect the battle for the future of open source developers hearts (at least on Linux) will be between Python and Mono/C#. But, right now, for larger projects it's looking somewhat weak. It *could* be a viable competitor with some more work, but right seems to be mostly confined to smaller projects, or developers who don't feel the need for the safety net of type safety.
I doubt it. They are a big company and OS vs server/class platform basically fall into different areas. The energy they are expending against Linux is certainly greater than what they are expending against Sun already.
Even if it is Linux that becomes the favoured platform for .Net, do you think that will stop MS from boasting to the heavens how great their new framework is? And all the pointy haired bosses will buy more MS stock and products...
The PHBs will buy into whatever is succesful and they think has a future in the market. If Microsofts tools are so much better than the open source equivalents, well, more power to them. We'll just have to do better.
If anything Mono will help avoid people being locked into .NET and therefore Windows. Now which would you prefer - the PHBs to buy Microsoft because they have to, or because they make the best tools? Hint: one is far easier to compete with than the other.
I'm sure Sun are no angels, but I happen to like both Linux and Java, so...
Right, they aren't. In case you hadn't noticed, up until recently it wasn't even possible to get the JVM for Linux without going through a massive EULA, downloading the >10mb file from a non-resumable location and so on.
Look at it this way, at least with .NET you'll have a decent free software implementation to work with.
No, reread what he wrote. Miguel quite clearly stated, and he even has a pretty map to show it even more clearly, which parts are free of patents and which parts are not. This is common knowledge. It's in the FAQ.
Meanwhile, which parts of Java are patented? I dunno. I've never seen a map of it. Maybe none, maybe all.
In other words, you have not been able to progress or resolve the fundamental issue here in over two years, when similar discussions took place here and in other forums.
If by "the fundamental issue" you mean patent exemption from the entirety of the framework, then I guess they haven't. That's too bad, but it's worth remembering that any patents Microsoft do hold will almost certainly not be specific enough to only apply to .NET - the equivalent SOAP libraries for Python, Java, C, whatever, might well be covered too.
However, until such time as the IP risk has been adequately addressed, we would appreciate it if you refrained from further misleading the OSS community in this regard.
Who is "we"? I'm not feeling misled at the moment. All software carries risk of patents, indeed, there are so many that I've probably violated many in my life already.
To be frank, given that the closest the open source community has got to something like C# is perhaps Python, which isn't compiled and has no static typing, it's looking like the best alternative right now.
I haven't used Mono yet, and probably won't for some time, but at the moment as an open source developer I've looked at the risks of patents and decided that the risk is acceptable. Certainly as we have to clone .NET anyway for application compatability, the point is somewhat moot. Wine has been OK for a decade, so hopefully the same will be true of Mono.
How about every company that has written software for Windows? Microsoft first and foremost don't make money from backstabbing, they make money from selling people tools. If .NET runs on Linux, well, they may well see that as a Plan B for when the Windows cash cow gets whacked by Linux. If they are still the Number 1 vendor of .NET tools, resources, training and so on they still have a place in the market.
Look at the Wine project. Do you really think the fact that some APIs aren't ISO standards are going to stop people getting compatability? No, me neither.
Considering that a commercial QT license is not that expensive for businesses developing software compared to the labour cost
It also reads an environment variable. Or, you could *shock* read the source and alter it, if you want other paths too.
But the tricks I know about there involve ugly symlink kludges all over the place pointing into and out of /usr, and still compiles will end up breaking if include files aren't found in /usr/include (solution: more links to kludge things, that don't really belong in any package but end up needed by them all).
Like I said, you're doing something wrong. I've never needed such cludges. Why don't you raise these issues on the Gnome mailing lists, maybe somebody can help you?
Not exactly what I'd call "clean", but GNOME zealots love it anyway. Can't get most of them to acknowledge the basic design flaws though.
So far I've not seen any evidence of "basic design flaws", only somebody who hasn't got things set up right, sorry.
As they aren't a part of Gnome, probably not, but then Gnome isn't a monolithic set of libraries. Why draw arbitrary distinctions in the sand like that? That is what /usr is for. SuSE have this habit of putting KDE and GNOME in /opt, and I'm not sure why, when I used SuSE it just caused me grief for apparently no good reason.
The only way to make that work for non-gurus is putting all the stuff under /usr, and hoping they use --prefix=/usr because /usr/local won't mix well either.
Well, I have Gnome installed in /usr, and have compiled stuff that depends on it to /usr/local just fine, I'm not sure what doesn't mix well there.... it seems you are deliberately making things hard on yourself.
If you can't get Gnome building into /opt, then you did something wrong. I've used Garnome to build and install gnome into many, many different prefixes, include /opt/gnome2, ~/.gargnome, ~/Source/garnome and so on. I'm not a Gnome hacker, nor a distro developer, I'm just a user, so if I can do it, why can't you?
True, but ultimately they're the best I've got, and people who rewrite the browser strings are probably a very small percentage of the total users.
Gaim isn't GNOME integrated at all, the Gaim guys have a pathological fear of linking against libraries. It depends on GTK+, and that's it.