Tomorrow the DOJ can formally ask for the Expediatary Act and the judge can certify the case as meeting the Act's stipulations. Then, the Supreme Court has the opportunity to take the case, out of the district court's hand. You can bet this will happen too.
I sure hope you're right, because if Microsoft manages to flout the spirit of the Expediting Act like this it will be another sorry day for American justice. --
...Before the district court had a chance to employ the Expediting act, to move it directly to the Supreme Court. I saw something like this happen in my home province, B.C. - former premier of B.C. was being charged with a blatant case of insider trading, and the provicial court grabbed the case quickly, before the federal court could get it, so they could let him off with a wrist-slap. Of course, the Appeals court can't let anybody off, but they can sure weaken the case if they want to. This looks very, very sleazy. I think it's well worth scrutinizing how the Appeals court conducts itself in this case, and if strange things are done, I think very sharp questions should be asked as to motivations and allegiances. --
Re:Napster vs. The GPL
on
Napster Wars
·
· Score: 2
Can someone please explain the difference between music which is covered by copyright and software which is covered by the GPL?
The question is badly formed since the GPL is a *licence* governing the use of copyrighted material, so you are really comparing apples to.. err... apple seeds.:-)
Here goes anyway: the GPL guarantees your right to use the licenced intellectual property freely, including redistributing it, and forbids you from imposing new conditions on anyone you restribute it to. It is a guarantee of freedom. As such, it is in a completely different class from the conditions that the RIAA is trying to impose on the use and distribution of music.
[offtopic] Rob, there is a new BUG in slash that prevents offline composition. Error message: Invalid form key! Sheesh, this bug has been in for weeks, does this say anything to you about the need to make the slash code truly open????? --
Repeating the exact same rhythm accurately is a skill that takes years to master. It sure doesn't happen by accident.
Memory of rhythm fades rapidly. Unlike the patterns that grow on the ends of your fingers.
Supposing that people did have characteristic patterns - by ear, a trained musician can easily copy and conterfeit them.
On top of that, *nobody* is going to be happy about getting a retinal scan or anything remotely resembling that before they can play a piece of music they bought and paid for. This idea is so far out in left field that I can't see it as anything other than grasping at a straw - an act of desperation.
I was reading a fine piece today that sums up exactly my thoughts, better than I could. The problem is defined perfectly, and the reasons why recorded music is *never* going to be expensive and restricted again, like it has for much of the 20th century. (The solutions he proposes for compensating musicians in that piece are too utopian, IMHO, but other solutions *will* work.)
The RIAA and their toadies are on the run. They may be able to attack dotcom's and bring them to heel, but they can't successfully overwhelm the entire net.
Disclaimer: I would *never* encourage anyone to violate a copyright, even to hasten the demise of an evil cartel like the RIAA - instead, listen to the music of musician's that *want* you to, and don't unfairly restrict you. --
" Will Opera integrate with my desktop? In version 4.0, integration into the environments such as KDE, Gnome, CDE, and others will not be a priority. "
Now, now. You'll never beat Microsoft if that's your attitude.;-)
Actually, I think they just mean they're not putting in special code for docking and such at the moment. I think that's fair - lets see how KDE and Gnome evolve first before putting in such desktop-specific stuff. Almost all the applications I use now work just fine without any desktop-specific hooks and I'd rather the Opera guys concentrated on getting the browser itself right, just now. --
I was pleased to see my favorite browser buttons sitting there in the Eazel browser concept shot: Back, Forward, Up, Reload, Home, Stop. This is almost ideal (my opinion) except that Home and Stop positions should be reversed. Why? Because Home should just be one of a number of user-defineable "goto location" buttons. Yet we want the stop button to be always in the same position so we don't have to hunt for it.
The counter argument is that the "stop" button is in some sense a "final" kind of action, therefore should be on the right like a period at the end of a sentence. That is where it is in Netscape, and I find that a pain. --
I see mostly flames, moderated up, at the top level. There are two things that are wrong with this: first, people should not be flaming a new, open-source project, they should be providing constructive criticism or encouragement. Second, moderators are moderating according to how strongly they agree with an article instead of how well-written and credible the article is.
I'll weigh in with my opinion here: I think, that with the track record of the people involved in Eazel, we should give them all the support we can, regardless of whether we see their work as a threat to our pet project (it isn't - remember, it's all open-source and any of the good ideas from Eazel can be incorporated into our other projects). --
Nope. Once way to make hair, start with a wooden log light by a spot in the middle (this will be the sheen), stretch it out and alpha it a few hundred times onto a surface with slight longitudinal displacements and slight bending - now it should like a sheaf of wheat. Take the resulting texture and map it two or three levels deep onto a hair-shaped object, using an alpha map to give it shape and taper. On the head place an opaque map, darkened, of the same texture so you don't get any bald spots. Presto! It looks like hair.
This runs pretty efficiently in real time too, because you're just mapping a few 10's of textures to get the effect. The main disadvantage of this approach is that the highlights (sheen) don't move. A hack to make them move is to light the hair texture with a spotlight before alpha mapping it onto the hair polys.
You could add a bump map to the hair texture and you would get the moving sheen. --
Re:Sun may or may not get it
on
JavaOne report
·
· Score: 2
In what way is [Microsoft's] J-- better than the JDK?
Faster and more stable. Note: I detest Microsoft, Its business practices, and its founder and its founder's dog. Yet I'm not going to deny what's true.
The language specification and API cannot be made un-free.
Not the existing APIs, no, but the new APIs coming up, that's where the problem lies. That's why so many of us have a problem with Sun's behaviour at the moment. --
As for "fiddling with environment variables": yeah, you're completely right, setting two variables (KDEDIR and QTDIR) is just SOOOOO hard...
Ok, ok, you win, you win, actually there is no problem at all with obtaining compiling KDE apps such as kmail, and as I have better ways to spend my time I'll forget about it for another year, thanks for the advice. --
Re:Sun may or may not get it
on
JavaOne report
·
· Score: 2
You may not be grateful to Sun for designing Java, but I am.
And I am too, don't make any mistake about it. But I am not grateful for having been handed a proprietary fingertrap masqueradeing as a public standard.
You say "We could have have done that quite well by ourselves, thank you." Are you serious?
By "we" I mean anyone who is willing to contribute their language design work to the public. For example, Larry Wall or Guido Van Rossum (designer of Python). Yes, I'm serious.
How many more brilliant languages are you planning to design and implement?
You are wasting both our time by not reading before you reply. I wrote: "I don't care much about their code. I could have written it myself, and better." And I stand by that since I've done such things before. But I won't do it for Java because Java is not yet free, as in speech. Some others are willing to rewrite Sun's bloated, unreliable code, and my hat goes off to them. I'm not one.
I hope that my interests and Sun's will continue to coincide
You seem to have missed the entire point of "free" as in speech.
If you can reimplement Sun's JDK on your own, as you claim, then I would be truly grateful to you as well. Many organizations have tried, but Sun's JDK still seems to work better than the alternatives.
That's wrong. IBM's implementation is better. Microsoft's is too. Blackdown is darn good and is now intertwined with Sun's - Sun gets the benefit of expert programmers there, working for free. Kaffee is good too: though not yet caught up to the others, it probably will, and pass them. The problem is, even when Kaffee does catch up, Sun will intentionally move the goal posts. Are you aware that Sun charges big bucks for access to the Java compatibility test suite? Can you think of any good reason for this other than a desire to lock out the open source movement?
The licenses are clear. If I don't want the code under those terms, then I don't use it.
But that sounds so much like the situation with Microsoft. "If you don't like it, don't buy it". The problem is, Sun is trying to get us into a position where we *don't* have a choice, and I object to that seriously.
As a language, Python is just as good - it does what Java is supposed to do, and does it without the bloat. But Sun has inserted Java into the niche that Python could have occupied. Should we be grateful for that? --
Re:Sun still doesn't get it
on
JavaOne report
·
· Score: 2
Poor psychology. You aren't going to persuade Sun to make you a gift when you clearly will show no gratitude anyway.
So you think being nice is the way to get Sun to come across? Hey, maybe you're right. But don't bet your life on it. Notwithstanding the fact that much that much of our free OS originated at Sun, we already know that Sun is not being nice. Witness their dance around the standards bodies. So we should be nice, yes, but also, we need some powerful pursuasion.
Get this clear: Sun is not giving us anything by designing Java and giving it to us. We could have done that quite well by ourselves, thankyou. *We* are giving Sun something by elevating their trademark and reputation to a lofty position - by agreeing to make Java a true, public standard.
If Java is always going to be proprietary to Sun, then we will be no better off with Sun as master than with Microsoft as master. Do get that clear. As long as Java is proprietary, we are much better of to deny it the full status it seeks, and to work instead with things that are truly public standards: the Linux kernel, Python, TCP/IP, all of GNU, etc. etc. Java only becomes useful to us in the long run if Sun lets go completely, so don't think about being nice when so much depends on it. It's not a matter of being nice, it's a matter of what our long term goals are.
You evidently feel entitled to their code, and you're not.
I don't care much about their code. I could have written it myself, and better. It's the design, the standard, etc that I care about. Now if they want us to work on their code and make it better than it is, because frankly, you can see from the outside that it sucks, they will have to open it up the rest of the way.
As Larry Wall said, those of leasurely moral development often confuse giving with taking. Since giving is good, some think taking must also be good. Are you grateful even to the FSF?
What a question. Of course I am. FSF gave us the GPL. FSF doesn't play games with standards. Now ask any member of the FSF whether they're "grateful" to Sun.
By the way, when Java first came out I was an ardent supporter and I really saw it as the way forward. I believed what Sun said, about not trying to keep control of it and keeping only the trademark. That was quite a few years ago. I've had a chance to study the whole thing very closely. Did you? Do you know about the ISO and ECMA affairs? Have you read the Sun Community Source Licencse? Didn't think so. --
There's a AWT on GTK port on the SCSL site, but they don't intend to do anything with it.
Why the heck not? Because they're Sun, that's why, and they don't really care if linux users want a GTK version badly enough to write it for them.
They have no plans to compromise on SCSL to be more GPL friendly.
Is that a surprise? They will continue to have no such plans until they get it forced on them.
I asked "why did it take so long to support Linux?", the answer I got was "limited resources".
That's disingenuous. If they needed more resources they could easily have gotten them by making the SCSL GPL-compatible. The real reason is: "we thought Solaris needed a little help". --
"When we set out, our goal wasn't to convert the 400 million PC users from Windows to Red Hat Linux," Young said. "There are 6 billion people on the planet. Our goal is to build technology for the other 5.6 billion."
Perfect quote, sums up my feelings except for one thing: I'm sure glad that *I* was one of the 400 million Windows users that got converted in the slipstream. --
The only downside is that leaving MSIE in Windows will make it a lot harder for Mozilla to establish a strong base on the Windows platform. Not impossible, but a lot harder. I'd rather be faced with that problem, though, than have to deal with tying between web/media content and MSIE-as-media-player. For the same reason, Microsoft's media players should be left with the OS, not the apps/web company.
It's the best of two bad situations. Actually, I agree with those who think that the best solution would be to liquidate Microsoft and throw Bill Gates in the slammer, but that's just wishful thinking - it isn't going to happen, at least, not unless Bill is dumb enough to keep flouting the law, even after this rather clear demonstration of why you shouldn't. (starting to drift offtopic here, but oh well.) Actually, I think that's how it will finally play out. Remember all the speeding tickets, and he never learned, did he? Just counted on his rich lawyer dad to fix it all up and keep him on the road. I guess it's probably going to happen that way again, except on a much bigger scale, and he's utimately going to wind up doing time, just like Michael Milken did. It's strange what greed and ego can do to a man.
Clark's advice has little chance of making it into policy, however, even if senators like what they hear. The appeals court that will look at the landmark Microsoft breakup proposal largely will be charged with deciding whether the original ruling was legally correct, rather than changing individual details of the remedy.
IANAL, but that's not a correct interpretation. The details of the split, what goes where, aren't specified at all in the final judgement and in fact are to be proposed by Microsoft. Naturally, the DoJ will make it clear to Microsoft what it wants where.
Rob, there is a new bug in slash that prevents offline composing. If you d/c while on the composing page then when you reconnect you can preview, but trying to post results in: Invalid form key! This is seriously annoying. --
Microsoft was only able to bully others once they gained a monopoly.
That's not correct. Microsoft was in the bullying business long before it had a monopoly. Perhaps you don't remember how Seattle Computer was legally forced to give up their licence to sell MS Dos? There are countless examples of such behaviour. Heck, there's even a story that Bill Gates forced Paul Allen to give up part of his originally-equal share in Microsoft. --
"If you can prove that [innovation was stifled] I will shut up forever."
Unfortunately, this is not a provable statement so I'm not really going to debate it.
This is easily provable. In the findings of fact you see that Microsoft forced Intel to can its media software research lab with a "credible and fairly terrifying threat". He loses, and has to shut up forever (his suggestion). --
Yes, the list is longer than for Mozilla. OTOH KDE IS much more than one app, it's an environment/application framework.
This is exactly my point. I do not want to compile KDE. I want to compile kmail. So why am I force to compile 6 more apps and a good part of KDE and possibly QT? When we both know that it would be easy to provide to me the source code I need just to compile kmail? And after doing what you suggest, I wind up with the wrong version of kmail - one that runs under a beta desktop that I'm not using. Fixing bugs there doesn't fix the immediate problems. Downloading other snaps doesn't gives me an old frozen version that nobody is fixing bugs in.
Good gosh, man, can't you see that if people are complaining, there must be a problem? It takes a lot to get people to speak up on something like this. My original post was moderated up by four readers and not marked a troll by any, as it easily could have been. What does that tell you? And what does it tell you about how it will be perceived if you keep sticking to your guns instead of looking for a resolution?
By the way you left out the "fiddle with environment variables" step in your list, maybe others. --
Really, in what way is downloading & compiling KDE less easy than doing the same for Mozilla?
Instructions for building Mozilla:
1) Download the source tarball 2) Unzip into directory of your choice 3) cd into the directory and type: make 4) Go for coffee, come back in 40 minutes 5) Type./mozilla and go for a surf
Instructions for building kmail:
0) Look for a kmail.x.x.tgz. Find a very old one. Get confused. Hunt around with RPM. Figure out it's now part of kdenetwork. Look for kdenetwork.x.x.tgz. Find a version that's way too old. Learn you have to get it out of CVS, and you have to get all of KDE with it. 1) Explore kde.org. Find the part that tells you about cvsup 2) Download and install cvsup 3) Find the instructions about how to get download KDE via cvsup 4) Decide what parts of KDE you actually want to download. Get confused. Decide to download everything 5) Start the download and go to sleep 6) Wake up, discover you got disconnected, repeat as necessary 7) Get a cup of coffee, sit down, and start figuring out how to build it 8) Guess that you have to build QT first. Try to build QT in the obvious way. It doesn't work. Go back to instructions. Learn you have to link a directory first. Do it and try again. 8) Go out for a walk while QT builds. Come back, find it's still building. Play Mahjong. 9) Try to use the same strategy to build kdebase. It doesn't work. Try some more. It still doesn't work. 10) Go back to developer.kde.org. Learn about the build script. Download it. Fiddle with it until all the path variable are correct. It finally seems to work. Out of fear, decide to build everything. 11) Go to sleep while it builds. 12) Wake up. One of the first packages failed to build - it's because somebody checked in something ugly that broke the build. Start cvsup again. Go for another walk while the tree updates. Later that day, start the build again and go to sleep. 13) It builds this time. Now figure out how to install it, without conflicting with your current KDE installation. Go for a surf. Find a howto on this subject. Read it. Fiddle with paths. Now it works. 14) Run kmail from the new desktop
OK, I may have missed a couple of steps, or a couple of details, but that's essentially what has to happen. Umm, don't you think there's a difference in difficulty and time investment between the two procedures?
There ARE snapshots of libs and app-packages available, and the next set of those will even contain CVS information, so you just need to update a specific directory from that on.
But why can't I just download a tgz of the specific package I want to compile, like almost any other open source project? Then all I need are headers for kde and qt, and I'm up and hacking. There is a *radical* difference in the amount of work required to get started. Later, when I've got some code I'm proud of, I can figure out how to submit it to a maintainer. In other words, the normal open source process.
Package snapshots only eliminate a few of the steps I listed, and you still have to figure out which packages you need, which directories to put them in, and how to set the paths. This is a *lot* of work if you've never done it before.
Mainly, what I hear you saying is: there's no problem, it's just your imagination. But it's not my imagination, I've been through this. I know what the difference is between downloading and compiling "spruce", for example, versus downloading all of kde and qt just to compile "kmail". It amounts to *days* of extra work the first time you do it. It's not my imagination.
Perhaps I should rejoin the KDE mailing list and we can continue this discussion there. *But* I still have this nagging feeling - why should I do that, when the last time I did, I just got flamed? --
But there IS a KDE_1_1_STABLE branch in CVS! It's just that nobody used it after releasing 1.1.2 (besides some bug fixing).
Close, but no cigar. It has to be: KDE_1_2_STABLE CVS, and it has to be complemented with the individual apps also posted in simple tgz format. In addition, the individual apps in, for example, kdenetwork, should be available as individual tgz's. Why should you have to download and build 6 apps when you're only interested in one?
There's no particular difficulty or excessive work in accomplishing it: a script can simply be written to extract and zip the necessary branches of CVS, and to create the necessary new CVS trees (so development of the stable apps can proceed independently from the development tree, the way it does in the Linux kernel). The script just needs to be run *once* following each stable release.
The only thing I see getting in the way is core developers are not, at this point, willing to recognize that non-core developers have a big barrier to getting started - much bigger than most other open-source apps. Even mozilla is easier to download and compile than KDE, let alone individual KDE core apps which have to be dug out with considerable effort from a rather indimidating CVS tree. --
If you've got problems with the KDE development model, nobody's stopping you from forking the KMail code and integrating your changes.
Believe me, I seriously considered that and would have done it if I had not gotten fully committed to other projects. The need to spend several hours downloading the full CVS tree (analog modem) and fiddling with the build process was the final straw. (I've since done that, and it did in fact take a lot of time.) But why is it necessary to solve the problem by forcing a fork? Why not address the problem in the first place by having a well-defined fork a la the stable-vs-development strategy of the Linux kernel?
Personally, I think David's an awesome guy- he knows what's going on with the code, he has some really brilliant ideas about how to implement features in Konqueror, and he's never been rude that I've seen.
I must have caught him on a bad day then, and what I've seen recently supports your opinion. I still I think I'm right about the question I raised and that KDE app source code needs to be more accessible to developers outside the inner circle. It's a real problem that bugs aren't getting fixed in the stable releases and it's a problem that isn't hard to fix.
Please note that none of what I say reflects in any way on the KDE 2 development - I think that's working great, and there's fundamental progress going on there, particularly in object embedding techniques. And the attention to detail and useability in the KDE development has always impressed me. No doubt such things are in part due to David's skills. --
You wish that KDE core applications were developed out of CVS ? With the changes that happen in kdelibs quite often - to build a better API, and because of all the new stuff in KDE 2.0 (KParts, DCOP, XMLGUI, etc.) - this is almost impossible. What you gain from having apps in CVS is that they can be fixed by many people, especially those who change kdelibs. Out of CVS, it's up to the author to fix his app to cope with the changes, and _that_ can be piss him off a lot, obviously.
I realize that this is not an easy problem. But there is a better solution than hiving off all development into the CVS and core team. In short, there should be a stable (1.1.2) and a development tree (1.x.x) just like the Linux kernel. The stable tree should actually be a number of trees, with each core app having its own tree. And also a zipped snapshot, so an interested developer can grab it and immediately compile it with no fuss or muss. Only after that the developer needs to put in the extra work to install cvsup and sync up to the latest tree, the mailing list, the maintainers, etc.
The stable trees can be maintained by a completely different set of developers - there will be no shortage of volunteers And so, no additional load on the core developers.
This is not about "controlling", this is effectively about helping....
Yes, of course, but sometimes the cure can be worse than the disease. Sometimes the first cure you think of isn't the best one, even if it seems to help.
To answer the more personal comments...
The personal comments were not necessary, and I apologize.
...KDE is definitely nobody's fiefdom.
I was referring strictly to the mailing list.
...the idea of developing core apps out of CVS really doesn't make much sense. You want to "open more" the development by making it private ?
I don't see how any of my remarks could be interpreted that way.
About KDE 2 apps that are not in CVS : from 1.91 onwards, they should be able to compile and run on top of KDE. The API shouldn't change anymore. No need to wait for the official 2.0.
That's nice, but the API is going to change again in the future (I hope! Ossification is bad) and the same problems will come up again.
Finally, I'm not a paid fulltime developer... yet.
Oooh, this is going to cost me karma as trolling, but...
How is this all-inclusive, single-source applications/OS environment any different than, say, Windows and Office?
You may be surprised at how much support you get. Disclaimer: I *use* KDE every day and I think it's great. I use lots of KDE mainline applications and lots of what I'd have to call "3rd party" applications. (though I probably use even more Gnome/GTK applications, running them from the KDE desktop.)
I have some experience compiling KDE out of CVS, have done a small amount of KDE/QT development and have participated in the KDE mailing list. My intention was to become a regular KDE contributor.
This was short lived, however, as I quickly found that the KDE mailing list, was being run as a sort of private fiefdom by this same David Faure. Any comments of the form "KDE mainline applications development should be opened up to more developers" i.e., not just be restricted to the main CVS tree, were met extremely aggressively. I didn't want to press the point because I thought "maybe he's right" and all the core applications *do* have to be tightly controlled by the core developers in order to have the highest possible quality.
But now, 6 months later, I know he's wrong. KDE development has slowed down *a lot*, and especially KDE core applications development. I've been putting up with the same bugs in kmail for almost a year now - it hasn't changed a bit, because kmail development has been inextricably bound into the main KDE CVS tree, and it's all oriented towards KDE 2 now. So if you're not compiling out of CVS, you're out of luck. The bottom line is that KDE users have to wait and wait and wait for bug fixes.
Now, I'm a developer and I should just be able to download the code, make the fixes and send them in. But in the case of kmail, you have to download practically the whole tree, and let me tell you, it isn't that easy to get it to build. I would have done that anyway, except for the agressive reception I got on the KDE mailing list. Anyway, I'd still have a problem with it, because suppose I put in a bunch of great features - It would still be months and months before anybody gets to use them, because they have to wait for the official release of KDE 2. One of the reasons developers develop for free is to see their stuff get used *immediately*, and this just doesn't happen with KDE development.
I did what open-source developers are famous for doing - I moved on to other projects that are more to my taste (e.g., Freenet!!). Now, I'm not bitter - why should I be, I'm still getting KDE for free and it's still darn good - but I am concerned that a certain prima-donna mentality is hurting the KDE development, and because of that, hurting the entire open-source movement. I wonder how much of this is due to the fact that some fulltime, paid developers (Faure is one) don't feel compelled to play by the traditional, unspoken rules of the community. OK, I've said my piece, and I'm posting this without my +1 bonus because I'm not sure whether this is a flame or a troll or constructive criticism. --
New ways of Getting through Windows Security
on
Microsoft Quickies
·
· Score: 2
Oops, I accidently posted this to the wrong thread:-0 (Rob, it's a bug... I can't d/c while composing a reply any more.) Here it is again, for what it's worth...
New ways of Getting through Windows Security.
My impression at this point is that the idea behind NGWS is to use rpc implemented via SOAP (an awkward sort of XML rpc wrapper for Visual Basic) to split traditional desktop apps into a client-resident part and a server-resident part. I find this concept incredibly scary - mainly because of the security record of the company that's doing it. Forchrissakes, if they can't even keep Visual Basic programs from executing out of email attachments, what's going to happen when they open up whole server farms for this kind of intrusion? How many hundreds of creative new possibilities are they proposing to create to let script kiddies come in and take over Windows boxes over the net?
It's already been demonstrated as clearly as necessary how porous Windows really is on the security front, and everybody knows what the main actor in the last drama was: Visual Basic Script. You'd think the thing to do would be to get it under control, but instead we have this proposal to deploy the exact same disasterous design all over the entire net. --
Slashdot Mirror
Tomorrow the DOJ can formally ask for the Expediatary Act and the judge can certify the case as meeting the Act's stipulations. Then, the Supreme Court has the opportunity to take the case, out of the district court's hand. You can bet this will happen too.
I sure hope you're right, because if Microsoft manages to flout the spirit of the Expediting Act like this it will be another sorry day for American justice.
--
...Before the district court had a chance to employ the Expediting act, to move it directly to the Supreme Court. I saw something like this happen in my home province, B.C. - former premier of B.C. was being charged with a blatant case of insider trading, and the provicial court grabbed the case quickly, before the federal court could get it, so they could let him off with a wrist-slap. Of course, the Appeals court can't let anybody off, but they can sure weaken the case if they want to. This looks very, very sleazy. I think it's well worth scrutinizing how the Appeals court conducts itself in this case, and if strange things are done, I think very sharp questions should be asked as to motivations and allegiances.
--
Can someone please explain the difference between music which is covered by copyright and software which is covered by the GPL?
:-)
The question is badly formed since the GPL is a *licence* governing the use of copyrighted material, so you are really comparing apples to.. err... apple seeds.
Here goes anyway: the GPL guarantees your right to use the licenced intellectual property freely, including redistributing it, and forbids you from imposing new conditions on anyone you restribute it to. It is a guarantee of freedom. As such, it is in a completely different class from the conditions that the RIAA is trying to impose on the use and distribution of music.
[offtopic] Rob, there is a new BUG in slash that prevents offline composition. Error message: Invalid form key! Sheesh, this bug has been in for weeks, does this say anything to you about the need to make the slash code truly open?????
--
Repeating the exact same rhythm accurately is a skill that takes years to master. It sure doesn't happen by accident.
Memory of rhythm fades rapidly. Unlike the patterns that grow on the ends of your fingers.
Supposing that people did have characteristic patterns - by ear, a trained musician can easily copy and conterfeit them.
On top of that, *nobody* is going to be happy about getting a retinal scan or anything remotely resembling that before they can play a piece of music they bought and paid for. This idea is so far out in left field that I can't see it as anything other than grasping at a straw - an act of desperation.
I was reading a fine piece today that sums up exactly my thoughts, better than I could. The problem is defined perfectly, and the reasons why recorded music is *never* going to be expensive and restricted again, like it has for much of the 20th century. (The solutions he proposes for compensating musicians in that piece are too utopian, IMHO, but other solutions *will* work.)
The RIAA and their toadies are on the run. They may be able to attack dotcom's and bring them to heel, but they can't successfully overwhelm the entire net.
Disclaimer: I would *never* encourage anyone to violate a copyright, even to hasten the demise of an evil cartel like the RIAA - instead, listen to the music of musician's that *want* you to, and don't unfairly restrict you.
--
" Will Opera integrate with my desktop?
;-)
In version 4.0, integration into the environments such as KDE, Gnome, CDE, and others will not be a priority. "
Now, now. You'll never beat Microsoft if that's your attitude.
Actually, I think they just mean they're not putting in special code for docking and such at the moment. I think that's fair - lets see how KDE and Gnome evolve first before putting in such desktop-specific stuff. Almost all the applications I use now work just fine without any desktop-specific hooks and I'd rather the Opera guys concentrated on getting the browser itself right, just now.
--
I was pleased to see my favorite browser buttons sitting there in the Eazel browser concept shot: Back, Forward, Up, Reload, Home, Stop. This is almost ideal (my opinion) except that Home and Stop positions should be reversed. Why? Because Home should just be one of a number of user-defineable "goto location" buttons. Yet we want the stop button to be always in the same position so we don't have to hunt for it.
The counter argument is that the "stop" button is in some sense a "final" kind of action, therefore should be on the right like a period at the end of a sentence. That is where it is in Netscape, and I find that a pain.
--
I see mostly flames, moderated up, at the top level. There are two things that are wrong with this: first, people should not be flaming a new, open-source project, they should be providing constructive criticism or encouragement. Second, moderators are moderating according to how strongly they agree with an article instead of how well-written and credible the article is.
I'll weigh in with my opinion here: I think, that with the track record of the people involved in Eazel, we should give them all the support we can, regardless of whether we see their work as a threat to our pet project (it isn't - remember, it's all open-source and any of the good ideas from Eazel can be incorporated into our other projects).
--
Is hair just sharp bumps?
Nope. Once way to make hair, start with a wooden log light by a spot in the middle (this will be the sheen), stretch it out and alpha it a few hundred times onto a surface with slight longitudinal displacements and slight bending - now it should like a sheaf of wheat. Take the resulting texture and map it two or three levels deep onto a hair-shaped object, using an alpha map to give it shape and taper. On the head place an opaque map, darkened, of the same texture so you don't get any bald spots. Presto! It looks like hair.
This runs pretty efficiently in real time too, because you're just mapping a few 10's of textures to get the effect. The main disadvantage of this approach is that the highlights (sheen) don't move. A hack to make them move is to light the hair texture with a spotlight before alpha mapping it onto the hair polys.
You could add a bump map to the hair texture and you would get the moving sheen.
--
In what way is [Microsoft's] J-- better than the JDK?
Faster and more stable. Note: I detest Microsoft, Its business practices, and its founder and its founder's dog. Yet I'm not going to deny what's true.
The language specification and API cannot be made un-free.
Not the existing APIs, no, but the new APIs coming up, that's where the problem lies. That's why so many of us have a problem with Sun's behaviour at the moment.
--
As for "fiddling with environment variables": yeah, you're completely right, setting two variables (KDEDIR and QTDIR) is just SOOOOO hard...
Ok, ok, you win, you win, actually there is no problem at all with obtaining compiling KDE apps such as kmail, and as I have better ways to spend my time I'll forget about it for another year, thanks for the advice.
--
You may not be grateful to Sun for designing Java, but I am.
And I am too, don't make any mistake about it. But I am not grateful for having been handed a proprietary fingertrap masqueradeing as a public standard.
You say "We could have have done that quite well by ourselves, thank you." Are you serious?
By "we" I mean anyone who is willing to contribute their language design work to the public. For example, Larry Wall or Guido Van Rossum (designer of Python). Yes, I'm serious.
How many more brilliant languages are you planning to design and implement?
You are wasting both our time by not reading before you reply. I wrote: "I don't care much about their code. I could have written it myself, and better." And I stand by that since I've done such things before. But I won't do it for Java because Java is not yet free, as in speech. Some others are willing to rewrite Sun's bloated, unreliable code, and my hat goes off to them. I'm not one.
I hope that my interests and Sun's will continue to coincide
You seem to have missed the entire point of "free" as in speech.
If you can reimplement Sun's JDK on your own, as you claim, then I would be truly grateful to you as well. Many organizations have tried, but Sun's JDK still seems to work better than the alternatives.
That's wrong. IBM's implementation is better. Microsoft's is too. Blackdown is darn good and is now intertwined with Sun's - Sun gets the benefit of expert programmers there, working for free. Kaffee is good too: though not yet caught up to the others, it probably will, and pass them. The problem is, even when Kaffee does catch up, Sun will intentionally move the goal posts. Are you aware that Sun charges big bucks for access to the Java compatibility test suite? Can you think of any good reason for this other than a desire to lock out the open source movement?
The licenses are clear. If I don't want the code under those terms, then I don't use it.
But that sounds so much like the situation with Microsoft. "If you don't like it, don't buy it". The problem is, Sun is trying to get us into a position where we *don't* have a choice, and I object to that seriously.
As a language, Python is just as good - it does what Java is supposed to do, and does it without the bloat. But Sun has inserted Java into the niche that Python could have occupied. Should we be grateful for that?
--
Poor psychology. You aren't going to persuade Sun to make you a gift when you clearly will show no gratitude anyway.
So you think being nice is the way to get Sun to come across? Hey, maybe you're right. But don't bet your life on it. Notwithstanding the fact that much that much of our free OS originated at Sun, we already know that Sun is not being nice. Witness their dance around the standards bodies. So we should be nice, yes, but also, we need some powerful pursuasion.
Get this clear: Sun is not giving us anything by designing Java and giving it to us. We could have done that quite well by ourselves, thankyou. *We* are giving Sun something by elevating their trademark and reputation to a lofty position - by agreeing to make Java a true, public standard.
If Java is always going to be proprietary to Sun, then we will be no better off with Sun as master than with Microsoft as master. Do get that clear. As long as Java is proprietary, we are much better of to deny it the full status it seeks, and to work instead with things that are truly public standards: the Linux kernel, Python, TCP/IP, all of GNU, etc. etc. Java only becomes useful to us in the long run if Sun lets go completely, so don't think about being nice when so much depends on it. It's not a matter of being nice, it's a matter of what our long term goals are.
You evidently feel entitled to their code, and you're not.
I don't care much about their code. I could have written it myself, and better. It's the design, the standard, etc that I care about. Now if they want us to work on their code and make it better than it is, because frankly, you can see from the outside that it sucks, they will have to open it up the rest of the way.
As Larry Wall said, those of leasurely moral development often confuse giving with taking. Since giving is good, some think taking must also be good. Are you grateful even to the FSF?
What a question. Of course I am. FSF gave us the GPL. FSF doesn't play games with standards. Now ask any member of the FSF whether they're "grateful" to Sun.
By the way, when Java first came out I was an ardent supporter and I really saw it as the way forward. I believed what Sun said, about not trying to keep control of it and keeping only the trademark. That was quite a few years ago. I've had a chance to study the whole thing very closely. Did you? Do you know about the ISO and ECMA affairs? Have you read the Sun Community Source Licencse? Didn't think so.
--
There's a AWT on GTK port on the SCSL site, but they don't intend to do anything with it.
Why the heck not? Because they're Sun, that's why, and they don't really care if linux users want a GTK version badly enough to write it for them.
They have no plans to compromise on SCSL to be more GPL friendly.
Is that a surprise? They will continue to have no such plans until they get it forced on them.
I asked "why did it take so long to support Linux?", the answer I got was "limited resources".
That's disingenuous. If they needed more resources they could easily have gotten them by making the SCSL GPL-compatible. The real reason is: "we thought Solaris needed a little help".
--
"When we set out, our goal wasn't to convert the 400 million PC users from Windows to Red Hat Linux," Young said. "There are 6 billion people on the planet. Our goal is to build technology for the other 5.6 billion."
Perfect quote, sums up my feelings except for one thing: I'm sure glad that *I* was one of the 400 million Windows users that got converted in the slipstream.
--
The only downside is that leaving MSIE in Windows will make it a lot harder for Mozilla to establish a strong base on the Windows platform. Not impossible, but a lot harder. I'd rather be faced with that problem, though, than have to deal with tying between web/media content and MSIE-as-media-player. For the same reason, Microsoft's media players should be left with the OS, not the apps/web company.
It's the best of two bad situations. Actually, I agree with those who think that the best solution would be to liquidate Microsoft and throw Bill Gates in the slammer, but that's just wishful thinking - it isn't going to happen, at least, not unless Bill is dumb enough to keep flouting the law, even after this rather clear demonstration of why you shouldn't. (starting to drift offtopic here, but oh well.) Actually, I think that's how it will finally play out. Remember all the speeding tickets, and he never learned, did he? Just counted on his rich lawyer dad to fix it all up and keep him on the road. I guess it's probably going to happen that way again, except on a much bigger scale, and he's utimately going to wind up doing time, just like Michael Milken did. It's strange what greed and ego can do to a man.
Clark's advice has little chance of making it into policy, however, even if senators like what they hear. The appeals court that will look at the landmark Microsoft breakup proposal largely will be charged with deciding whether the original ruling was legally correct, rather than changing individual details of the remedy.
IANAL, but that's not a correct interpretation. The details of the split, what goes where, aren't specified at all in the final judgement and in fact are to be proposed by Microsoft. Naturally, the DoJ will make it clear to Microsoft what it wants where.
Rob, there is a new bug in slash that prevents offline composing. If you d/c while on the composing page then when you reconnect you can preview, but trying to post results in: Invalid form key! This is seriously annoying.
--
Microsoft was only able to bully others once they gained a monopoly.
That's not correct. Microsoft was in the bullying business long before it had a monopoly. Perhaps you don't remember how Seattle Computer was legally forced to give up their licence to sell MS Dos? There are countless examples of such behaviour. Heck, there's even a story that Bill Gates forced Paul Allen to give up part of his originally-equal share in Microsoft.
--
"If you can prove that [innovation was stifled] I will shut up forever."
Unfortunately, this is not a provable statement so I'm not really going to debate it.
This is easily provable. In the findings of fact you see that Microsoft forced Intel to can its media software research lab with a "credible and fairly terrifying threat". He loses, and has to shut up forever (his suggestion).
--
Yes, the list is longer than for Mozilla. OTOH KDE IS much more than one app, it's an environment/application framework.
This is exactly my point. I do not want to compile KDE. I want to compile kmail. So why am I force to compile 6 more apps and a good part of KDE and possibly QT? When we both know that it would be easy to provide to me the source code I need just to compile kmail? And after doing what you suggest, I wind up with the wrong version of kmail - one that runs under a beta desktop that I'm not using. Fixing bugs there doesn't fix the immediate problems. Downloading other snaps doesn't gives me an old frozen version that nobody is fixing bugs in.
Good gosh, man, can't you see that if people are complaining, there must be a problem? It takes a lot to get people to speak up on something like this. My original post was moderated up by four readers and not marked a troll by any, as it easily could have been. What does that tell you? And what does it tell you about how it will be perceived if you keep sticking to your guns instead of looking for a resolution?
By the way you left out the "fiddle with environment variables" step in your list, maybe others.
--
Really, in what way is downloading & compiling KDE less easy than doing the same for Mozilla?
./mozilla and go for a surf
Instructions for building Mozilla:
1) Download the source tarball
2) Unzip into directory of your choice
3) cd into the directory and type: make
4) Go for coffee, come back in 40 minutes
5) Type
Instructions for building kmail:
0) Look for a kmail.x.x.tgz. Find a very old one. Get confused. Hunt around with RPM. Figure out it's now part of kdenetwork. Look for kdenetwork.x.x.tgz. Find a version that's way too old. Learn you have to get it out of CVS, and you have to get all of KDE with it.
1) Explore kde.org. Find the part that tells you about cvsup
2) Download and install cvsup
3) Find the instructions about how to get download KDE via cvsup
4) Decide what parts of KDE you actually want to download. Get confused. Decide to download everything
5) Start the download and go to sleep
6) Wake up, discover you got disconnected, repeat as necessary
7) Get a cup of coffee, sit down, and start figuring out how to build it
8) Guess that you have to build QT first. Try to build QT in the obvious way. It doesn't work. Go back to instructions. Learn you have to link a directory first. Do it and try again.
8) Go out for a walk while QT builds. Come back, find it's still building. Play Mahjong.
9) Try to use the same strategy to build kdebase. It doesn't work. Try some more. It still doesn't work.
10) Go back to developer.kde.org. Learn about the build script. Download it. Fiddle with it until all the path variable are correct. It finally seems to work. Out of fear, decide to build everything.
11) Go to sleep while it builds.
12) Wake up. One of the first packages failed to build - it's because somebody checked in something ugly that broke the build. Start cvsup again. Go for another walk while the tree updates. Later that day, start the build again and go to sleep.
13) It builds this time. Now figure out how to install it, without conflicting with your current KDE installation. Go for a surf. Find a howto on this subject. Read it. Fiddle with paths. Now it works.
14) Run kmail from the new desktop
OK, I may have missed a couple of steps, or a couple of details, but that's essentially what has to happen. Umm, don't you think there's a difference in difficulty and time investment between the two procedures?
There ARE snapshots of libs and app-packages available, and the next set of those will even contain CVS information, so you just need to update a specific directory from that on.
But why can't I just download a tgz of the specific package I want to compile, like almost any other open source project? Then all I need are headers for kde and qt, and I'm up and hacking. There is a *radical* difference in the amount of work required to get started. Later, when I've got some code I'm proud of, I can figure out how to submit it to a maintainer. In other words, the normal open source process.
Package snapshots only eliminate a few of the steps I listed, and you still have to figure out which packages you need, which directories to put them in, and how to set the paths. This is a *lot* of work if you've never done it before.
Mainly, what I hear you saying is: there's no problem, it's just your imagination. But it's not my imagination, I've been through this. I know what the difference is between downloading and compiling "spruce", for example, versus downloading all of kde and qt just to compile "kmail". It amounts to *days* of extra work the first time you do it. It's not my imagination.
Perhaps I should rejoin the KDE mailing list and we can continue this discussion there. *But* I still have this nagging feeling - why should I do that, when the last time I did, I just got flamed?
--
But there IS a KDE_1_1_STABLE branch in CVS! It's just that nobody used it after releasing 1.1.2 (besides some bug fixing).
Close, but no cigar. It has to be: KDE_1_2_STABLE CVS, and it has to be complemented with the individual apps also posted in simple tgz format. In addition, the individual apps in, for example, kdenetwork, should be available as individual tgz's. Why should you have to download and build 6 apps when you're only interested in one?
There's no particular difficulty or excessive work in accomplishing it: a script can simply be written to extract and zip the necessary branches of CVS, and to create the necessary new CVS trees (so development of the stable apps can proceed independently from the development tree, the way it does in the Linux kernel). The script just needs to be run *once* following each stable release.
The only thing I see getting in the way is core developers are not, at this point, willing to recognize that non-core developers have a big barrier to getting started - much bigger than most other open-source apps. Even mozilla is easier to download and compile than KDE, let alone individual KDE core apps which have to be dug out with considerable effort from a rather indimidating CVS tree.
--
If you've got problems with the KDE development model, nobody's stopping you from forking the KMail code and integrating your changes.
Believe me, I seriously considered that and would have done it if I had not gotten fully committed to other projects. The need to spend several hours downloading the full CVS tree (analog modem) and fiddling with the build process was the final straw. (I've since done that, and it did in fact take a lot of time.) But why is it necessary to solve the problem by forcing a fork? Why not address the problem in the first place by having a well-defined fork a la the stable-vs-development strategy of the Linux kernel?
Personally, I think David's an awesome guy- he knows what's going on with the code, he has some really brilliant ideas about how to implement features in Konqueror, and he's never been rude that I've seen.
I must have caught him on a bad day then, and what I've seen recently supports your opinion. I still I think I'm right about the question I raised and that KDE app source code needs to be more accessible to developers outside the inner circle. It's a real problem that bugs aren't getting fixed in the stable releases and it's a problem that isn't hard to fix.
Please note that none of what I say reflects in any way on the KDE 2 development - I think that's working great, and there's fundamental progress going on there, particularly in object embedding techniques. And the attention to detail and useability in the KDE development has always impressed me. No doubt such things are in part due to David's skills.
--
It works perfectly on the stable kernels. The development kernels occasionally break VMWare and this is rapidly corrected, no big deal.
--
You wish that KDE core applications were developed out of CVS ? With the changes that happen in kdelibs quite often - to build a better API, and because of all the new stuff in KDE 2.0 (KParts, DCOP, XMLGUI, etc.) - this is almost impossible. What you gain from having apps in CVS is that they can be fixed by many people, especially those who change kdelibs. Out of CVS, it's up to the author to fix his app to cope with the changes, and _that_ can be piss him off a lot, obviously.
...KDE is definitely nobody's fiefdom.
...the idea of developing core apps out of CVS really doesn't make much sense. You want to "open more" the development by making it private ?
I realize that this is not an easy problem. But there is a better solution than hiving off all development into the CVS and core team. In short, there should be a stable (1.1.2) and a development tree (1.x.x) just like the Linux kernel. The stable tree should actually be a number of trees, with each core app having its own tree. And also a zipped snapshot, so an interested developer can grab it and immediately compile it with no fuss or muss. Only after that the developer needs to put in the extra work to install cvsup and sync up to the latest tree, the mailing list, the maintainers, etc.
The stable trees can be maintained by a completely different set of developers - there will be no shortage of volunteers And so, no additional load on the core developers.
This is not about "controlling", this is effectively about helping....
Yes, of course, but sometimes the cure can be worse than the disease. Sometimes the first cure you think of isn't the best one, even if it seems to help.
To answer the more personal comments...
The personal comments were not necessary, and I apologize.
I was referring strictly to the mailing list.
I don't see how any of my remarks could be interpreted that way.
About KDE 2 apps that are not in CVS : from 1.91 onwards, they should be able to compile and run on top of KDE. The API shouldn't change anymore. No need to wait for the official 2.0.
That's nice, but the API is going to change again in the future (I hope! Ossification is bad) and the same problems will come up again.
Finally, I'm not a paid fulltime developer... yet.
Pardon me for misspeaking in that regard.
--
Oooh, this is going to cost me karma as trolling, but...
How is this all-inclusive, single-source applications/OS environment any different than, say, Windows and Office?
You may be surprised at how much support you get. Disclaimer: I *use* KDE every day and I think it's great. I use lots of KDE mainline applications and lots of what I'd have to call "3rd party" applications. (though I probably use even more Gnome/GTK applications, running them from the KDE desktop.)
I have some experience compiling KDE out of CVS, have done a small amount of KDE/QT development and have participated in the KDE mailing list. My intention was to become a regular KDE contributor.
This was short lived, however, as I quickly found that the KDE mailing list, was being run as a sort of private fiefdom by this same David Faure. Any comments of the form "KDE mainline applications development should be opened up to more developers" i.e., not just be restricted to the main CVS tree, were met extremely aggressively. I didn't want to press the point because I thought "maybe he's right" and all the core applications *do* have to be tightly controlled by the core developers in order to have the highest possible quality.
But now, 6 months later, I know he's wrong. KDE development has slowed down *a lot*, and especially KDE core applications development. I've been putting up with the same bugs in kmail for almost a year now - it hasn't changed a bit, because kmail development has been inextricably bound into the main KDE CVS tree, and it's all oriented towards KDE 2 now. So if you're not compiling out of CVS, you're out of luck. The bottom line is that KDE users have to wait and wait and wait for bug fixes.
Now, I'm a developer and I should just be able to download the code, make the fixes and send them in. But in the case of kmail, you have to download practically the whole tree, and let me tell you, it isn't that easy to get it to build. I would have done that anyway, except for the agressive reception I got on the KDE mailing list. Anyway, I'd still have a problem with it, because suppose I put in a bunch of great features - It would still be months and months before anybody gets to use them, because they have to wait for the official release of KDE 2. One of the reasons developers develop for free is to see their stuff get used *immediately*, and this just doesn't happen with KDE development.
I did what open-source developers are famous for doing - I moved on to other projects that are more to my taste (e.g., Freenet!!). Now, I'm not bitter - why should I be, I'm still getting KDE for free and it's still darn good - but I am concerned that a certain prima-donna mentality is hurting the KDE development, and because of that, hurting the entire open-source movement. I wonder how much of this is due to the fact that some fulltime, paid developers (Faure is one) don't feel compelled to play by the traditional, unspoken rules of the community. OK, I've said my piece, and I'm posting this without my +1 bonus because I'm not sure whether this is a flame or a troll or constructive criticism.
--
Oops, I accidently posted this to the wrong thread :-0 (Rob, it's a bug... I can't d/c while composing a reply any more.) Here it is again, for what it's worth...
New ways of Getting through Windows Security.
My impression at this point is that the idea behind NGWS is to use rpc implemented via SOAP (an awkward sort of XML rpc wrapper for Visual Basic) to split traditional desktop apps into a client-resident part and a server-resident part. I find this concept incredibly scary - mainly because of the security record of the company that's doing it. Forchrissakes, if they can't even keep Visual Basic programs from executing out of email attachments, what's going to happen when they open up whole server farms for this kind of intrusion? How many hundreds of creative new possibilities are they proposing to create to let script kiddies come in and take over Windows boxes over the net?
It's already been demonstrated as clearly as necessary how porous Windows really is on the security front, and everybody knows what the main actor in the last drama was: Visual Basic Script. You'd think the thing to do would be to get it under control, but instead we have this proposal to deploy the exact same disasterous design all over the entire net.
--