Sharing is the very idea of all genial human relationships. The notion that socialism has a monopoly on sharing is absurd. Socialism is about forced sharing, which isn't sharing (in the common sense) at all.
It should be self-evident that "copyleft" is the use
(abuse)
of copyright (the institution) to advance the cause of a community
with you so far
that operates according to a more socialist economic principle.
You seem not to see it, but it is a huge leap to equate sharing of software to an overall "socialist economic principle". What many people don't realize is that RMS is very little interested in economic and political reform. His goals (to a first approximation) stop at creating enough free software that people who don't want to use proprietary software, don't have to (and at convincing people that they don't want to use proprietary software). I don't think you can read RMS's writings (esp the GNU manifesto) carefully and come up with evidence for anything more radical.
Yes, RMS has become involved in politics at times and has mentioned a "software tax". But this is such a minor part of his activities, and so moderate in today's political climate (even in the US), that I don't think you can draw any significance from it.
A lot of your argument seems to be based on the fact that Free Software is compatible with socialism, therefore Free Software must be associated socialism. This is logical nonsesnse; and given that flamboyant capitalists like ESR support Free Software, is manifestly pure bunk.
Your evidence is all extremely circumstantial. Show me where RMS criticizes capitalism in principle, or advocates wide-scale political reform (socialist or any other kind, for that matter). Given that he recently lauded America's founders, who stood solidly on free-market principles, I think you will find it impossible. RMS has explicitly said he is not a communist (can't remember where, but he said it point blank); I don't know how far apart you think communism and socialism are, but I would expect a socialist to express some sympathy for communism.
There is a major bug in your program: you are keeping a backup of the offensive file. It should be permanently eradicated. You might consider writing the correct version to a different disk, and destroying the old disk when you are done.
I think everyone will relate to what you said (very well!)--but if anyone has trouble, try imagining Pedro Martinez pitching to Babe Ruth. Even though the game is substantially unchanged over 100 years, I just can't do it.
Re:Why it's important to assign copyright to FSF
on
Sony Violating GPL?
·
· Score: 2
There is one good reason to reserve copyright to yourself, and it is a considerable reason. You may wish to be able
to provide the software under a proprietary license to someone else
I have heard from people who have signed over copyright that the FSF agreement allows you to offer the software under alternative licenses.
it takes a profit incentive to push discovery into the final phases of development, manufacture, distribution and sale.
As you say yourself: commercialization is very different from discovery. And as the constitution says clearly, patent protection may be awarded only for the second. So while profit incentive may be necessary for commercialization, it will have to be found without the help of patents. Fortunately, as the history of capitalizm has amply demonstrated, entrepreneurs and businesses have many other means of making profits. (I think that's a good thing, on balance.)
The vast majority of security vulnerabilities are buffer overflows.
I don't have numbers (probably only large espionage organizations do), but
I'm willing to bet that's not true.
Buffer overruns undeniably get a lot of coverage on bugtraq--if you casually
read the list, you'll be forgiven for thinking that buffer overruns are the overwhelming
bane of computer security. But there are two biases to this observation:
Buffer overruns get more talk than vulnerability reports. Go to the vulnerability database at SecurityFocus and browse the recent
reports. On the first
page, there are 28 vulnerabilities, of which only three explicitly
mention buffer overruns. Even assuming that this is an unusually low
number, and that a few buffer overruns aren't labeled as overruns, and allowing that buffer overruns tend to be more serious than the
average vulnerability, this is hardly a preponderance.
I frankly think the reason the discussion on bugtraq seems dominated by buffer
overruns is that the community enjoys, and is comfortable, discussing
buffer overruns. Even though the same religious issues (bounded arrays,
language choice, non-executable stack, stack-guarding libraries) are
rehashed over and over, people never get tired of them. Buffer overruns
have a cherished place in security folklore.
This is kinda nice in that it gives the community a common ground, but
dangerous because it leads people to overlook the importance of other program
flaws that can result vulnerabilities.
bugtraq report statistics probably over-represent
buffer overruns. This is related to the above discussion--buffer overruns
are popular and well-worn ground. If you report one, everyone will
understand it and you'll win sure ego points. So if you're going to search
for vulnerabilities, you'll probably search for buffer overruns.
Further, buffer overruns are plain easy to find. If you have source code,
a few greps often take you right to the hole. Even if you don't, tools like fuzz do pretty well (many bugtraq
reports indicate that tools like this were used to find the overrun). Plus,
contrary to what you might think, buffer overrun exploits are ususally easy
to write, so don't think that turns of any would-be security gurus. Other classes of vulnerability usually require more analysis of program logic to find.
In short, even if we stop using languages with unsafe pointers tomorrow, our
security woes will continue in full force.
If in
10 years time you're writing a dissertation on the visual effects used in the Star Wars films, you MUST have access
to the originals so that you can analyse it frame by frame and pixel by pixel.
I don't think you'll find many pixels on the original Star Wars film.
How the did the above post get modded up to +4 interesting?
The excess of moderator points hasn't subsided.
Wrong. Software engineering practices like tracking the severity and
priority of bugs are aimed at creating higher quality software. Instead of
developers spending time fixing bugs that are unimportant or not as annoying
to the user, they have a way of categorizing and fixing bugs on a scale of
importance.
You're saying the same thing I said. Bug tracking helps communication.
People know where the nasty problems are, and nothing falls through the
cracks.
Yet people like you will bitch that Microsoft shouldn't release software
with known severe bugs. I guess if they didn't track bugs they would be able
to say they didn't know that there were any severe bugs with a clear
conscience.
That must be the most common fallacy on Slashdot: that everyone here thinks
the same thing. I myself understand very well that Microsoft's business
requires them to release software with serious bugs. I also know that I
have the choice of software developed under a better (for me, at least) model.
... the myth that programming is an art instead of trying to make it an
engineering discipline.
Programming is certainly not engineering. Why? The requirements are
nowhere near well enough defined. And with the pace of the field, it's not
worth anyone's time to define them to "engineering" precision. This is simply a fact at
this stage of the game.
So if the members of the team come up with the rules for what makes a bug a
certain severity and what marks a bug as a certain priority exactly why can
they not base releasability on these metrics?
For the same reason that "the law is an ass", "metrics are an ass". Even if
developed by reasonable people with good intentions. See below.
Quite frankly, waiting until the software "feels right" before releasing
it is probably the most ridiculuos thing I've ever heard.
Where did you get the idea that I want to release software based on good
vibes and burning entrails? Look, I'm saying that you use all the evidence that you have
available. But you use it more in the manner of a historian arguing a
thesis, not a mathematicial constructing a proof. These are different modes
of thinking, but each is valid in its domain. Or do you think history is
new age bullshit?
On the other hand saying "we won't release until all the bugs that cause
core dumps/segfaults/BSODs are fixed (severity one)" or that "we won't ship
until we fix the annoying UI issues (priority one or two)" are quite
reasonable even from a common sense point of view.
Depends what you mean. If you mean, "We reviewed the bug db and the beta
tester feedback, and everyone agrees that we can release when the four known
crashes are fixed, barring unforseen new issues", then I'm with you. If you
mean, "Welcome to the new project, team; we're going to ship when the
feature-set is implemented and there are no sev 1 bugs", you're fooling
yourself. There are just too many possibilities, and no bug database can
objectively capture the complex reality of a software project. Any hope
that metrics will guide you is (pardon the slang) just wanking.
Interestingly most users of Windows 98 I know judged the software on its
bug count (i.e. how many crashes needing reboots per day or other ridiculuos
problems per day)
Really? They don't care about the zillions of applications they can run?
What proportion of Windows users quit using it because of the bugs? If it's
not high, then bug count is probably not a significant factor in the success
of Windows.
Do you really think Mozilla, GNOME, KDE, Apache, the Linux kernel,
OpenBSD, etc are shipping "stable" releases of software without keeping an
eye on bug severities and priorities?
The projects I follow most closely are Linux and Debian. Debian explicitly
eschews specific release criteria based on hard experience. Linus has been
known to release kernels that don't compile.
They may choose to ignore them for one reason or the other but they are
keeping track.
Hear my point: bug databases are good because they assist in keeping track.
Releasing based on a formula is bad. "Ignoring bugs for one reason or
another" represents the practice I advocate: look at the evidence (including
bug database), apply intelligence, draw conclusion.
Logging bugs, and giving them "severities", is well and good. It can help in the same way that any effective software development tool helps, by enhancing communication. The moral is that bug tracking is useful only in the context of a team that can, and wishes to, use it effectively.
Using bug count and severity as a measure of "releasability", however, is the fallacy of feeble-minded managers, who are afraid to make a decision without a number to back it up. Software development (as practiced in all but epsilon of cases) is simply not a measurable process. You will only waste your time trying to quantify it.
Releasability can only be determined by the judgement of the team working on the release (which may include developers, testers, release managers, beta testers, partners, etc). That is not to say that you should not draw upon the bug database for evidence upon which to base your judgement. But it requires intelligent interpretation, not counting up some totals.
Some people consider this a failing of the software development process. I think they are too quick to condemn. The customer doesn't (usually) judge software by its bug count. Most software is judged by an overall feel: if the software is compelling, many deficiencies will be overlooked. Further, it is difficult to guess ahead of time (even with beta testing) which bugs will really bite people and impede their use of the software. Given the many interacting factors that determine the success of software, release decisions are naturally more art than science.
I know, I haven't presented any hard evidence. I'm arguing from experience in both free and closed software projects, and appealing to common sense. Most free software is released "when it's ready", without any metrics. Ponder on whether this is a strength or a weakness. And remember that when someone gives you number, the burden is on him to show that the number means something.
Finally, before someone else points it out, I know that software can be developed with sufficient care and process that it is measurable. But I challenge you to demonstrate that it can be cost effective in today's mainstream software markets. Until this is shown, I don't think that such methodologies merit consideration.
It's probably hard for most people here to imagine, because email is part of
our way of life. But inefficient use of email is a real problem at some
companies. Of course, as is typically the case, the fault isn't with email,
but with dysfunction in the company.
Email is an incredibly efficient means of communication. Senders can
compose their thought without taking anyone else's time. They can multicast
without getting people in the room or on the phone. All communications can
be archived. Recipients can automatically file and prioritize. They can
decide what to read, when to read it, when to stop reading. They can
delete, file, defer. They can compose a reply to whichever points they
wish, along-side the original message, all on their own time. Linux kernel
developers probably get (at least) an order of magnitude more mail than the
average office worker, but kernel development remains efficient.
Yet companies really do try to curtail email, all because some employees
have bad email skills, which sets off the managers who have the old-school
intuition that communication should be carefully channelled. This matters
because, incredible as it may seem, it will probably affect you sometime.
You will find yourself in a situation where there is pressure, or even a
dictum, to ration email. To combat this, we must help people use email
efficiently.
Unfortunately, I don't know exactly how to do this, because I think the biggest factor is
psychological. People who have become comfortable with traditional business
environments are used to hearing only what they need to hear. Yes--this includes techies, many of whom expect to think only about their particular domain. They become
anxious or confused when they get something that doesn't directly apply to
them. They need to learn that 1. skimming this email can be valuable,
because they will learn more about related activities in the company, and
discover unexpected ways in which they can advise or contribute; and 2.
deleting or filing messages without reading them can be ok.
Has anyone seen an "email skills" approach that worked?
It's amazing how many technically literate people have a poor understanding of large numbers. The article proposes distributed caching of checksums generated by genuine AOL clients. They then (implicitly) apply the argument, "it's distributed, so it will scale as far as we'd like it to".
Suppose that aim.exe is one megabyte in size. Then the number of ranges you could be asked to checksum is around 10^6 * 10^6 = 10^12 (note to nitpickers: this is an order-of-magnitude calculation). This means that if 1000 "legitimate" logons are cached every second, it would take years for the cache to warm.
This is the reverse of the dismally failing attempt to push multicasting, by concentrating on the backbone.
You don't seem to understand how the MBone works. It's the opposite of concentrating on the backbone. Users behind the multicast router get real multicast, and the router tunnels it over unicast IPv4.
The lesson of the MBone is that even when you can put real multicast on people's desktops, the infrastructure still resists change.
Yeah, perhaps the question would have been better phrased,
In
Giving it away, you suggested that we could all easily make ketchup in our kitchen sinks. I tried and succeeded only in making a mess. Can you give us that recipe?
But you have to rush if you want anyone to read what you write on slashdot;-)
Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl?
It just so happens that I know exactly one such person--and he is (without a hint of exaggeration) a mind of genious caliber. Hmm... Well, I guess you've taught me that I should forget about becoming a C++ expert. Thanks!
Unfortunately it means ditching miles of code written for the widget toolkit not used, but that's par for the course when building standards.
You don't seem to have much practical knowledge of standards! Standards typically go out of their way to include all of the features people already use. "Par for the course" would probably be a superset of Gtk and Qt (if you can imagine that!).
Seriously, go to a standards meeting sometime and suggest ditching functionality that some committee member's company uses. If an end to the "UI wars" is found, it won't be a in a standards body.
I'd like to think that a strong organization can resist the anti-engineers. But in truth, they scare me to death. They seem to have a source of power and persuasion that is foreign to me. They impede technical excellence more thoroughly than managers, marketing, and sales put together. The way to stop them is to get the results they could never achieve and make sure the PHB's see that your methods work, and theirs don't. But it's not easy, and the struggle never ends.
Why on earth does this article pit "engineers" against "people"?
Because of one important difference: we (engineers) should know better.
The managers may be above the engineers on the org chart; but in practice, that is merely a rough abstraction. The guys in the trenches have enormous influence over how a project develops.
Anyone who says the engineers' duty is to rotely carry out the designs and requirements handed to them is either naive or hopelessly jaded. A balanced organizaton includes engineering pushing for technical excellence, and demonstrating that it pays off. In fact, good management wants to trust engineers' judgement, because they have expertise that can't be found elsewhere in the company.
The upshot of this is that engineers do deserve the blunt of the blame for bad software, because we should know better, and we shouldn't allow it. Yes, there are times to compromise in order to get the product into a customers hands. But there are also times to take a stand. And even more important, we should find time on a regular basis to work on things that our managers didn't ask us to do, but will improve software quality. That's not going behind your boss's back, it's part of doing your job. A good manager will respect and appreciate that.
Slashdot Mirror
Sharing is the very idea of all genial human relationships. The notion that socialism has a monopoly on sharing is absurd. Socialism is about forced sharing, which isn't sharing (in the common sense) at all.
(abuse)
of copyright (the institution) to advance the cause of a community
with you so far
that operates according to a more socialist economic principle.
You seem not to see it, but it is a huge leap to equate sharing of software to an overall "socialist economic principle". What many people don't realize is that RMS is very little interested in economic and political reform. His goals (to a first approximation) stop at creating enough free software that people who don't want to use proprietary software, don't have to (and at convincing people that they don't want to use proprietary software). I don't think you can read RMS's writings (esp the GNU manifesto) carefully and come up with evidence for anything more radical.
Yes, RMS has become involved in politics at times and has mentioned a "software tax". But this is such a minor part of his activities, and so moderate in today's political climate (even in the US), that I don't think you can draw any significance from it.
A lot of your argument seems to be based on the fact that Free Software is compatible with socialism, therefore Free Software must be associated socialism. This is logical nonsesnse; and given that flamboyant capitalists like ESR support Free Software, is manifestly pure bunk.
Your evidence is all extremely circumstantial. Show me where RMS criticizes capitalism in principle, or advocates wide-scale political reform (socialist or any other kind, for that matter). Given that he recently lauded America's founders, who stood solidly on free-market principles, I think you will find it impossible. RMS has explicitly said he is not a communist (can't remember where, but he said it point blank); I don't know how far apart you think communism and socialism are, but I would expect a socialist to express some sympathy for communism.
Please cite evidence. I think you (like others) are trying to co-opt RMS for your own cause. Low.
There is a major bug in your program: you are keeping a backup of the offensive file. It should be permanently eradicated. You might consider writing the correct version to a different disk, and destroying the old disk when you are done.
I think everyone will relate to what you said (very well!)--but if anyone has trouble, try imagining Pedro Martinez pitching to Babe Ruth. Even though the game is substantially unchanged over 100 years, I just can't do it.
I have heard from people who have signed over copyright that the FSF agreement allows you to offer the software under alternative licenses.
As you say yourself: commercialization is very different from discovery. And as the constitution says clearly, patent protection may be awarded only for the second. So while profit incentive may be necessary for commercialization, it will have to be found without the help of patents. Fortunately, as the history of capitalizm has amply demonstrated, entrepreneurs and businesses have many other means of making profits. (I think that's a good thing, on balance.)
I don't have numbers (probably only large espionage organizations do), but I'm willing to bet that's not true.
Buffer overruns undeniably get a lot of coverage on bugtraq--if you casually read the list, you'll be forgiven for thinking that buffer overruns are the overwhelming bane of computer security. But there are two biases to this observation:
-
Buffer overruns get more talk than vulnerability reports. Go to the vulnerability database at SecurityFocus and browse the recent
reports. On the first
page, there are 28 vulnerabilities, of which only three explicitly
mention buffer overruns. Even assuming that this is an unusually low
number, and that a few buffer overruns aren't labeled as overruns, and allowing that buffer overruns tend to be more serious than the
average vulnerability, this is hardly a preponderance.
-
bugtraq report statistics probably over-represent
buffer overruns. This is related to the above discussion--buffer overruns
are popular and well-worn ground. If you report one, everyone will
understand it and you'll win sure ego points. So if you're going to search
for vulnerabilities, you'll probably search for buffer overruns.
In short, even if we stop using languages with unsafe pointers tomorrow, our security woes will continue in full force.I frankly think the reason the discussion on bugtraq seems dominated by buffer overruns is that the community enjoys, and is comfortable, discussing buffer overruns. Even though the same religious issues (bounded arrays, language choice, non-executable stack, stack-guarding libraries) are rehashed over and over, people never get tired of them. Buffer overruns have a cherished place in security folklore. This is kinda nice in that it gives the community a common ground, but dangerous because it leads people to overlook the importance of other program flaws that can result vulnerabilities.
Further, buffer overruns are plain easy to find. If you have source code, a few greps often take you right to the hole. Even if you don't, tools like fuzz do pretty well (many bugtraq reports indicate that tools like this were used to find the overrun). Plus, contrary to what you might think, buffer overrun exploits are ususally easy to write, so don't think that turns of any would-be security gurus. Other classes of vulnerability usually require more analysis of program logic to find.
I don't think you'll find many pixels on the original Star Wars film.
Yes it is the same Robert Morris, but for Pete's sake, don't mod me up so everyone knows!
The excess of moderator points hasn't subsided.
Wrong. Software engineering practices like tracking the severity and priority of bugs are aimed at creating higher quality software. Instead of developers spending time fixing bugs that are unimportant or not as annoying to the user, they have a way of categorizing and fixing bugs on a scale of importance.
You're saying the same thing I said. Bug tracking helps communication. People know where the nasty problems are, and nothing falls through the cracks.
Yet people like you will bitch that Microsoft shouldn't release software with known severe bugs. I guess if they didn't track bugs they would be able to say they didn't know that there were any severe bugs with a clear conscience.
That must be the most common fallacy on Slashdot: that everyone here thinks the same thing. I myself understand very well that Microsoft's business requires them to release software with serious bugs. I also know that I have the choice of software developed under a better (for me, at least) model.
Programming is certainly not engineering. Why? The requirements are nowhere near well enough defined. And with the pace of the field, it's not worth anyone's time to define them to "engineering" precision. This is simply a fact at this stage of the game.
So if the members of the team come up with the rules for what makes a bug a certain severity and what marks a bug as a certain priority exactly why can they not base releasability on these metrics?
For the same reason that "the law is an ass", "metrics are an ass". Even if developed by reasonable people with good intentions. See below.
Quite frankly, waiting until the software "feels right" before releasing it is probably the most ridiculuos thing I've ever heard.
Where did you get the idea that I want to release software based on good vibes and burning entrails? Look, I'm saying that you use all the evidence that you have available. But you use it more in the manner of a historian arguing a thesis, not a mathematicial constructing a proof. These are different modes of thinking, but each is valid in its domain. Or do you think history is new age bullshit?
On the other hand saying "we won't release until all the bugs that cause core dumps/segfaults/BSODs are fixed (severity one)" or that "we won't ship until we fix the annoying UI issues (priority one or two)" are quite reasonable even from a common sense point of view.
Depends what you mean. If you mean, "We reviewed the bug db and the beta tester feedback, and everyone agrees that we can release when the four known crashes are fixed, barring unforseen new issues", then I'm with you. If you mean, "Welcome to the new project, team; we're going to ship when the feature-set is implemented and there are no sev 1 bugs", you're fooling yourself. There are just too many possibilities, and no bug database can objectively capture the complex reality of a software project. Any hope that metrics will guide you is (pardon the slang) just wanking.
Interestingly most users of Windows 98 I know judged the software on its bug count (i.e. how many crashes needing reboots per day or other ridiculuos problems per day)
Really? They don't care about the zillions of applications they can run? What proportion of Windows users quit using it because of the bugs? If it's not high, then bug count is probably not a significant factor in the success of Windows.
Do you really think Mozilla, GNOME, KDE, Apache, the Linux kernel, OpenBSD, etc are shipping "stable" releases of software without keeping an eye on bug severities and priorities?
The projects I follow most closely are Linux and Debian. Debian explicitly eschews specific release criteria based on hard experience. Linus has been known to release kernels that don't compile.
They may choose to ignore them for one reason or the other but they are keeping track.
Hear my point: bug databases are good because they assist in keeping track. Releasing based on a formula is bad. "Ignoring bugs for one reason or another" represents the practice I advocate: look at the evidence (including bug database), apply intelligence, draw conclusion.
Using bug count and severity as a measure of "releasability", however, is the fallacy of feeble-minded managers, who are afraid to make a decision without a number to back it up. Software development (as practiced in all but epsilon of cases) is simply not a measurable process. You will only waste your time trying to quantify it.
Releasability can only be determined by the judgement of the team working on the release (which may include developers, testers, release managers, beta testers, partners, etc). That is not to say that you should not draw upon the bug database for evidence upon which to base your judgement. But it requires intelligent interpretation, not counting up some totals.
Some people consider this a failing of the software development process. I think they are too quick to condemn. The customer doesn't (usually) judge software by its bug count. Most software is judged by an overall feel: if the software is compelling, many deficiencies will be overlooked. Further, it is difficult to guess ahead of time (even with beta testing) which bugs will really bite people and impede their use of the software. Given the many interacting factors that determine the success of software, release decisions are naturally more art than science.
I know, I haven't presented any hard evidence. I'm arguing from experience in both free and closed software projects, and appealing to common sense. Most free software is released "when it's ready", without any metrics. Ponder on whether this is a strength or a weakness. And remember that when someone gives you number, the burden is on him to show that the number means something.
Finally, before someone else points it out, I know that software can be developed with sufficient care and process that it is measurable. But I challenge you to demonstrate that it can be cost effective in today's mainstream software markets. Until this is shown, I don't think that such methodologies merit consideration.
Go read gnu.org. That's not what they want at all. Maybe when you realize what they want, what they do won't seem so strange.
Email is an incredibly efficient means of communication. Senders can compose their thought without taking anyone else's time. They can multicast without getting people in the room or on the phone. All communications can be archived. Recipients can automatically file and prioritize. They can decide what to read, when to read it, when to stop reading. They can delete, file, defer. They can compose a reply to whichever points they wish, along-side the original message, all on their own time. Linux kernel developers probably get (at least) an order of magnitude more mail than the average office worker, but kernel development remains efficient.
Yet companies really do try to curtail email, all because some employees have bad email skills, which sets off the managers who have the old-school intuition that communication should be carefully channelled. This matters because, incredible as it may seem, it will probably affect you sometime. You will find yourself in a situation where there is pressure, or even a dictum, to ration email. To combat this, we must help people use email efficiently.
Unfortunately, I don't know exactly how to do this, because I think the biggest factor is psychological. People who have become comfortable with traditional business environments are used to hearing only what they need to hear. Yes--this includes techies, many of whom expect to think only about their particular domain. They become anxious or confused when they get something that doesn't directly apply to them. They need to learn that 1. skimming this email can be valuable, because they will learn more about related activities in the company, and discover unexpected ways in which they can advise or contribute; and 2. deleting or filing messages without reading them can be ok.
Has anyone seen an "email skills" approach that worked?
Suppose that aim.exe is one megabyte in size. Then the number of ranges you could be asked to checksum is around 10^6 * 10^6 = 10^12 (note to nitpickers: this is an order-of-magnitude calculation). This means that if 1000 "legitimate" logons are cached every second, it would take years for the cache to warm.
You don't seem to understand how the MBone works. It's the opposite of concentrating on the backbone. Users behind the multicast router get real multicast, and the router tunnels it over unicast IPv4.
The lesson of the MBone is that even when you can put real multicast on people's desktops, the infrastructure still resists change.
... but it takes a score 2 reply with a different subject for any moderator to realize it :-)
But you have to rush if you want anyone to read what you write on slashdot ;-)
Which brand of ketchup do you buy?
It just so happens that I know exactly one such person--and he is (without a hint of exaggeration) a mind of genious caliber. Hmm... Well, I guess you've taught me that I should forget about becoming a C++ expert. Thanks!
You don't seem to have much practical knowledge of standards! Standards typically go out of their way to include all of the features people already use. "Par for the course" would probably be a superset of Gtk and Qt (if you can imagine that!).
Seriously, go to a standards meeting sometime and suggest ditching functionality that some committee member's company uses. If an end to the "UI wars" is found, it won't be a in a standards body.
Did you look at the example IDs? There were seven of them, and they varied in only 8 bits.
Nice post.
Because of one important difference: we (engineers) should know better.
The managers may be above the engineers on the org chart; but in practice, that is merely a rough abstraction. The guys in the trenches have enormous influence over how a project develops. Anyone who says the engineers' duty is to rotely carry out the designs and requirements handed to them is either naive or hopelessly jaded. A balanced organizaton includes engineering pushing for technical excellence, and demonstrating that it pays off. In fact, good management wants to trust engineers' judgement, because they have expertise that can't be found elsewhere in the company.
The upshot of this is that engineers do deserve the blunt of the blame for bad software, because we should know better, and we shouldn't allow it. Yes, there are times to compromise in order to get the product into a customers hands. But there are also times to take a stand. And even more important, we should find time on a regular basis to work on things that our managers didn't ask us to do, but will improve software quality. That's not going behind your boss's back, it's part of doing your job. A good manager will respect and appreciate that.