No, mathematics is exactly that: a description of the phenmoena. The "laws" we're always talking about are just reasonable expectations of consistent phenomena, phrased to exclude irrelevant factors and products, while describing the relationships between the phenomena actually involved.
And. Making unwarranted and usually untrue assumptions about the nature of the relationship. Kinda like all hills have straight sides.
What is true is that mother nature sides with the hidden, and whatever and whenever causes stuff to be hidden increases the odds of mother nature biting you in a place you didn't know you had.
That's because they don't teach it the way it was developed. What you learn is a santised version and you learn it in the wrong order (compared to order of discovery and development).
Incorrect might not be the right word, it was not mathematically rigorous. There were instances when he treated an infintesimal as a zero and discarded it, there were instances where he treated it as a non-zero and divided it. Math is rigorous. You need a set of rules that hold in all situations. [Emphasis added]
A set of rules that hold in all situations means that there are no paradoxes. There is nothing non-rigorous about infintesimals which behave in some cases identically with zero when added to something and in other cases behave like non-zeros when dividing two of them. What is non-rigorous and non-defensible is the attempted distinction between zero and non-zero. Not everything mathematical is a number. In fact most mathematical things are not numbers. It all has to do with functions from spaces to spaces that preserve interesting properties.
Unbillable hours. Your employer pays you for those hours. Your employer can't bill someone else for those hours. Pretty much irrelevant as to how much of a job it is.
Good one. Open Source, with a few eyeballs, simple trivial bug. Closed Source, after it has been used in an exploit, without access to that source, would be an interesting bug.
My sympathies. I'd expect your employer's QA group would be in for some rude shocks if they tried for ISO certification. It's not all that hard, but what you do has to match what you claim you do and it has to be documented. Done right it's productive and not all that difficult.
they would do themselves and us developers a favor to incorporate some of the oldest "lessons learned" into the tools.
The lessons have never been learned. Old Burroughs hardware had that stuff built in. The problem is that programs that would seeminging run on other stuff would blow up on Burroughs because the hardware refused to perform the logically illegal operations. There's an awful lot that you can do that is blatantly wrong that nobody will ever notice. If that something hasn't bitten you yet, hard enough and often enough, you keep using it. Unfortunately, the solution to any of these problems will be to throw more and more of what causes the problems into the mix.
In theory QA sounds great. In practice though QA does not produce anything other than process.
Nah, I think you are assuming that QA is strictly about improving quality. Qa is more like a pair of eyeballs so you can see what quality and/or the lack of quality is really costing you so that you can make intelligent trade-offs. Perfect quality is rarely achievable and almost never worth the required effort.
It's more like improving highway safety by putting up streetlights so people can see and be seen.
Quality software is achievable in any language through hard work and discipline. No tool will replace discipline, no matter how silvery and bullety it looks.
Correct. It is achievable in any language in finite time. Given adequate discipline it can be toggled into a machine in machine language. In finite time.
The above is technically correct but irrelevant for what is practicably attainable. It really boils down to matters of efficiency. Effecient use of all limited resources including discipline. There are no silver bullets, but there are places where the current state of the art is woefully lacking. Handling interfaces now is worse than it was 30 years ago, because there are so many more of them now if for no other reason.
Unfortunately, most programming languages refuse to support contracting in any form
Worse, they do not allow you to specify in which direction the information flows. There is no syntactic distinction between an output variable and an input variable. That's like installing a check valve with no indication of which direction.
I suspect that the answer lies in discovering that CALL must be a callable function and that systems must be capable of sufficient isolation that modules cannot interact interact except through defined interfaces. Much more likely to happen with interpreted languages, even with absolute machine efficiency is required. As an old-time Assembly programmer, I'm amazed as how lacking in high-level concepts the "high-level" languages are.
At the end of the day, the KISS principle is the single greatest enemy of bugs. Gives 'em fewer places to hide.
Unit tests are no more than glorified sanity checks. As a sanity check, should be useful, but any assumption that they mean much of anything makes me suspicious. If by unit test, they mean an ene-to-end test of the unit in a live buggy system, then it has some good value, but it sounds too much like trying to use the fact that it works correctly in a carefully controlled environment to imply that it has to be somebody else's problem.
"Compounding the situation even further is the incentive for businesses to deny all knowledge and point fingers when software errors are uncovered. If there are several parties responsible for the maintenance of a piece of software, he said, it's in everybody's interests that the other person fixes the bug because the customer will assume that whoever fixes the bug was responsible for it."
The bugs caught by unit testing tend to be the simple trivial bugs. Boring. The interesting bugs are when it takes two of them together for anybody to notice anything. I've even seen a triple. These are what you run into in integration and later in production after everything is supposedly tested and debugged. You can't find these with unit testing. Only in combination can you even see that it is a bug. Both of them.
If there is a bug in the spec, that is enough to ensure that any implementation is buggy. Buggy if it follows the spec. Buggy because it does not follow the spec. The spec being wrong cannot make any implementation right.
either way, successful software is a combination of good programming and good management.
From somewhere log ago I read something that there is about an 85% overlap in the skill set required for good management and good programming. Both have to make do with conflicting goals and limited resources. Bad management and bad programming is a bad combination. Bad management and bad anything is bad, but seems that the situation is much worse with programming because programmers can instinctively pass sound judgement on managers and managemet style. This doesn't mean what a manager would expect. It's more like the color is red or blue.
Management listen? The blunt reality is that if management had any intention of listening, it would be doing it themselves. In fact, one of the places where pair programming works is to team a manager with a programmer. However, even then finding an ear to bend will happen only in those few moments when neither of you have anything better to do. Sorry.
Sounds like SUBROUTINE Like in prehistoric FORTRAN.
Now if you need something that doesn't have to evaluate its arguments, there's Lisp.
This "skilled in the art" thing. Is it supposed to mean something? There's a lot of Computer Science that was independently invented by a lot of people before there was anything like a Computer Science curriculum.
Novell needs to make a choice and go forward with one desktop.
Nah, any single choice is demonstrably wrong. Between Gnome and KDE, some will prefer one. Some will prefer the other. Some will keep changing their minds. Some people even like to wear more than one color of shirt.
To simplify, if businesses wanted a vendor-supported "kitchen sink", they would already be using ClubMandrake. Some yes, Others will somehow or another have a different set of priorities as to being attracted to the cutting edge while avoiding as much as possible the bleeding edge. There will be a large number of distributions, even supported distributions, which will differ on those priorities. If Novell is well atuned to the priorities of its customers, Novell should do very well provided their software is not markedly inferior to everyone else's. I would expect, for Novell's (and its customers') priorities, it will be markedly superior. This is not nearly so simple as finding the right spot on a cutting-edge - stable curve. The optimum point depends. On a lot of things. An enterprise version on a lightly loaded home server is not necessarily more stable than the latest hacker-grade release candidate! The priorities are that different.
And the effects of war can be very long term indeed. Iraq is smack dab in the middle of the fertile crescent, the cradle of world civilization, if my bad memory of world history serves.
Totally off topic, but bringing in a lot of foreign workers to rebuild Iraq, while the onlookers are out-of-work Iraqis has to about as insulting and dumb as you can get.
I am in the camp that believes critical software-mechanical projects can be successfully managed.
Agreed. And it's not just the critical systems.
The easiest and cheapest, and maybe most effective, is to design so that no one bug is capable of causing the system to do anything way out of proportion to the cause. The system should be survivable even when everything (else) is extremely buggy. Then you find and get rid of the bugs, both of 'em. Sometimes the only way to find a bug is with the help of another bug.
When something does fail, you overanalyze everything that participated in the failure. It's never really just one failure.
The problem as I see it is the Administrators don't know when they are being taken for a ride by the "consulting companies" that they bring in to do the work.
Bingo. While the school probably requires something better than home or hacker-grade equipment, they certainly do not need nor should they pay the exhorbitant premium required for five nines reliability. There is a conflict of interest in the consulting company, as the margins are better and bigger on the high ticket items. "And of course you want the best for the children." If you figure in things like snow days, that's what? About one nine?
The reason the Federal government is involved here is because the Federal Government benefits when the population of the entire country is better educated.
Another reason for government involvment is when the return is long-term as opposed to short-term. If the water and sewage systems had to have a five-year payout, we'd all be much worse off. It is also to the long-term interests of the cities to do a bit to improve conditions in the hinterlands.
FCC policy we have today is leading us to an Information Superhighway of privately owned toll roads. Information Superhighway? That's a rational goal, certainly not what we've accomplished. With a mess of privately owned toll roads, we have a mess of goat tracks trying to pretend to be an Information Superhighway.
Methinks that's key. It does not translate into an unreasonable expectation of privacy. Networks, particularly the internet, are a lot like the old POTS party lines. There is some expectation of privacy but not a lot. I suspect that a lot of problems with malware, etc. are essentially due to an unwarranted and unneeded sense of privacy and security.
Public places that allow visitors/customers to use the network. Best analogy I can come up with is a storefront with a public vestibule with bulliten boards, etc. There is a big difference between just leaving the front doors open and giving visitors or potential customers a key to that front door. If I'm giving the key out to "everybody" all I can be doing is givng myself a false sense of security and to some extent compromising the internal security of the few things that do matter.
[rant] Office doors. They have locks. Most doors, most people, are "never" locked. Desk drawers. Same situation. Computers and computer files. Almost certainly not the most sensitive stuff in the office. The idea that just because it is on a computer it is secure, seems ridiculous. The few people that actually need some degree of securty are very easy to work with. These are the same people who take the trouble to lock their door when they leave. In fact their security is their security, not IT's. The situation would be different with masses of clerks messing with sensitive information, but that is somebody else's problem, not mine. In a discussion with our CEO, we figured out that "security" for top brass was at best counterproductive. Having everything open and aboveboard works better. It also has the interesting side effect that snooping is much more of a social no-no, giving a rather larger expectaton of privacy and security, so long as things are going as they should. When things are not as they should be, it is much less a breach of whatever security is relevant to talk on the phone to someone in your office, using your login with stuff where you last left it. [/rant] Thanks for your time.
I do know that if I want to allow use of my network
7. Add 'obvious' trusted sites like mozilla.org to trusted sites list (I can't believe mozilla forgot this!) Be very careful here.
I can. That's the user's choice and needs to be made intentionally, never by default. Specifically, it's not mozilla's choice to trust mozilla.
That little-bitty detail, all by itself, makes a large difference in the effective security. Trust everybody? They don't even trust themselves! Big difference in what the dumb users will click on.
Any chance that 2005 is the year of Linux on the desktop? =)
I think Linux is almost there already
Almost =)
Methinks Linux is (and has been) pretty much there.
When your big customers switch to a Linux desktop, then you switch. It doesn't even matter if you're ready or not or if Linux is ready or not. Until then, inertia pretty much rules.
I suspect that Novell will make a large difference. Corporate network. Netware is a controlled internal network. TCP/IP is an uncontrolled anything-goes anywhere network. There are lots of little-bitty things that reflect the inherent bias and overall exert a rather large amount of force. The inherent bias of Novell will make a Linux desktop much more attractive to business, primarily Novell Linux Desktop, but it will leak everywhere else.
Is Windows XPSP2 more secure now than Windows 95 was then? Is security a problem with Windows XPSP2? Was security a problem with Windows 95? Seems like there's something very fundamental that Microsoft has failed to grasp. I'd guess that whatever that something is, it's square in the middle of Novell's home turf.
Hey, wait a second, at "all" costs? Right. If the threat of terror, or more accurately the reaction to the threat of terror, does more damage than the terror itself, then the terrorists have won.
One wonders what F-Prot and Command-com antivirus need to do to get on the "trusted" AV list at Microsoft.
I'm wondering if I really want anything that's on Microsoft's trusted virus list.
Microsoft has too many irons in the fire, too many deals going on, planned, projected, for them to have any intention of cutting back to what is required for a trusted base. And whatever Microsoft doesn't, the OEMs will.
Actually we use F-PROT. Multi-user setup is simple and effective. Seems competent enough and distinctly less annoying than Norton.
Slashdot Mirror
No, mathematics is exactly that: a description of the phenmoena. The "laws" we're always talking about are just reasonable expectations of consistent phenomena, phrased to exclude irrelevant factors and products, while describing the relationships between the phenomena actually involved.
And.
Making unwarranted and usually untrue assumptions about the nature of the relationship. Kinda like all hills have straight sides.
What is true is that mother nature sides with the hidden, and whatever and whenever causes stuff to be hidden increases the odds of mother nature biting you in a place you didn't know you had.
That's because they don't teach it the way it was developed. What you learn is a santised version and you learn it in the wrong order (compared to order of discovery and development).
Fortunately.
Incorrect might not be the right word, it was not mathematically rigorous. There were instances when he treated an infintesimal as a zero and discarded it, there were instances where he treated it as a non-zero and divided it. Math is rigorous. You need a set of rules that hold in all situations. [Emphasis added]
A set of rules that hold in all situations means that there are no paradoxes.
There is nothing non-rigorous about infintesimals which behave in some cases identically with zero when added to something and in other cases behave like non-zeros when dividing two of them. What is non-rigorous and non-defensible is the attempted distinction between zero and non-zero. Not everything mathematical is a number. In fact most mathematical things are not numbers. It all has to do with functions from spaces to spaces that preserve interesting properties.
Unbillable hours.
Your employer pays you for those hours.
Your employer can't bill someone else for those hours.
Pretty much irrelevant as to how much of a job it is.
Good one.
Open Source, with a few eyeballs, simple trivial bug.
Closed Source, after it has been used in an exploit, without access to that source, would be an interesting bug.
My sympathies.
I'd expect your employer's QA group would be in for some rude shocks if they tried for ISO certification. It's not all that hard, but what you do has to match what you claim you do and it has to be documented. Done right it's productive and not all that difficult.
they would do themselves and us developers a favor to incorporate some of the oldest "lessons learned" into the tools.
The lessons have never been learned.
Old Burroughs hardware had that stuff built in.
The problem is that programs that would seeminging run on other stuff would blow up on Burroughs because the hardware refused to perform the logically illegal operations.
There's an awful lot that you can do that is blatantly wrong that nobody will ever notice.
If that something hasn't bitten you yet, hard enough and often enough, you keep using it.
Unfortunately, the solution to any of these problems will be to throw more and more of what causes the problems into the mix.
In theory QA sounds great. In practice though QA does not produce anything other than process.
Nah, I think you are assuming that QA is strictly about improving quality.
Qa is more like a pair of eyeballs so you can see what quality and/or the lack of quality is really costing you so that you can make intelligent trade-offs. Perfect quality is rarely achievable and almost never worth the required effort.
It's more like improving highway safety by putting up streetlights so people can see and be seen.
Quality software is achievable in any language through hard work and discipline. No tool will replace discipline, no matter how silvery and bullety it looks.
Correct. It is achievable in any language in finite time. Given adequate discipline it can be toggled into a machine in machine language. In finite time.
The above is technically correct but irrelevant for what is practicably attainable. It really boils down to matters of efficiency. Effecient use of all limited resources including discipline.
There are no silver bullets, but there are places where the current state of the art is woefully lacking. Handling interfaces now is worse than it was 30 years ago, because there are so many more of them now if for no other reason.
If that doesn't sound like false advertisement (fraud) then I dont know what is.
The way to cure such is to hold the EULA void and the perpetrator liable for consequential damages, real or imaginary.
Unfortunately, most programming languages refuse to support contracting in any form
Worse, they do not allow you to specify in which direction the information flows. There is no syntactic distinction between an output variable and an input variable. That's like installing a check valve with no indication of which direction.
I suspect that the answer lies in discovering that CALL must be a callable function and that systems must be capable of sufficient isolation that modules cannot interact interact except through defined interfaces. Much more likely to happen with interpreted languages, even with absolute machine efficiency is required. As an old-time Assembly programmer, I'm amazed as how lacking in high-level concepts the "high-level" languages are.
I agree.
At the end of the day, the KISS principle is the single greatest enemy of bugs.
Gives 'em fewer places to hide.
Unit tests are no more than glorified sanity checks.
As a sanity check, should be useful, but any assumption that they mean much of anything makes me suspicious.
If by unit test, they mean an ene-to-end test of the unit in a live buggy system, then it has some good value, but it sounds too much like trying to use the fact that it works correctly in a carefully controlled environment to imply that it has to be somebody else's problem.
"Compounding the situation even further is the incentive for businesses to deny all knowledge and point fingers when software errors are uncovered. If there are several parties responsible for the maintenance of a piece of software, he said, it's in everybody's interests that the other person fixes the bug because the customer will assume that whoever fixes the bug was responsible for it."
The bugs caught by unit testing tend to be the simple trivial bugs. Boring.
The interesting bugs are when it takes two of them together for anybody to notice anything. I've even seen a triple. These are what you run into in integration and later in production after everything is supposedly tested and debugged. You can't find these with unit testing. Only in combination can you even see that it is a bug. Both of them.
If there is a bug in the spec, that is enough to ensure that any implementation is buggy. Buggy if it follows the spec. Buggy because it does not follow the spec. The spec being wrong cannot make any implementation right.
either way, successful software is a combination of good programming and good management.
From somewhere log ago I read something that there is about an 85% overlap in the skill set required for good management and good programming. Both have to make do with conflicting goals and limited resources. Bad management and bad programming is a bad combination. Bad management and bad anything is bad, but seems that the situation is much worse with programming because programmers can instinctively pass sound judgement on managers and managemet style. This doesn't mean what a manager would expect. It's more like the color is red or blue.
Management listen?
The blunt reality is that if management had any intention of listening, it would be doing it themselves. In fact, one of the places where pair programming works is to team a manager with a programmer. However, even then finding an ear to bend will happen only in those few moments when neither of you have anything better to do. Sorry.
"program that help other programms".
Sounds like SUBROUTINE
Like in prehistoric FORTRAN.
Now if you need something that doesn't have to evaluate its arguments, there's Lisp.
This "skilled in the art" thing. Is it supposed to mean something? There's a lot of Computer Science that was independently invented by a lot of people before there was anything like a Computer Science curriculum.
Novell needs to make a choice and go forward with one desktop.
Nah, any single choice is demonstrably wrong.
Between Gnome and KDE, some will prefer one. Some will prefer the other. Some will keep changing their minds. Some people even like to wear more than one color of shirt.
To simplify, if businesses wanted a vendor-supported "kitchen sink", they would already be using ClubMandrake.
Some yes, Others will somehow or another have a different set of priorities as to being attracted to the cutting edge while avoiding as much as possible the bleeding edge. There will be a large number of distributions, even supported distributions, which will differ on those priorities. If Novell is well atuned to the priorities of its customers, Novell should do very well provided their software is not markedly inferior to everyone else's. I would expect, for Novell's (and its customers') priorities, it will be markedly superior. This is not nearly so simple as finding the right spot on a cutting-edge - stable curve. The optimum point depends. On a lot of things. An enterprise version on a lightly loaded home server is not necessarily more stable than the latest hacker-grade release candidate! The priorities are that different.
And the effects of war can be very long term indeed.
Iraq is smack dab in the middle of the fertile crescent, the cradle of world civilization, if my bad memory of world history serves.
Totally off topic, but bringing in a lot of foreign workers to rebuild Iraq, while the onlookers are out-of-work Iraqis has to about as insulting and dumb as you can get.
I am in the camp that believes critical software-mechanical projects can be successfully managed.
Agreed. And it's not just the critical systems.
The easiest and cheapest, and maybe most effective, is to design so that no one bug is capable of causing the system to do anything way out of proportion to the cause.
The system should be survivable even when everything (else) is extremely buggy. Then you find and get rid of the bugs, both of 'em. Sometimes the only way to find a bug is with the help of another bug.
When something does fail, you overanalyze everything that participated in the failure. It's never really just one failure.
The problem as I see it is the Administrators don't know when they are being taken for a ride by the "consulting companies" that they bring in to do the work.
Bingo.
While the school probably requires something better than home or hacker-grade equipment, they certainly do not need nor should they pay the exhorbitant premium required for five nines reliability. There is a conflict of interest in the consulting company, as the margins are better and bigger on the high ticket items. "And of course you want the best for the children."
If you figure in things like snow days, that's what? About one nine?
The reason the Federal government is involved here is because the Federal Government benefits when the population of the entire country is better educated.
Another reason for government involvment is when the return is long-term as opposed to short-term. If the water and sewage systems had to have a five-year payout, we'd all be much worse off.
It is also to the long-term interests of the cities to do a bit to improve conditions in the hinterlands.
FCC policy we have today is leading us to an Information Superhighway of privately owned toll roads.
Information Superhighway?
That's a rational goal, certainly not what we've accomplished.
With a mess of privately owned toll roads, we have a mess of goat tracks trying to pretend to be an Information Superhighway.
"reasonable expectation of privacy"
Methinks that's key. It does not translate into an unreasonable expectation of privacy. Networks, particularly the internet, are a lot like the old POTS party lines. There is some expectation of privacy but not a lot. I suspect that a lot of problems with malware, etc. are essentially due to an unwarranted and unneeded sense of privacy and security.
Public places that allow visitors/customers to use the network.
Best analogy I can come up with is a storefront with a public vestibule with bulliten boards, etc. There is a big difference between just leaving the front doors open and giving visitors or potential customers a key to that front door. If I'm giving the key out to "everybody" all I can be doing is givng myself a false sense of security and to some extent compromising the internal security of the few things that do matter.
[rant]
Office doors. They have locks. Most doors, most people, are "never" locked.
Desk drawers. Same situation.
Computers and computer files. Almost certainly not the most sensitive stuff in the office.
The idea that just because it is on a computer it is secure, seems ridiculous.
The few people that actually need some degree of securty are very easy to work with. These are the same people who take the trouble to lock their door when they leave. In fact their security is their security, not IT's.
The situation would be different with masses of clerks messing with sensitive information, but that is somebody else's problem, not mine.
In a discussion with our CEO, we figured out that "security" for top brass was at best counterproductive. Having everything open and aboveboard works better. It also has the interesting side effect that snooping is much more of a social no-no, giving a rather larger expectaton of privacy and security, so long as things are going as they should. When things are not as they should be, it is much less a breach of whatever security is relevant to talk on the phone to someone in your office, using your login with stuff where you last left it.
[/rant] Thanks for your time.
I do know that if I want to allow use of my network
7. Add 'obvious' trusted sites like mozilla.org to trusted sites list (I can't believe mozilla forgot this!) Be very careful here.
I can.
That's the user's choice and needs to be made intentionally, never by default.
Specifically, it's not mozilla's choice to trust mozilla.
That little-bitty detail, all by itself, makes a large difference in the effective security.
Trust everybody? They don't even trust themselves!
Big difference in what the dumb users will click on.
Any chance that 2005 is the year of Linux on the desktop? =)
I think Linux is almost there already
Almost =)
Methinks Linux is (and has been) pretty much there.
When your big customers switch to a Linux desktop, then you switch. It doesn't even matter if you're ready or not or if Linux is ready or not.
Until then, inertia pretty much rules.
I suspect that Novell will make a large difference.
Corporate network.
Netware is a controlled internal network.
TCP/IP is an uncontrolled anything-goes anywhere network.
There are lots of little-bitty things that reflect the inherent bias and overall exert a rather large amount of force.
The inherent bias of Novell will make a Linux desktop much more attractive to business, primarily Novell Linux Desktop, but it will leak everywhere else.
Is Windows XPSP2 more secure now than Windows 95 was then?
Is security a problem with Windows XPSP2?
Was security a problem with Windows 95?
Seems like there's something very fundamental that Microsoft has failed to grasp.
I'd guess that whatever that something is, it's square in the middle of Novell's home turf.
Hey, wait a second, at "all" costs?
Right. If the threat of terror, or more accurately the reaction to the threat of terror, does more damage than the terror itself, then the terrorists have won.
One wonders what F-Prot and Command-com antivirus need to do to get on the "trusted" AV list at Microsoft.
I'm wondering if I really want anything that's on Microsoft's trusted virus list.
Microsoft has too many irons in the fire, too many deals going on, planned, projected, for them to have any intention of cutting back to what is required for a trusted base. And whatever Microsoft doesn't, the OEMs will.
Actually we use F-PROT. Multi-user setup is simple and effective. Seems competent enough and distinctly less annoying than Norton.
My HP 55 calculator had almost exactly the same specs as ENIAC, memory, word size, stored program steps.
Suddenly I feel kinda old.