I have a question for you. If on his website, he made it clear he was willing to make exceptions to the LGPL for this purpose (assuming it can be done is a watertight legal manner, just like for any proprietary software you may license), would you consider using his codec then?
Because when I want to discuss social policy, I want to discuss it with someone who understands that compromise is not always evil, that partial solutions can sometimes be better than no solutions, and that there are ways of doing good for the world that don't fit into the narrow definition of free software.
The ironic thing is that Stallman is also an entity with disadvantages that don't yet outweigh his advantages. Free/open software probably wouldn't be as good a thing as it is now, without him. So accepting him is purely a matter of compromise.
That's precisely the problem. No one gets the space to make educational errors. Therefore you get a nice average of people, but you lose so many innovations that you must find them from other disciplines.
I have seen memory leaks with Java. Just make a long-running thread which has a reference to something which should really be tossed. The most common of all is to forget removing a listener.
Just a warning if you ever debug someone else's code. The JProbe memory analyzer is the best I've found for locating the error quickly. Weakreferences are useful at creating quick fixes, until you can correct the design in the next version.
Well, I am fairly atrocious at my understanding of SQL (clueful db admins have always coddled me), but it does not strike me as hard to store hierarchal data in databases. Each tuple would just have a reference to its parent.
As for attributes, a different table per type of node.
I have no idea about performance properties of such a contraption, but I imagine it could really be improved by modifying the XML to lend itself to such a relational representation.
Possible, but not optimal for languages like C/C++ where there are pointers. There is no real efficient way to represent them, even if you code them in Java bytecode.
Reminds me of an analysis I wrote at Kuro5hin. I am just looking at it again and seeing if I still agree with it:
----
Here are some points I've noticed are useful in building a successful free/open projects.
. Don't assume that you will get any help. This sounds antithetical to the whole point of opening up the source. However, there are other points; an end-user contributes a patch.. and then gets competent enough to understand some aspect of the software that she can provide help on the mailing lists. Eventually that person may contribute more. And even if not so many developers help out, you probably at this point have an infrastructure that is good for efficient (== less costly) support. As Netscape learned, opening up the source is not some magical fairy-dust, but it does have some very deep overall advantages.
. Stable mailing lists. Should have an archive, so you're not answering the same question over & over. As well as a faq. You might find that much of this infrastructure is very useful even just for purely internal projects.
. Have a pretty good first release. That's how you attract users. The point is that some of these users start liking the software, and would rather help it along rather than switch to something else that doesn't quite satisfy their needs. A secondary advantage to this is that you'll probably have a good design at this point, since you were forced to deal with the monster. Make your mistakes before releasing it, so the developers will know that you have experience and trust that you understand the sticky corners.
. Feel free to look at other projects. It clearly seems like you're developing in Java, so I'd suggest looking at the guys at jakarta.apache; they have an entirely straightforward approach to things, even if one of the mailing-list archives gets bounced around to different URLs sometimes...
And at this point, you probably will notice that you are doing the best practices that you should have been doing for any project, internal or otherwise. (Making sure to comment, for example.) Just a small generalization to external development. And it will probably be some of the best management training you will ever find.
Fortunately, everyone's who's admitted to writing a large project in VB now has this useful cluestick link:
"But many VB programs are spaghetti, either because they're done as quick and dirty one-offs, or because they're written by hack programmers without training in object oriented programming, or even structured programming.
"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines."
Admittedly, it's from the person who began what eventually became VB, but he's always a fun read.
That was the story. Then the press changed the story to him being a brave maverick who changed GE to a great place to work, as long as you like your work.
I'm too young to know which version was correct, though it seems to me that both versions certainly can have merit. In fact, they're probably the exact same story, just from different perspectives.
Those who were able to continue were promoted. Those who were not quit, suffered health problems and got laid off.
That's no secret, though different words are used to describe that. Keep the "A and B players," get rid of the "C players." No bones are made as to the darwinism inherent in GE companies. He also sold off low-growth commodity businesses that were still profitable. However, he notes that his severance packages were humane and nothing like the brutal ones that followed GE's example.
Also, intelligent arrogance is always cultivated when trying to build elite groups. I hear that GE tries to avoid the stupid variety of arrogance, by not giving greater merit to people depending on what school they happened to attend.
You're nuts. Ensemble teams have surprisingly deep resources.
This guy is clearly good at tactics. Since he works on graphics engines, he is an important resource. Never throw away or deride your best resources when there are situations where their advantages heavily outweigh disadvantages.
That's the fallacy of McDonalds-style management. Of COURSE your team will be hurt of you lose a great performer. GE stock used to dip when Jack Welch (former CEO) went on vacation, because he might be hit by a bus, and he was disturbingly competent at his job. Sames goes for Bill Gates, Steve Jobs, Linus/Alan, etc.
You need the very competent ones. That means you depend on the very competent ones. And if you want to not be so dependent on a single one of them, make sure you hire more.
While I think you were able to do this because you had all their experience from the failed project to draw upon, as well as pretty well-frozen requirements, I definitely agree -- there is blame for both bad developers and bad business processes.
Any business that can not do SOFTWARE with decent communication technologies that allow flexibility is a terribly stupid business.
Non-service oriented companies often charge for service because it is so costly. As I read, in the past at MS, callcenter costs were charged against the division that released the project. So, the more bugs in a project, the more it kills the revenue. At some point, you must charge for these things. People are expensive, and that's why there's so much work on intelligent help systems to answer your questions.
We're talking about chicken vs. egg. You think people charge for service because of its moneymaking possibilities. But many companies are forced to provide service as a consequence of their business, and they end up needing to charge for it. In reality, both happen, with some overlap.
riser which sucks and alaways has in my eyes (each to their own)
Those numbers sound very suspicious. Even though the "default" config was used, I imagine that possibly the tester used a distro like RedHat which turns on debug mode, slowing down Reiser FS. When testing databases, you see shrinkwrap agreements which forbid you from publicly posting benchmarks for this reason.
He mentions he used:
linux 2.4.7, Samba 2.2.0, and NetBench 7.0.1
and it is unclear whether that was from an upgraded distro or not.
Re:ThinkPads, Inspirons and Vaios All Work Quite W
on
Which Laptop To Buy?
·
· Score: 1
Hmm, smart posting. I'll keep your company in mind for any painful linux-laptop needs.
Though I'd probably get a dual-boot config, since then Dell/IBM/Sony's tech support would complain that the fault is in software, or that they can't possibly support a machine with a non-standard OS. And they'd be right.
Slashdot Mirror
That is interesting. I don't agree, but your disagreement with him is a stronger part of Linus' envisioned ecosystem than my agreement.
I have a question for you. If on his website, he made it clear he was willing to make exceptions to the LGPL for this purpose (assuming it can be done is a watertight legal manner, just like for any proprietary software you may license), would you consider using his codec then?
You have made an error of omission. The author could put it under the LGPL and then accept requests to ease the LGPL's requirements.
The ironic thing is that Stallman is also an entity with disadvantages that don't yet outweigh his advantages. Free/open software probably wouldn't be as good a thing as it is now, without him. So accepting him is purely a matter of compromise.
That's precisely the problem. No one gets the space to make educational errors. Therefore you get a nice average of people, but you lose so many innovations that you must find them from other disciplines.
I have seen memory leaks with Java. Just make a long-running thread which has a reference to something which should really be tossed. The most common of all is to forget removing a listener.
Just a warning if you ever debug someone else's code. The JProbe memory analyzer is the best I've found for locating the error quickly. Weakreferences are useful at creating quick fixes, until you can correct the design in the next version.
I can't imagine downloading executables from an open p2p, checksums or no.
Scalability vs. development speed. Who wins?
.net can become scalable far easier than Java can host languages with pointers.
Plus, I imagine
Well, I am fairly atrocious at my understanding of SQL (clueful db admins have always coddled me), but it does not strike me as hard to store hierarchal data in databases. Each tuple would just have a reference to its parent.
As for attributes, a different table per type of node.
I have no idea about performance properties of such a contraption, but I imagine it could really be improved by modifying the XML to lend itself to such a relational representation.
Possible, but not optimal for languages like C/C++ where there are pointers. There is no real efficient way to represent them, even if you code them in Java bytecode.
No kidding. Apparently Netscape is still getting through. Should "The Open Source Community" also file antitrust charges against Microsoft?
Reminds me of an analysis I wrote at Kuro5hin. I am just looking at it again and seeing if I still agree with it:
----
Here are some points I've noticed are useful in building a successful free/open projects.
. Don't assume that you will get any help. This sounds antithetical to the whole point of opening up the source. However, there are other points; an end-user contributes a patch.. and then gets competent enough to understand some aspect of the software that she can provide help on the mailing lists. Eventually that person may contribute more. And even if not so many developers help out, you probably at this point have an infrastructure that is good for efficient (== less costly) support. As Netscape learned, opening up the source is not some magical fairy-dust, but it does have some very deep overall advantages.
. Stable mailing lists. Should have an archive, so you're not answering the same question over & over. As well as a faq. You might find that much of this infrastructure is very useful even just for purely internal projects.
. Have a pretty good first release. That's how you attract users. The point is that some of these users start liking the software, and would rather help it along rather than switch to something else that doesn't quite satisfy their needs. A secondary advantage to this is that you'll probably have a good design at this point, since you were forced to deal with the monster. Make your mistakes before releasing it, so the developers will know that you have experience and trust that you understand the sticky corners.
. Feel free to look at other projects. It clearly seems like you're developing in Java, so I'd suggest looking at the guys at jakarta.apache; they have an entirely straightforward approach to things, even if one of the mailing-list archives gets bounced around to different URLs sometimes...
And at this point, you probably will notice that you are doing the best practices that you should have been doing for any project, internal or otherwise. (Making sure to comment, for example.) Just a small generalization to external development. And it will probably be some of the best management training you will ever find.
I'm too young to know which version was correct, though it seems to me that both versions certainly can have merit. In fact, they're probably the exact same story, just from different perspectives.
That's no secret, though different words are used to describe that. Keep the "A and B players," get rid of the "C players." No bones are made as to the darwinism inherent in GE companies. He also sold off low-growth commodity businesses that were still profitable. However, he notes that his severance packages were humane and nothing like the brutal ones that followed GE's example.Also, intelligent arrogance is always cultivated when trying to build elite groups. I hear that GE tries to avoid the stupid variety of arrogance, by not giving greater merit to people depending on what school they happened to attend.
You're nuts. Ensemble teams have surprisingly deep resources.
This guy is clearly good at tactics. Since he works on graphics engines, he is an important resource. Never throw away or deride your best resources when there are situations where their advantages heavily outweigh disadvantages.
That's the fallacy of McDonalds-style management. Of COURSE your team will be hurt of you lose a great performer. GE stock used to dip when Jack Welch (former CEO) went on vacation, because he might be hit by a bus, and he was disturbingly competent at his job. Sames goes for Bill Gates, Steve Jobs, Linus/Alan, etc.
You need the very competent ones. That means you depend on the very competent ones. And if you want to not be so dependent on a single one of them, make sure you hire more.
While I think you were able to do this because you had all their experience from the failed project to draw upon, as well as pretty well-frozen requirements, I definitely agree -- there is blame for both bad developers and bad business processes.
Any business that can not do SOFTWARE with decent communication technologies that allow flexibility is a terribly stupid business.
Since Gateway only has to pass the cost of CPUs on to the consumer
That's the flaw in your logic. They can't do that.
But that's one reason why countries have to become more global. Otherwise, multinationals can begin to play governments off each other.
Application programmers != OS programmers.
Non-service oriented companies often charge for service because it is so costly. As I read, in the past at MS, callcenter costs were charged against the division that released the project. So, the more bugs in a project, the more it kills the revenue. At some point, you must charge for these things. People are expensive, and that's why there's so much work on intelligent help systems to answer your questions.
We're talking about chicken vs. egg. You think people charge for service because of its moneymaking possibilities. But many companies are forced to provide service as a consequence of their business, and they end up needing to charge for it. In reality, both happen, with some overlap.
riser which sucks and alaways has in my eyes (each to their own)
Those numbers sound very suspicious. Even though the "default" config was used, I imagine that possibly the tester used a distro like RedHat which turns on debug mode, slowing down Reiser FS. When testing databases, you see shrinkwrap agreements which forbid you from publicly posting benchmarks for this reason.
He mentions he used:
linux 2.4.7, Samba 2.2.0, and NetBench 7.0.1
and it is unclear whether that was from an upgraded distro or not.
Slashdot is not Kuro5hin.
Wait, the ratings don't work the same way here...
Hmm, smart posting. I'll keep your company in mind for any painful linux-laptop needs.
Though I'd probably get a dual-boot config, since then Dell/IBM/Sony's tech support would complain that the fault is in software, or that they can't possibly support a machine with a non-standard OS. And they'd be right.
It's perfectly relevant. It's the steppingstone before Microsoft gets forced to realize they destroy the software ecosystem far more than the GPL.
These guys can really hold contradictions in their minds without questioning them.