How is a service that requires you to use Windows and IE any worse than a service that requires you use to a Mac and iTunes?
Re:Sounds like a plan.
on
Qt On DirectFB
·
· Score: 4, Insightful
This is a myth, and an XFree86 developer, board member, and one of the founders seems to agree:
As has already been pointed out to you, said XFree86 developer has been out of touch for so long that he thought Red Hat hadn't contributed to X, and now works on Windows entirely doing AOL stuff. When he took part in the XFree-forum list, he got flamed, badly.
Nobody except people who use X over the network extensively are making claims such as yours.
Don't be so short sighted. Maybe the reason nobody uses network transparency on Windows is because it blows so many goats? Have you thought of that? Yet, Microsoft have still taken architectural backflips to make it work, see W2K Terminal Services etc. It's a lame, poor imitation of actual network transparency, but they sell it anyway.
Simply having worked in tech support, I can think of MANY times when being able to have an xterm launched to me, would have been a godsend, especially as said person could continue working while I also worked.
There is a HUGE project of people doing exactly what the above link says. Implementing a direct rendered GUI with an X layer atop for remote display
Which desktop uses that then? Cos AFAIK both MacOS X and Windows use a model similar to that of X internally. None of them are direct rendered.
People making claims that the UNIX SOCKETS for local display don't involve overhead haven't made their evidence available. if this is true, explain yourself.
Why don't you find out for yourself, instead of ranting on Slashdot? You know, there are indeed studies, performed under controlled conditions, that show the overhead of UNIX domain sockets is negligable. They even tried replacing them entirely with SHM segments at one point, but it made no difference. Domain sockets are one of the most heavily optimized IPC primitives in the kernel, and you are quite free to perform speed tests yourself. The only area that it makes any difference is when throwing large amounts of data through them, such as pixmaps (which is why we use the XSHM pixmap extension), and the memcpy may not be completed in the available timeslice. For small messages, ie the bulk of X traffic, there is no speed gain to be had.
There is real world proof that the DirectFB model is faster for local rendering
Er, that's so wrong. For most people, ie anybody without a Matrox G series card, it's far far slower.
until XFree86 either gets its own direct rendering model built into it for 2d rendering
.... which it has....
and all the bells and whistles that DirectFB has (alpha blending with hardware acceleration, desktop/screen resloution switching on the fly, etc)
..... which it also has.... oh, unless you mean the ability to pointlessly make entire windows semi-transparent so you can't read what's on them, an ability that's useful primarily for screenshots with hot babes in the background
you people claiming X's faults aren't with the protocol and implementation but with drivers are all blowing hot air.
There are faults in every area of XFree/X11, nothing is perfect. The protocol needs some changes, which are being worked on, the driver interface needs to be broken to support proper save unders, and the scheduler is a dog. Needless to say however, DirectFB isn't a perfect work of art either. It's certainly useful, but right now it's not even competitive in terms of speed or features for 90% of users.
I'm not bashing X here
LMFAO. Yes you are. You've made many, many assertions, that you would know were wrong if you had actually sat down for a couple of weekends and done some basic research into the matter, like I have done. I have read boring reports, mailing lists archives, and chatted to various people involved, and so I'm pretty sure the impressions I have are accurate. There is nothing wrong with X as a local rendering mode
No, the reason for the jump from 8.0 -> 9 was due to the introduction of NPTL.
For all I know, it may go from 9 to 10, because of the big changes in project direction - see here. But, when the major number changes, it's due to a major change, that much is certain.
There are no free software authoring environments. Flash is open as long as you have the Flash program, or maybe SWiSH, all of which are proprietary and mostly expensive.
In fact, the preamble is wrong. The Adobe plugin does not work correctly on Mozilla Windows or Linux. The reason, iirc, is that they used a non-frozen XPCOM based plugin API, which mozilla.org subsequently dropped, rendering their work useless. As you might imagine they were pissed, and didn't do another one.
I think the Mac Mozilla never had this plugin API, so the version of the plugin for that browser simply used the old netscape plugin API, which is severely limited.
It's a shame. A web app I wrote at work requires IE in parts, basically because we use the Adobe SVG plugin but Mozilla doesn't have a plugin API powerful enough to do the tricks IE can do. Maybe some day native SVG will catch up with what the Adobe plugin can do, which would be great.
SVG support in Mozilla has been around for years, literally. The reason it never got into Moz yet is for exactly that reason.
Last I heard, maybe they were going to support the static SVG mini-spec or something. I'd be surprised if they dropped the policy of not including half baked implementations now.
At least in many parts of the EU, the ability to reverse engineer for interop IS a part of the law, and contractual agreements cannot override the law in that way.
Look, anonymous coward, yes it has occurred to me that maybe the kernel developers didn't want to work on a source control system.
Nonetheless, I have jack all sympathy for that. In most projects, sometimes you hit obstacles and have to take a detour for a bit in order to solve your long term goal. We're doing it in my project, because our goal is not to make a nice framework for writing installers and packages, it is to make software installation on Linux easy. That means we have to solve problems with symbol version locking, desktop integration and so on.
When the Gnome and KDE projects decided they were going to write a desktop, they took detours into writing component technology infrastructure. It's not directly related, but it was a problem they needed to solve in order to write a good desktop.
So, the kernel developers need to look at what their goals are. Are they simply to write some nifty kernel components, or are they trying to produce something useful to the free software community as a wider whole. Which is more important, a slight increase in productivity today and getting screwed tomorrow, or long term stability?
If I was Linus, the answer would be obvious, and yes I absolutely would be willing to work on the tools I needed to do my job, if no suitable ones were available. If people didn't like the fact that kernel development slowed down during this period, then they had better damn help me, or take responsibility for the project so I could get on with something else.
In this case, the easy way out was chosen - we'll let this nice man give us his product for free, and that means we can carry on doing what we enjoy. They just forgot to think about the consequences of using this particular tool, and now things have gone pear shaped.
Well, I can't say I have much sympathy. You've got to keep the long view.
It's unfortunate that McVoy is being portrayed as such a demon in this story, he really isn't a bad guy. He has a family to feed, and so he has to protect his revenue stream.....
OK. I have no problem with that.
RMS is threatening that revenue stream directly by calling for people to create not just another app that does the same things, but one that uses BK's protocols. Obviously, that would kill sales of BK to non-OSS developers, and thus kill McVoys business.
Meep. Logic failure. That would kill his revenue streams only if the customers actually desired an alternative, and couldn't move to it, because they were tied down by the BitKeeper protocols. McVoy has said repeatedly that it cost bazillions of dollars and countless programmer hours to create BitKeeper, iirc he said specifically it couldn't have been done using the free software model - but if a bunch of presumably volunteer coders can produce something similar AND compatible, that makes his claim look rather shaky, doesn't it?
When you look at it that way, his response seems perfectly reasonable.
No it doesn't. He's explicitly saying that if people were to try and produce a replacement for his product, he would deliberately make it hard for his existing customer base to move off to it. That's not competition, that's lockin, and that's bad.
It should never have come to this. In every possible outcome of this scenario I can see, somebody will feel that they were screwed over.
Very few people buy the boxed sets. People are comfortable with cell phones, it's an entirely different market - there is plenty of competition and little lock in. People are aware of these facts.
Operating systems are different. The vast, vast, vast majority of people use whatever comes with their computer. Those who wish to try something different, are by definition not mainstream. The problems with the boxed sets are many - they are expensive and complex to produce, and are rapidly obsoleted at a rate most people would not be happy about.
Basically, with the increase in broadband penetration it becomes increasingly likely that if you want Linux, you either have, or know somebody that has a fast link, so you can download the ISOs.
I expect you will still be able to buy CDs of the distro, just that you will have to get them from online shops.
Anyway, IMHO this move makes sense. RHL is no longer a "product" as such, certainly not one that makes money. It would seem to make sense to make it more a community thing - after all, in terms of software freedom it's just as good as Debian.
I'd be a bit worried that it might stagnate though - I hope Red Hat still take a lead in developing it. Would BlueCurve have happened in a community driven distro? Probably not. Yet I still like it.
Now, CVS is less than perfect, but considering the entirety of FreeBSD is developed using it, as are many other HUGE projects, I think that's a bit rich. Certainly, if they needed the tools, then improving subv to the level where it worked for them would have been a good idea.
McVoy has really shot himself in the foot this time. Does he really think he's going to get much sympathy from people when he writes things like:
If you are trying to copy BK, give it up. We'll simply follow in the footsteps of every other company faced with this sort of thing and change the protocol every 6 months. Since you would be chasing us you can never catch up. If you managed to stay close then we'd put digital signatures into the protocol to prevent your clone from interoperating with BK.
That sounds waaaaaaaaay too much like Microsoft for me. I vote for Subversion. I guess the distributed repository things would be a problem though.
I mean, damn. That is openly hostile. I don't CARE if people are trying to write a competitor that can interoperate with out, those sorts of tactics simply aren't honourable.
Next time, when RMS warns about things like this, I for sure am going to listen carefully.
I used desktop mode. Remember you must install QuickTime first.
I tried playing it for a few mins, but for some reason the game wouldn't recognise my key presses, or maybe I was just operating the game wrong. The music was choppy, but DSound is b0rked here. The rest seemed to work OK. I may take a look at the keyboard thingy some time, as that seems to be the only real showstopper.
It's because if you dynamically link to a library, your program will not run if it isn't present (with its full functionality). Therefore you are creating a derived work, so GPL compatability is important.
Microsoft has traditionally been very flexible in terms of business models and ideas. I truly wonder if one day, they will become a valued member of the open source community like Red Hat or IBM is today (remember big bad old ibm?).
It could happen. I'm not going to rule it out, that's for sure.
Apple are not, and never have been, a threat to Microsoft, or anybody else for that matter. They've been around for over a decade - yet have always been the underdog.
The primary problem, I'd guess, for Apple, is business. Outside of a few specialised areas, you just don't get businesses deploying large numbers of Macs. The costs don't add up. I read somewhere most computers are in business - so.....
Believe me, the "attraction of developers" you speak of is not an issue. Those developers are not writing killer apps, it's software houses like Adobe, Quark and Apple themselves that are doing that. The new Apple developers are all busy either writing yet another Cocoa instant messenger or porting open source software written primarily by the far larger free software community. Microsoft has nothing to fear there either.
One thing that interests me is your assertion that OLE/DCOM is slower than XML based message passing.
As I'm working on Wines implementation of DCOM at the moment, this is surprising - I always assumed that being a binary level protocol, with native code marshallers, would mean that is was significantly faster than something that involved lots of text processing. Why isn't that the case?
You can still use static linking, if you so wish. You just have to make a dynamically linked version available as well. Some games do this, for instance.
Basically two licenses are incompatible if they say different things.
Let's take your example. You wish to link Xerces into a GPLd program. The Apache 1.1 license is incompatible with the GPL.
Firstly, let's take a look at why this is so. You can read it here. The FSF page says:
This is a permissive non-copyleft free software license with a few requirements that render it incompatible with the GNU GPL.
We urge you not to use the Apache licenses for software you write. However, there is no reason to avoid running programs that have been released under this license, such as Apache.
Exactly what these requirements are is not explicitly stated, but reading the license, it's probably the clause that says:
5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.
When you link your program with Xerces, you are creating a derived work. That's because, your app would not function if Xerces was not present. Exactly what happens in the case of plugins, I do not know.
But let's say you linked it and redistributed it. This would cause problems, primarily because the GPL basically says that you can do anything you like with the software, but you must do FOO if you modify and redistribute a derived work.
Being able to do anything you like, includes the ability to have the word "Apache" in the name. For instance, You may want to use it to load level data for an Apache helicopter simulation using Xerces, nonetheless, you would not be allowed to have the word "Apache" in the title anywhere without written permission from one organization - which may, or may not exist when you write this software.
Obviously in this case, the GPL says you can make any changes you like, including to the title, and the Apache license says you can't. So, by combining them together, you are basically telling people two contradictory things.
It's a slightly contrived example, and the Apache license does not cause great problems. But, as far as I understand it, this sort of thing is what makes licenses incompatible.
The BSD license is pretty simple. And it's equally simple to rule out for-profit use of your code, if that's your beef.
No it's not. Various licenses have tried to rule out "for profit" use, but the term is so vague as to be useless. Pico was rewritten to nano so it could have a free license, for reasons like that iirc.
The problem is, where do you draw the line? IF you use the software in a charity, that gets more donations this month than they spend because of efficiencies gained from using your software, is that them making a profit from your work? How about indirect profits?
The complexities of the GPL stem from its attempt to be "viral" and enforce the FSF's philosophy on other people.
I wonder if it's a troll, but am too tired to really care. The GPL is very simple, it's people who make it complex. If you actually read the damn thing, maybe some of the supporting essays as well, instead of relying on random Slashdotters or IRC dudes take on it, you realise that a lot of the things said about it, are simply untrue.
Unfortunately, this tends to cause harm to OSS in general, as many people just slap the GPL on their code because it's a popular "free" license, without really understanding or considering the consequence
Dude, I think implying that the GPL is popular because often extremely smart coders are sheeple is pretty damn rude. Has it ever crossed your mind that maybe most of these people actually know what they're doing, and decided that a copyleft license was the way to go?
And thus, it becomes easier "just to stay away from" lots of OSS code that might otherwise get used in more contexts were the license less murky -- or if another license altogether became popular.
You equate popularity of the code with success. Such thinking led to serious issues with the X consortium, and when considering the total value gained to society, the picture is not so clear aynmore.
Slashdot Mirror
How is a service that requires you to use Windows and IE any worse than a service that requires you use to a Mac and iTunes?
As has already been pointed out to you, said XFree86 developer has been out of touch for so long that he thought Red Hat hadn't contributed to X, and now works on Windows entirely doing AOL stuff. When he took part in the XFree-forum list, he got flamed, badly.
Nobody except people who use X over the network extensively are making claims such as yours.
Don't be so short sighted. Maybe the reason nobody uses network transparency on Windows is because it blows so many goats? Have you thought of that? Yet, Microsoft have still taken architectural backflips to make it work, see W2K Terminal Services etc. It's a lame, poor imitation of actual network transparency, but they sell it anyway.
Simply having worked in tech support, I can think of MANY times when being able to have an xterm launched to me, would have been a godsend, especially as said person could continue working while I also worked.
There is a HUGE project of people doing exactly what the above link says. Implementing a direct rendered GUI with an X layer atop for remote display
Which desktop uses that then? Cos AFAIK both MacOS X and Windows use a model similar to that of X internally. None of them are direct rendered.
People making claims that the UNIX SOCKETS for local display don't involve overhead haven't made their evidence available. if this is true, explain yourself.
Why don't you find out for yourself, instead of ranting on Slashdot? You know, there are indeed studies, performed under controlled conditions, that show the overhead of UNIX domain sockets is negligable. They even tried replacing them entirely with SHM segments at one point, but it made no difference. Domain sockets are one of the most heavily optimized IPC primitives in the kernel, and you are quite free to perform speed tests yourself. The only area that it makes any difference is when throwing large amounts of data through them, such as pixmaps (which is why we use the XSHM pixmap extension), and the memcpy may not be completed in the available timeslice. For small messages, ie the bulk of X traffic, there is no speed gain to be had.
There is real world proof that the DirectFB model is faster for local rendering
Er, that's so wrong. For most people, ie anybody without a Matrox G series card, it's far far slower.
until XFree86 either gets its own direct rendering model built into it for 2d rendering
and all the bells and whistles that DirectFB has (alpha blending with hardware acceleration, desktop/screen resloution switching on the fly, etc)
you people claiming X's faults aren't with the protocol and implementation but with drivers are all blowing hot air.
There are faults in every area of XFree/X11, nothing is perfect. The protocol needs some changes, which are being worked on, the driver interface needs to be broken to support proper save unders, and the scheduler is a dog. Needless to say however, DirectFB isn't a perfect work of art either. It's certainly useful, but right now it's not even competitive in terms of speed or features for 90% of users.
I'm not bashing X here
LMFAO. Yes you are. You've made many, many assertions, that you would know were wrong if you had actually sat down for a couple of weekends and done some basic research into the matter, like I have done. I have read boring reports, mailing lists archives, and chatted to various people involved, and so I'm pretty sure the impressions I have are accurate. There is nothing wrong with X as a local rendering mode
In a way they contributed even after dropping the product line. Gav State, who set up TransGaming, found Wine by working at Corel.
Chin up dude ;)
For all I know, it may go from 9 to 10, because of the big changes in project direction - see here. But, when the major number changes, it's due to a major change, that much is certain.
I would make one, but I'm busy with other stuff, and Sodipodi meets all my needs.
There are no free software authoring environments. Flash is open as long as you have the Flash program, or maybe SWiSH, all of which are proprietary and mostly expensive.
I think the Mac Mozilla never had this plugin API, so the version of the plugin for that browser simply used the old netscape plugin API, which is severely limited.
It's a shame. A web app I wrote at work requires IE in parts, basically because we use the Adobe SVG plugin but Mozilla doesn't have a plugin API powerful enough to do the tricks IE can do. Maybe some day native SVG will catch up with what the Adobe plugin can do, which would be great.
Last I heard, maybe they were going to support the static SVG mini-spec or something. I'd be surprised if they dropped the policy of not including half baked implementations now.
At least in many parts of the EU, the ability to reverse engineer for interop IS a part of the law, and contractual agreements cannot override the law in that way.
Nonetheless, I have jack all sympathy for that. In most projects, sometimes you hit obstacles and have to take a detour for a bit in order to solve your long term goal. We're doing it in my project, because our goal is not to make a nice framework for writing installers and packages, it is to make software installation on Linux easy. That means we have to solve problems with symbol version locking, desktop integration and so on.
When the Gnome and KDE projects decided they were going to write a desktop, they took detours into writing component technology infrastructure. It's not directly related, but it was a problem they needed to solve in order to write a good desktop.
So, the kernel developers need to look at what their goals are. Are they simply to write some nifty kernel components, or are they trying to produce something useful to the free software community as a wider whole. Which is more important, a slight increase in productivity today and getting screwed tomorrow, or long term stability?
If I was Linus, the answer would be obvious, and yes I absolutely would be willing to work on the tools I needed to do my job, if no suitable ones were available. If people didn't like the fact that kernel development slowed down during this period, then they had better damn help me, or take responsibility for the project so I could get on with something else.
In this case, the easy way out was chosen - we'll let this nice man give us his product for free, and that means we can carry on doing what we enjoy. They just forgot to think about the consequences of using this particular tool, and now things have gone pear shaped.
Well, I can't say I have much sympathy. You've got to keep the long view.
OK. I have no problem with that.
RMS is threatening that revenue stream directly by calling for people to create not just another app that does the same things, but one that uses BK's protocols. Obviously, that would kill sales of BK to non-OSS developers, and thus kill McVoys business.
Meep. Logic failure. That would kill his revenue streams only if the customers actually desired an alternative, and couldn't move to it, because they were tied down by the BitKeeper protocols. McVoy has said repeatedly that it cost bazillions of dollars and countless programmer hours to create BitKeeper, iirc he said specifically it couldn't have been done using the free software model - but if a bunch of presumably volunteer coders can produce something similar AND compatible, that makes his claim look rather shaky, doesn't it?
When you look at it that way, his response seems perfectly reasonable.
No it doesn't. He's explicitly saying that if people were to try and produce a replacement for his product, he would deliberately make it hard for his existing customer base to move off to it. That's not competition, that's lockin, and that's bad.
It should never have come to this. In every possible outcome of this scenario I can see, somebody will feel that they were screwed over.
Operating systems are different. The vast, vast, vast majority of people use whatever comes with their computer. Those who wish to try something different, are by definition not mainstream. The problems with the boxed sets are many - they are expensive and complex to produce, and are rapidly obsoleted at a rate most people would not be happy about.
Basically, with the increase in broadband penetration it becomes increasingly likely that if you want Linux, you either have, or know somebody that has a fast link, so you can download the ISOs.
I expect you will still be able to buy CDs of the distro, just that you will have to get them from online shops.
Anyway, IMHO this move makes sense. RHL is no longer a "product" as such, certainly not one that makes money. It would seem to make sense to make it more a community thing - after all, in terms of software freedom it's just as good as Debian.
I'd be a bit worried that it might stagnate though - I hope Red Hat still take a lead in developing it. Would BlueCurve have happened in a community driven distro? Probably not. Yet I still like it.
Care to elaborate? Or is this going to be a big surprise?
Now, CVS is less than perfect, but considering the entirety of FreeBSD is developed using it, as are many other HUGE projects, I think that's a bit rich. Certainly, if they needed the tools, then improving subv to the level where it worked for them would have been a good idea.
Unless you live in a country where reverse engineering for interop purposes is allowed, which makes Larrys EULA invalid. Like most countries, in fact.
That sounds waaaaaaaaay too much like Microsoft for me. I vote for Subversion. I guess the distributed repository things would be a problem though.
I mean, damn. That is openly hostile. I don't CARE if people are trying to write a competitor that can interoperate with out, those sorts of tactics simply aren't honourable.
Next time, when RMS warns about things like this, I for sure am going to listen carefully.
I used desktop mode. Remember you must install QuickTime first.
I tried playing it for a few mins, but for some reason the game wouldn't recognise my key presses, or maybe I was just operating the game wrong. The music was choppy, but DSound is b0rked here. The rest seemed to work OK. I may take a look at the keyboard thingy some time, as that seems to be the only real showstopper.
It's because if you dynamically link to a library, your program will not run if it isn't present (with its full functionality). Therefore you are creating a derived work, so GPL compatability is important.
Right you are it is.
Microsoft has traditionally been very flexible in terms of business models and ideas. I truly wonder if one day, they will become a valued member of the open source community like Red Hat or IBM is today (remember big bad old ibm?).
It could happen. I'm not going to rule it out, that's for sure.
The primary problem, I'd guess, for Apple, is business. Outside of a few specialised areas, you just don't get businesses deploying large numbers of Macs. The costs don't add up. I read somewhere most computers are in business - so.....
Believe me, the "attraction of developers" you speak of is not an issue. Those developers are not writing killer apps, it's software houses like Adobe, Quark and Apple themselves that are doing that. The new Apple developers are all busy either writing yet another Cocoa instant messenger or porting open source software written primarily by the far larger free software community. Microsoft has nothing to fear there either.
As I'm working on Wines implementation of DCOM at the moment, this is surprising - I always assumed that being a binary level protocol, with native code marshallers, would mean that is was significantly faster than something that involved lots of text processing. Why isn't that the case?
You can still use static linking, if you so wish. You just have to make a dynamically linked version available as well. Some games do this, for instance.
Let's take your example. You wish to link Xerces into a GPLd program. The Apache 1.1 license is incompatible with the GPL.
Firstly, let's take a look at why this is so. You can read it here. The FSF page says :
Exactly what these requirements are is not explicitly stated, but reading the license, it's probably the clause that says:
When you link your program with Xerces, you are creating a derived work. That's because, your app would not function if Xerces was not present. Exactly what happens in the case of plugins, I do not know.
But let's say you linked it and redistributed it. This would cause problems, primarily because the GPL basically says that you can do anything you like with the software, but you must do FOO if you modify and redistribute a derived work.
Being able to do anything you like, includes the ability to have the word "Apache" in the name. For instance, You may want to use it to load level data for an Apache helicopter simulation using Xerces, nonetheless, you would not be allowed to have the word "Apache" in the title anywhere without written permission from one organization - which may, or may not exist when you write this software.
Obviously in this case, the GPL says you can make any changes you like, including to the title, and the Apache license says you can't. So, by combining them together, you are basically telling people two contradictory things.
It's a slightly contrived example, and the Apache license does not cause great problems. But, as far as I understand it, this sort of thing is what makes licenses incompatible.
No it's not. Various licenses have tried to rule out "for profit" use, but the term is so vague as to be useless. Pico was rewritten to nano so it could have a free license, for reasons like that iirc.
The problem is, where do you draw the line? IF you use the software in a charity, that gets more donations this month than they spend because of efficiencies gained from using your software, is that them making a profit from your work? How about indirect profits?
I wonder if it's a troll, but am too tired to really care. The GPL is very simple, it's people who make it complex. If you actually read the damn thing, maybe some of the supporting essays as well, instead of relying on random Slashdotters or IRC dudes take on it, you realise that a lot of the things said about it, are simply untrue.
Dude, I think implying that the GPL is popular because often extremely smart coders are sheeple is pretty damn rude. Has it ever crossed your mind that maybe most of these people actually know what they're doing, and decided that a copyleft license was the way to go?
You equate popularity of the code with success. Such thinking led to serious issues with the X consortium, and when considering the total value gained to society, the picture is not so clear aynmore.