... and the 'poor planning' simile fits forced IP6 adoption far better than IP4 addy assignment audit/revision across the board.
The OP is right. Many organizations have large IP4 blocks that are not justified or properly utilized. I recently encountered a city hospital (!!) in northern NJ which has a PUBLIC IP4 ip for every floor. Pretty silly and exactly what the OP is talking about. Never mind the old A, B, C type allocations that have been left alone since old post ARPA days. If an organization wants a public IP4 addy, it should get only one and manage it properly. Yes that will take some work, but far easier than IP6 implementation.
The real IP6 motivation appears to be that Big Brother wants to be able to trace all traffic directly to a specific source host, which full IP6 adoption would make possible. IP6 adoption should be resisted by the free world on that principle alone.
Furthermore, you do realize that most IP4 and IP6 stacks are usually implemented separately, right? Considering that the US gov't is evidently still having trouble securing its IP4 based hosts, imagine how it is going to do with the challenge of securing them in an IP6 environment.
Can you say - come in - we are open, wide open, i.e. "Welcome, Chinese hackers..."
"The Identity Ecosystem reduces the risk of exploitation of information by unauthorized access through more robust access control techniques." (pgs 4-5)
If the author is this tentative in the Executive Summary, I don't have much confidence that the result will be anything solid.
Besides, the EFF and such should oppose the imposition of any government identity 'mandates'. I know this draft says that "participation in the Identity Ecosystem is voluntary for both organizations and individuals", but we all know how these things grow up into requirements.
Regarding CASE, there were/are a lot of tools mis-labeled as CASE tools.
In order for a CASE tool to deliver, there has to be a sound method behind it. You can tell a poor excuse for one because the marketing hype uses the term "methodology" instead of "method".
The number of people who truly understand software development methods, their history and their benefits and limitations is probably in the hundreds, worldwide. (Hint - they do not include Rumbaugh, Jacobsen and Booch.)
The goal of real CASE and the methods behind it, was to develop zero defect software. This was equivalent to attaining the highest level of SEI CMM, as imperfect as that 'standard' is/was.
What 'killed' CASE use is the money behind UML and Rational and... the tonnes of money to be made from consulting on defective software products. And... a lot of people, who had no idea what methods are, ran around messing up projects left and right saying they were using CASE and 'methodologies'.
Call it the perfect automobile syndrome - the product rarely breaks down and seldom needs replacement. What manufacturer would dare to produce a product that would not require replacement or parts?
So, during the 'CASE' golden era there were a lot of ignorant people touting 'CASE' and now there are some people writing articles about 'CASE'.
Just check out the pancreatic cancer survival stats. It's something like 10% survival one year after diagnosis, 4% five years afrer diagnosis. Detection almost always at latter stages when surgery not an option. Very nasty and fast cancer.
Jobs has classic symptoms - wasting away, losing weight.
My own father perished five weeks after diagnosis (stage iv). My father in law died nine months after diagnosis (stage ii).
the silly notion that human-reviewed code is somehow safe is a childish fairytale. i don't care how many of you repeat this old wife's tale - it's trivial to prove wrong...
if this were true, we would never ever see a software crash. all it would take is a careful human 'review'.
the dustbin of software system history is quite replete with 'code-reviewed' systems.
the same religious belief drives those who think that they are the only keepers of back doors and that these are so well hidden as to never be discovered by others.
lessee - how many bugs are there in these 'vetted' kernels?
most slashdot readers/posters are programmers that have no clue what methods are (hey insist on calling them methodologies like lame recruiters).
just because you've read a uml book or an article by a 'popular' author, does not mean that you have the knowledge to make comments that others could realistically use.
I would bet that most 'real' software engineers can predict what their code will do more than 90-95% of the time. I'm not saying that I can, but I like to think I'm getting there:).
Real engineers can do it 100% of the time.
As we all gain more experience we get to the point that most of the time we can just look over the code and see what it's going to do without having to run it.
The experience must be embodied in a set of rules that live outside of the individual and can be passed on to others. Individual experience does not count.
Real engineering specifications are separate from the implementation. Looking at the code is not engineering. Engineering is an abstraction.
There actually are Proof of Correctness tests that can be performed on code to ensure that it will perform it's desired function.
Ditto above. The proof must reside outside of the implementation realm and chronologically ahead of it.
And I've heard (not actually seen though) of software that will produce 100% 'correct' code. However, 100% correct code is usually not optimized at all and in doing the optimization is where most programmers fail and where bugs are often introduced.
Optimization can be seggregated in a separate architecture domain. Optimization of the code is up to the compiler.
The solution that Software Engineers use today is to just try to break the project up into managable components and hope each one of them is done correctly.
One of the properties of engineering is the knowledge of how to break up the system into manageable pieces and know that that is the best persistent approach.
However, if a component is not correct then the problem cascades into other modules that depend on that component.
The 'pieces' or domains, as I'd term them, must be independent. If they are not assembled correctly, they can be rearranged. The important difference is that with real engineering the incorrectness can be detected before implementation and that the rearrangement be feasible (because the domains are truly independent).
But in theory software can be written such that it doesn't have to be executed to know what it will do, however in practice this is usually not the case.
With current 'mainstream' techniques, this is possible only for the most trivial systems.
This is true all too often, but well managed projects may not be as rare as you think. I can tell you exactly what new features will exist in the next releases of my applications and how they will look and feel to the user.
Does this information reside in your head? If so, then it is not engineering.
In a well run project, you can write the app's user documentation before coding even begins. That's one difference between a programmer and a developer/engineer.
If this is solely in text form, it is trivial to prove that (unless the system is very, very simple) the text is incomplete, inconsistent and incorrect (i.e. does not reflect what needs to happen correctly). It will also be close to impossible to manage changes.
Unless development is done what I call cowboy-style (come into down, get the dirty work done, then get out asap, leaving a mess behind), any good developer should be doing pseudo-engineering.
I am not quite sure what you mean by the above statement (esp. the term pseudo-engineering).
This was indeed discovered very early on. The oldest reference I have is "Forgive them, for they know not what they do", which is, of course, found in the Bible's New Testament.
...as practiced in most shops it is not engineering. Can you accurately predict what the code will do before you run it? Betcha most of us cannot. Real engineers can predict the properties of the most complex product they are working on before implementing it, be it buildings, circuits, mechanical structures, etc. (Or even complex large automated computer systems.) For this to happen, they have models that accurately and completely represent the contemplated system. I have met few people in the software industry that even realize this.
If we built bridges the way most people build software, we'd all be dead because the testing (and problem discovery) would happen in production.
yes, it would seem to make sense, but... there was a post on/. recently proving the reverse. the domain was races.com. (attempted to search/. to link the url here, but no joy) apparently ownership of a domain is not the same thing as the ownership of a physical thing, at least not in the view of that court decision.
Heh. Ever had to try to salvage a project designed by someone using a CASE tool and prototyping environment who had no idea how a system should be designed? And who's manifest lack of skills weren't apparent because all his/her work looked so good?
The person using the CASE tool having no clue does not mean that methodologies and CASE tools are not effective.
Like anything, one must know what one is doing. Would you say that Linux performs badly because some utility may be poorly written by a newbie? I hope not!
Some methodologies and CASE tools are pure garbage even though they sell well. Popular does not mean right. The disasters do and will continue to speak for themselves.
Until effective methods and tools become widely accepted and used on large and complex systems, we will continue seeing these expensive disasters.
it's happened before with some sort of gamma ray cancer treatment machine a few years back. faulty software caused patients to be exposed to huge dosages much greater than intended and reported by the machine. i don't know what os that device ran, but of course, the court award (or settlement) must have been huge.
i do not care what windows it is running on, it will a good excuse to take the train and catch up on my reading. and i thought the checkout counter lasers were bad!
Slashdot Mirror
... and the 'poor planning' simile fits forced IP6 adoption far better than IP4 addy assignment audit/revision across the board.
The OP is right. Many organizations have large IP4 blocks that are not justified or properly utilized. I recently encountered a city hospital (!!) in northern NJ which has a PUBLIC IP4 ip for every floor. Pretty silly and exactly what the OP is talking about. Never mind the old A, B, C type allocations that have been left alone since old post ARPA days. If an organization wants a public IP4 addy, it should get only one and manage it properly. Yes that will take some work, but far easier than IP6 implementation.
The real IP6 motivation appears to be that Big Brother wants to be able to trace all traffic directly to a specific source host, which full IP6 adoption would make possible. IP6 adoption should be resisted by the free world on that principle alone.
Furthermore, you do realize that most IP4 and IP6 stacks are usually implemented separately, right? Considering that the US gov't is evidently still having trouble securing its IP4 based hosts, imagine how it is going to do with the challenge of securing them in an IP6 environment.
Can you say - come in - we are open, wide open, i.e. "Welcome, Chinese hackers..."
More spew from some NoBama pseudogeek.
From the Executive Summary:
"The Identity Ecosystem reduces the risk of exploitation of information by unauthorized access through more robust access control techniques." (pgs 4-5)
If the author is this tentative in the Executive Summary, I don't have much confidence that the result will be anything solid.
Besides, the EFF and such should oppose the imposition of any government identity 'mandates'. I know this draft says that "participation in the Identity Ecosystem is voluntary for both organizations and individuals", but we all know how these things grow up into requirements.
Regarding CASE, there were/are a lot of tools mis-labeled as CASE tools.
In order for a CASE tool to deliver, there has to be a sound method behind it. You can tell a poor excuse for one because the marketing hype uses the term "methodology" instead of "method".
The number of people who truly understand software development methods, their history and their benefits and limitations is probably in the hundreds, worldwide. (Hint - they do not include Rumbaugh, Jacobsen and Booch.)
The goal of real CASE and the methods behind it, was to develop zero defect software. This was equivalent to attaining the highest level of SEI CMM, as imperfect as that 'standard' is/was.
What 'killed' CASE use is the money behind UML and Rational and... the tonnes of money to be made from consulting on defective software products. And... a lot of people, who had no idea what methods are, ran around messing up projects left and right saying they were using CASE and 'methodologies'.
Call it the perfect automobile syndrome - the product rarely breaks down and seldom needs replacement. What manufacturer would dare to produce a product that would not require replacement or parts?
So, during the 'CASE' golden era there were a lot of ignorant people touting 'CASE' and now there are some people writing articles about 'CASE'.
Neither type has a clue.
Just check out the pancreatic cancer survival stats. It's something like 10% survival one year after diagnosis, 4% five years afrer diagnosis. Detection almost always at latter stages when surgery not an option. Very nasty and fast cancer.
Jobs has classic symptoms - wasting away, losing weight.
My own father perished five weeks after diagnosis (stage iv). My father in law died nine months after diagnosis (stage ii).
the silly notion that human-reviewed code is somehow safe is a childish fairytale. i don't care how many of you repeat this old wife's tale - it's trivial to prove wrong...
if this were true, we would never ever see a software crash. all it would take is a careful human 'review'.
the dustbin of software system history is quite replete with 'code-reviewed' systems.
the same religious belief drives those who think that they are the only keepers of back doors and that these are so well hidden as to never be discovered by others.
lessee - how many bugs are there in these 'vetted' kernels?
must be all those ad revenue stealing firefox browsers
With the Chinese military devoting huge amounts of time to rebooting WinDoze clients, there will be no time to train and wage war.
since it took vi 20 yrs to get to where emacs was 20 yrs ago.
it will kill all electronics in its path - regardless of radio, CD, tape, 8-track ;-)
[EMF=elecro-magnetic frequency]
Linux does not
1) crash as often as M$ Windows
2) get owned as often as M$ Windows
gee - we had topple on our dec 20s wayyy back in the 70s....
just because you've read a uml book or an article by a 'popular' author, does not mean that you have the knowledge to make comments that others could realistically use.
Real engineers can do it 100% of the time.
As we all gain more experience we get to the point that most of the time we can just look over the code and see what it's going to do without having to run it.
The experience must be embodied in a set of rules that live outside of the individual and can be passed on to others. Individual experience does not count.
Real engineering specifications are separate from the implementation. Looking at the code is not engineering. Engineering is an abstraction.
There actually are Proof of Correctness tests that can be performed on code to ensure that it will perform it's desired function.
Ditto above. The proof must reside outside of the implementation realm and chronologically ahead of it.
And I've heard (not actually seen though) of software that will produce 100% 'correct' code. However, 100% correct code is usually not optimized at all and in doing the optimization is where most programmers fail and where bugs are often introduced.
Optimization can be seggregated in a separate architecture domain. Optimization of the code is up to the compiler.
The solution that Software Engineers use today is to just try to break the project up into managable components and hope each one of them is done correctly.
One of the properties of engineering is the knowledge of how to break up the system into manageable pieces and know that that is the best persistent approach.
However, if a component is not correct then the problem cascades into other modules that depend on that component.
The 'pieces' or domains, as I'd term them, must be independent. If they are not assembled correctly, they can be rearranged. The important difference is that with real engineering the incorrectness can be detected before implementation and that the rearrangement be feasible (because the domains are truly independent).
But in theory software can be written such that it doesn't have to be executed to know what it will do, however in practice this is usually not the case.
With current 'mainstream' techniques, this is possible only for the most trivial systems.
Does this information reside in your head? If so, then it is not engineering.
In a well run project, you can write the app's user documentation before coding even begins. That's one difference between a programmer and a developer/engineer.
If this is solely in text form, it is trivial to prove that (unless the system is very, very simple) the text is incomplete, inconsistent and incorrect (i.e. does not reflect what needs to happen correctly). It will also be close to impossible to manage changes.
Unless development is done what I call cowboy-style (come into down, get the dirty work done, then get out asap, leaving a mess behind), any good developer should be doing pseudo-engineering.
I am not quite sure what you mean by the above statement (esp. the term pseudo-engineering).
This was indeed discovered very early on. The oldest reference I have is "Forgive them, for they know not what they do", which is, of course, found in the Bible's New Testament.
...as practiced in most shops it is not engineering. Can you accurately predict what the code will do before you run it? Betcha most of us cannot. Real engineers can predict the properties of the most complex product they are working on before implementing it, be it buildings, circuits, mechanical structures, etc. (Or even complex large automated computer systems.) For this to happen, they have models that accurately and completely represent the contemplated system. I have met few people in the software industry that even realize this.
If we built bridges the way most people build software, we'd all be dead because the testing (and problem discovery) would happen in production.
yes, it would seem to make sense, but... there was a post on /. recently proving the reverse. the domain was races.com. (attempted to search /. to link the url here, but no joy) apparently ownership of a domain is not the same thing as the ownership of a physical thing, at least not in the view of that court decision.
The person using the CASE tool having no clue does not mean that methodologies and CASE tools are not effective.
Like anything, one must know what one is doing. Would you say that Linux performs badly because some utility may be poorly written by a newbie? I hope not!
Some methodologies and CASE tools are pure garbage even though they sell well. Popular does not mean right. The disasters do and will continue to speak for themselves.
Until effective methods and tools become widely accepted and used on large and complex systems, we will continue seeing these expensive disasters.
it's happened before with some sort of gamma ray cancer treatment machine a few years back. faulty software caused patients to be exposed to huge dosages much greater than intended and reported by the machine. i don't know what os that device ran, but of course, the court award (or settlement) must have been huge.
i do not care what windows it is running on, it will a good excuse to take the train and catch up on my reading. and i thought the checkout counter lasers were bad!
At least now I don't have to take the cover off to see how deep the dust is piled up inside!
Too bad that its so ugly, that I have to cover it up!