I've been a KDE fan since 1.x, but one of the worst pieces of OSS I've ever used was in KDE 4.7 -- KMail 2. I thought it might just be me, but a little research showed that every distro shipping it has had many angry users. For me on OpenSUSE it's been an endless source of lost incoming and outgoing mail, performance problems, and generally horrible bugs. Totally broken development process -- the problems were widely reported during at beta, but ignored since KDE leadership insists on pushing the buggy/leaky Akonadi-Nepomuk stuff regardless of what it means to end users. I'll give KMail in 4.8 another chance, but I don't hold out much hope -- it's been years since Akonadi was introduced and everything associated with it has been a disaster.
The rest of KDE 4.7 is absolutely terrific though.
If I had mod points today, I'd spend them here. It isn't possible to explain away or excuse Miguel's gushing support of the OOXML spec. He's either completely clueless or "what you said"...
From: "Miguel de Icaza" Date: Thu, 6 Sep 2007 01:37:44 -0400 Local: Thurs, Sep 6 2007 1:37 am Subject: Re: I tell you how does this look
Hello,
* I think we'll all agree that this collaboration can be seen as part > of an strategy to gain acceptance in a flash dominated world. I've got > no problem with that if this kind of competition benefits the users.. > but why didn't Microsoft standarize Silverlight like they did with CLR > and C#? This make me think that all this collaboration is temporal.
I do not blame them. OOXML is a superb standard and yet, it has been FUDed so badly by its competitors that serious people believe that there is something fundamentally wrong with it. This is at a time when OOXML as a spec is in much better shape than any other spec on that space.
Besides, it is always better to have two implementations and then standardize than trying to standardize a single implementation.
As for aseigo, I follow his blog and I can't remember him saying users can't comment on UI issues. If you'd give links to that than I might find your comment informative, right now, it seems mostly flamebait.
Bug 154535 is a user request for the ability to optionally remove the toolbox "cashew". 154535 has the second highest number of votes of any plasma bug. Aaron marked it as WONTFIX ("that is the final resolution of this issue as per the maintainer of the project"). Here are two examples of his attitude:
#53
it would be nice, however, if in situations like this you refrained from commenting... i don't particularly need to open my inbox, go through the bug reports and read this kind of stuff.
#84
please, please, please people: don't try and get involved in discussions of design. if you are technically capable of doing so, read the code and jump on panel-devel and discuss things with the rest of the team in a reasoned and well-informed manner.
My personal opinion is that Hans killed Nina in a fit of rage, then scrambled to cover up the evidence. I did not see any evidence whatsoever of premeditation. So I can not at all understand how this jury reached a verdict of First degree murder.
The prosecution pointed out that he arranged this for a weekend that was not Hans' normal weekend to have the kids, and that he intentionally switched weekends so Nina would be coming to his house when the other people in the house were out of town.
Over the last two weeks we ported a complex webapp to current RHEL and SLES in parallel. SLES feels like a much more modern product. RHEL felt like it hasn't advanced since RH 6.0. Configuration tools (nothing on RHEL compares to YAST), java compatibility (the RHEL required gcj/tomcat doesn't get along with sunjava/tomcat jars), yum vs. the suse updater, and numerous other little improvements.
Based on reputation, it was the opposite result from what we had expected.
Read what I wrote again. Then ask yourself why you thought of JJ Abrams.
He has done some excellent stuff by himself. Then again, read the crap treatment he came up with for Superman and you'll see why many Star Trek fans wish he would stay away.
All a "reboot" says is that a producer is too gutless to create and popularize their own fictional creation, so they take the shortcut of starting with the good name and recognizable parts of someone else's creation. I wish people who doesn't want to follow what has come before show some cajones and create their own thing from scratch.
Greenpeace, and other edge activists, will happily sell out their own image to generate change. It is unfortunate they did not read more Aesop as children.
What they want is for your thinking about Apple--and other computer companies--to include environmental policy. Mission accomplished, I'd say. It already did; now I am less likely to consider technology industry environmental policy as a serious issue since proponents of concern show themselves to be fools or knaves.
Think KKK. Think John Brown. Think Al Qaida You have a very unusual definition of strategic success.
"First of all the posting of this document is a huge, huge, huge win for Greenpeace. I think it's hard to overemphasize the extent to which this is a victory."
I'm not very tuned into environmental issues, although I donate periodically to the Sierra Club and Nature Conservancy. Before this, all I knew about Greenpeace was that they are a recognizable leader in the movement. But after reading this set of documents (the Greenpeace site, the Ars analysis, and Apple's response), I've realized that Greenpeace is a bunch of not-to-be-trusted liars.
Now my default reaction to the claims of _any_ environmental group will be suspicion. I don't think thats a "huge, huge, huge win". Assuming your definition ("exaggeration, hyperbole, heck even making stuff up") is correct, "Edge activism" looks to me like the way immature idiots rationalize irresponsible behavior.
The record company _does_ "own it", at a cost of many thousands of dollars. And what they choose to do with their ownership is sell a copy with restricted rights to use under specified circumstances (enforced by DRM) to willing purchasers at a fraction of their ownership cost.
The forkers could maintain the fork's GPLv2 status, but that would not allow them to change the licensing conditions and eliminate the 'later version' clause: only the FSF would have the authority to do that.
Only that FSF copyright assignment policy prohibits the addition of new code without the clause. A forked community can eliminate the "later version" clause on their new contributions, preventing the FSF from putting those contributions into a version that prohibits v2 distribution.
The FSF may relicense their version of the toolchain v3 only, but it is far from clear that all key developers will go along -- some have supposedly said they will not. If the projects fork entirely, the FSF version could wind up like the HURD. If contributors refuse to license their contributions GPL v3 only it's hard to tell what will happen since the FSF won't answer all questions about GPL v2/v3 interactions.
So today we have secured a peace of mind for Novell customers that might have been worried about possible patent infringements open source deployments. This matters in particular for Mono, because for a long time its been the favorite conversation starter for folks that find dates on Slashdot.
Notice the "for Novell customers" part. So any part of the community not a Novell customer seems to still have a problem.
Which Miguel are you asking? The old Miguel been telling people for years that there are no patent issues with Mono. Today's Miguel says there are serious patent issues, and only Novell customers are safe from Microsoft litigation.
Which one is right? Can you believe either? Wanna bet the future of the Linux desktop on the answer?
The total failure of ATI quality control to regression test even on recent cards like in my laptop is astounding. I'll never make the mistake of buying ATI products again.
(a) Technical data means, for purposes of this subchapter:
(1) Information, other than software as defined in Sec. 120.10(4), which is required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance or modification of defense articles. This includes information in the form of blueprints, drawings, photographs, plans, instructions and documentation.
I'm not saying this is necessarily a good thing, but it is what it is.
The applicable categories are obvious. If they're so obvious, why didn't you post links to those categories, or better yet, applicable excerpts?
Laziness. Category 5pt2, and 4 & 5pt1 also. Look how broad ITAR 120.10 is (and according to another poster in the thread they can also classify info as a "service" and use those sections).
In short, it looks like you thought you could try to justify your argument by pointing me to a ridiculously large government document, and then hoping I wouldn't bother to actually read it. You thought wrong.
I thought right. It looks like you searched a couple of sections for the word "documentation" without even trying to follow it. Understanding "ridiculously large" and complex laws that put people in jail is hard, that's why lawyers get paid big.
other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites. And this from the person who qualified their original contention with 'AFAIK' and "IANAL'. Pot, meet kettle.
Or with more thought and less attitude you might infer that I take my own advice.
I'm not going to respond to the rest of your rant, Translation: I can't refute it, so I'll shut my eyes and pretend it's not there.
Better translation: Oops, I'm wrestling a pig in mud.
You can skip many of the "Part XXX"s. The applicable categories are obvious. Don't forget to read interpretations and supplement 2.
I'm not going to respond to the rest of your rant, other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
I really don't see how this is supposed to be a violation of export licences
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws. Cryptographic technology actually falls under an even more restrictive license class - munitions.
Read the "Current Status" section. My point is that Hifn isn't "baiting" anyone. You might disagree with their lawyer or think it's your right to demand that Hifn fight "the man", but that's another issue.
I didn't see any useful discussion of the key point in Cohen's email:
Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us.
With a choice between "make Theo happy" and "violate export regulations" it doesn't seem like Hifn is exactly trying to "bait" Theo or OpenBSD.
"Also I don't see how a microkernel is a real improvement."
Well, the self-healing stuff is supposed to prevent this. And I actually had MkLinux (linux hosted on Mach) personality servers that could recover from various crashes. It was pretty neat. Problem is that you (often) have to implement complex error handling code all the way up the software stack to take advantage of it (your WoW example shows why it doesn't work otherwise).
Lots of expensive enterprise software doesn't even check return values from system calls, so I don't hold out much hope for it becoming pervasive.
I've been a KDE fan since 1.x, but one of the worst pieces of OSS I've ever used was in KDE 4.7 -- KMail 2. I thought it might just be me, but a little research showed that every distro shipping it has had many angry users. For me on OpenSUSE it's been an endless source of lost incoming and outgoing mail, performance problems, and generally horrible bugs. Totally broken development process -- the problems were widely reported during at beta, but ignored since KDE leadership insists on pushing the buggy/leaky Akonadi-Nepomuk stuff regardless of what it means to end users. I'll give KMail in 4.8 another chance, but I don't hold out much hope -- it's been years since Akonadi was introduced and everything associated with it has been a disaster.
The rest of KDE 4.7 is absolutely terrific though.
If I had mod points today, I'd spend them here. It isn't possible to explain away or excuse Miguel's gushing support of the OOXML spec. He's either completely clueless or "what you said"...
From: "Miguel de Icaza"
Date: Thu, 6 Sep 2007 01:37:44 -0400
Local: Thurs, Sep 6 2007 1:37 am
Subject: Re: I tell you how does this look
Hello,
* I think we'll all agree that this collaboration can be seen as part
> of an strategy to gain acceptance in a flash dominated world. I've got
> no problem with that if this kind of competition benefits the users..
> but why didn't Microsoft standarize Silverlight like they did with CLR
> and C#? This make me think that all this collaboration is temporal.
I do not blame them. OOXML is a superb standard and yet, it has been FUDed so badly by its competitors that serious people believe that there is something fundamentally wrong with it. This is at a time when OOXML as a spec is in much better shape than any other spec on that space.
Besides, it is always better to have two implementations and then standardize than trying to standardize a single implementation.
The XPS 1730 has NVidia 8700 graphics. AFAIK, the 8700 is an overclocked 8600 part which I would expect to fail even faster.
As for aseigo, I follow his blog and I can't remember him saying users can't comment on UI issues. If you'd give links to that than I might find your comment informative, right now, it seems mostly flamebait.
Bug 154535 is a user request for the ability to optionally remove the toolbox "cashew". 154535 has the second highest number of votes of any plasma bug. Aaron marked it as WONTFIX ("that is the final resolution of this issue as per the maintainer of the project"). Here are two examples of his attitude:
#53
it would be nice, however, if in situations like this you refrained from commenting ... i don't particularly need to open my inbox, go through the bug reports and read this kind of stuff.
#84
please, please, please people: don't try and get involved in discussions of design. if you are technically capable of doing so, read the code and jump on panel-devel and discuss things with the rest of the team in a reasoned and well-informed manner.The prosecution pointed out that he arranged this for a weekend that was not Hans' normal weekend to have the kids, and that he intentionally switched weekends so Nina would be coming to his house when the other people in the house were out of town.
Over the last two weeks we ported a complex webapp to current RHEL and SLES in parallel. SLES feels like a much more modern product. RHEL felt like it hasn't advanced since RH 6.0. Configuration tools (nothing on RHEL compares to YAST), java compatibility (the RHEL required gcj/tomcat doesn't get along with sunjava/tomcat jars), yum vs. the suse updater, and numerous other little improvements.
Based on reputation, it was the opposite result from what we had expected.
At this point, there really aren't any more excuses for Miguel...
Read what I wrote again. Then ask yourself why you thought of JJ Abrams.
He has done some excellent stuff by himself. Then again, read the crap treatment he came up with for Superman and you'll see why many Star Trek fans wish he would stay away.
All a "reboot" says is that a producer is too gutless to create and popularize their own fictional creation, so they take the shortcut of starting with the good name and recognizable parts of someone else's creation. I wish people who doesn't want to follow what has come before show some cajones and create their own thing from scratch.
"First of all the posting of this document is a huge, huge, huge win for Greenpeace. I think it's hard to overemphasize the extent to which this is a victory."
I'm not very tuned into environmental issues, although I donate periodically to the Sierra Club and Nature Conservancy. Before this, all I knew about Greenpeace was that they are a recognizable leader in the movement. But after reading this set of documents (the Greenpeace site, the Ars analysis, and Apple's response), I've realized that Greenpeace is a bunch of not-to-be-trusted liars.
Now my default reaction to the claims of _any_ environmental group will be suspicion. I don't think thats a "huge, huge, huge win". Assuming your definition ("exaggeration, hyperbole, heck even making stuff up") is correct, "Edge activism" looks to me like the way immature idiots rationalize irresponsible behavior.
The record company _does_ "own it", at a cost of many thousands of dollars. And what they choose to do with their ownership is sell a copy with restricted rights to use under specified circumstances (enforced by DRM) to willing purchasers at a fraction of their ownership cost.
I don't see the problem.
The forkers could maintain the fork's GPLv2 status, but that would not allow them to change the licensing conditions and eliminate the 'later version' clause: only the FSF would have the authority to do that.
Only that FSF copyright assignment policy prohibits the addition of new code without the clause. A forked community can eliminate the "later version" clause on their new contributions, preventing the FSF from putting those contributions into a version that prohibits v2 distribution.
>
The FSF may relicense their version of the toolchain v3 only, but it is far from clear that all key developers will go along -- some have supposedly said they will not. If the projects fork entirely, the FSF version could wind up like the HURD. If contributors refuse to license their contributions GPL v3 only it's hard to tell what will happen since the FSF won't answer all questions about GPL v2/v3 interactions.
Yes. He has some comments on his blog, promising more to come
http://tirania.org/blog/index.html
But here is the money quote.
So today we have secured a peace of mind for Novell customers that might have been worried about possible patent infringements open source deployments. This matters in particular for Mono, because for a long time its been the favorite conversation starter for folks that find dates on Slashdot.
Notice the "for Novell customers" part. So any part of the community not a Novell customer seems to still have a problem.
Which Miguel are you asking? The old Miguel been telling people for years that there are no patent issues with Mono. Today's Miguel says there are serious patent issues, and only Novell customers are safe from Microsoft litigation.
Which one is right? Can you believe either? Wanna bet the future of the Linux desktop on the answer?
It's a 9700 and should be adequate for XGL (which dozer correctly guessed was my reason for installing ATI drivers).
Recently, I got a laptop with ATI video. The 8.25 drivers worked perfectly, but all the drivers since have died with:
fglrx(0) PreInitDAL failed
fglrx(0) R200PreInit failed
The total failure of ATI quality control to regression test even on recent cards like in my laptop is astounding. I'll never make the mistake of buying ATI products again.
http://kmymoney2.sourceforge.net/index-home.html
I'm not saying this is necessarily a good thing, but it is what it is.
The applicable categories are obvious.
If they're so obvious, why didn't you post links to those categories, or better yet, applicable excerpts?
Laziness. Category 5pt2, and 4 & 5pt1 also. Look how broad ITAR 120.10 is (and according to another poster in the thread they can also classify info as a "service" and use those sections).
In short, it looks like you thought you could try to justify your argument by pointing me to a ridiculously large government document, and then hoping I wouldn't bother to actually read it. You thought wrong.
I thought right. It looks like you searched a couple of sections for the word "documentation" without even trying to follow it. Understanding "ridiculously large" and complex laws that put people in jail is hard, that's why lawyers get paid big.
other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
And this from the person who qualified their original contention with 'AFAIK' and "IANAL'. Pot, meet kettle.
Or with more thought and less attitude you might infer that I take my own advice.
I'm not going to respond to the rest of your rant,
Translation: I can't refute it, so I'll shut my eyes and pretend it's not there.
Better translation: Oops, I'm wrestling a pig in mud.
Please post links supporting this contention, or withdraw it.
http://www.access.gpo.gov/bis/ear/ear_data.html
You can skip many of the "Part XXX"s. The applicable categories are obvious. Don't forget to read interpretations and supplement 2.
I'm not going to respond to the rest of your rant, other than to suggest you get legal advice somewhere other than mailing lists and agitprop web sites.
I really don't see how this is supposed to be a violation of export licences
h y
AFAIK (and IANAL), detailed hardware documentation is considered the same as the product under the export license laws. Cryptographic technology actually falls under an even more restrictive license class - munitions.
http://en.wikipedia.org/wiki/Export_of_cryptograp
Read the "Current Status" section. My point is that Hifn isn't "baiting" anyone. You might disagree with their lawyer or think it's your right to demand that Hifn fight "the man", but that's another issue.
With a choice between "make Theo happy" and "violate export regulations" it doesn't seem like Hifn is exactly trying to "bait" Theo or OpenBSD.
"Also I don't see how a microkernel is a real improvement."
Well, the self-healing stuff is supposed to prevent this. And I actually had MkLinux (linux hosted on Mach) personality servers that could recover from various crashes. It was pretty neat. Problem is that you (often) have to implement complex error handling code all the way up the software stack to take advantage of it (your WoW example shows why it doesn't work otherwise).
Lots of expensive enterprise software doesn't even check return values from system calls, so I don't hold out much hope for it becoming pervasive.