"it is not really a matter of what the subject of the bill is these days but rather that it is prudent to not let ANYTHING pass right now [at the Federal level] because we cannot control the time bombs they are writing into them until we get firmer legislation at the State level to protect ourselves from Federal overreach, stupidity, and corruption."
What is it about Wi-Fi that forces hot-spots to be free? If cellular outfits can 'protect' access to their towers with SIM cards, why couldn't Wi-Fi hot spots do the same?
And if hot-spots can be 'protected', why couldn't they impose charges?
And if hot-spots can be charged for, why do they HAVE to be free : muncipality-funded or not?
And given the technological potential, why couldn't such an arrangement be *far* less expensive (even if not costing zero) than today's conventional cellular services?
3) Cisco knows full well (but omits to mention) that Cingular will not allow Apple to "do VoIP" on its cells.
I have been thinking that finishing all the details on an arrangement of exactly this kind would be the holdup, a better explanation of what is going on than that Apple just went ahead and announced using the name anyway.
Although it makes sense that Cingular *might* not want this new Apple product able to *also* do VoIP... Cingular [now AT&T] *is* a big presence provider, Cisco *is* a big presence-infrastructure equipment vendor... ?
Are you doing more than just speculating when you flat out state that Cingular will not allow Apple to also provide VoIP? Not that my thoughts about what a killer product an iPhone running OSX and able to do *both* cellular *and* VoIP are anything more than speculation:). Should be interesting to see exactly what gets filed with the FCC.
This post is both informative and insightful. It, and the groklaw link it provides, deserve a thoughful read. It deserves a "5" - so, moderators, please bump it up.
Maybe - IANAL. But I encountered a firsthand, up-close-and-personal situation.
My company (and I) were deemed ineligibile to participate in implementing an OSI stack for an international project. The reason was that I and my team mates had worked on an earlier proprietary implemenation of an OSI stack, and that fact "posioned" us in the eyes of the contracting lawyers - we were ineligible to work on the contract despite - indeed, because of - our expertise in OSI protocols.
It was not a question of whether or not we intended to copy the code we had seen 'word for word'. It was a question of avoiding anything that made it likely that a court would be willing to formally hear an _allegation_ of copying. The contracting lawyers considered the risk of using anyone who had seen the code too great to approve using us.
===
Since IANAL, it might be that you are right, and that the contracting lawyers were worried about patent and not copyright challenges? But I fail to see how that changes the fact that seeing the code is dangerous.
I had fun, reading about the arguments SCO was making... with pattern analysis being done on Linux memory management routines in order to detect non-literal copying violations. But I would sure not consider it fun to come up with the money it took for IBM to defend against those arguments (which is the exact problem... you may be sure that you are right, but you cannot be sure how a court will rule and it will cost you a lot to get the ruling... and if you are in the US, there is no 'loser pays the winner' so you can recoup whatever you lost defending yourself, no matter how "SCOish" the challenge may be).
===
My own conclusion is still that it is dangerous to even look at the code. As others beside me have said on other places on this thread, this looks like a trap that the FOSS community would do well to avoid.
If you later write a piece of software that in any way resembles software for which M$ owns the copyright (where 'resemblance' will be something a lawyer can get to define in a court of law), and if you have looked, you could easily lose the copyright to your own work and be found guilty of copying from M$.
If you have had access to the source of a computer program, you need to be particularly concerned that you aren't unconsciously copying the original program when you write a similar program.
If what you write is successful enough to attract M$ lawywers, being able to say "I never even looked" could prove to be very important!
The problem is that the socket only has enough memory bandwidth for one cpu's worth of work.
This is exactly right. It is really surprising that Intel has focussed so completely, almost obessively, and for so long, on the problem of supplying the maximum number of work-cycles per unit of time (GHZ, Pipelining, Itanium's EPIC design) while seemingly paying so little attention to supply-of-work-to-do (FSB speed and architecture)
AMD has paid quite a bit of attention to the work-supply and has a much more efficiently balanced work-cycle-supply/ data-for-work design. http://www.hypertransport.org/ gives AMD a big leg-up over Intel.
If Intel fails to do something spectacular to FSB speeds, AMD is sure to continue to pull away from Intel. The more cores and threads per CPU, the greater AMD's lead over Intel will become (at least from a performance point of view), until Intel addresses this problem.
"Oh, I have an idea. Lets make OSS illegal since it hurts business".
You have given the best summary of what this author is really selling.
Leads off with IP laws (written before there was such a thing as software) and ends with:
"What we really need from government is an investigation of the long-term effects of OSS on our indigenous software industry, assistance to combat the threat to the industry's livelihood that OSS might pose"
No! What we need is for government to pay less attention to the "threat to the industry's livelihood" and more attention to removing obstacles to the rise of the public domain's interests, as is fostered by FOSS methods of product value development and delivery.
Pretty cute, too, use of "the industry" - as if processes and methods matter more than the public value of, and accessibility to, the product. And as if the 'proprietary' world's processes and methods are "the industry" while FOSS is not.
As pointed out in at least one other post, I think that - for example - IBM, Sun and HP would be surprised to discover that they are not in "the industry".
Interestingly enough, this is EXACTLY the way DEC interfaced with its customer base... at least through the 70s, when I worked there... and I believe through the beginning of the 80s as well.
DEC was, until the late 70s, a 'matrix organization' that had several market-focussed sales groups. The market-focussed sales groups drew on and shared a central engineering and manufacturing facility and an essentially independent software support organization. But the 'independence' of the support organization had to do with the matrix-of-product-lines nature of the sales orgainization so that a common support pool could be made available to sales... make no bones about it, sales was 'in charge'.
At field offices, particular software specialists tended to align with particular kinds of sales groups doing the pre-sales technical presentations and proposals and then the post-sales installation and support work... which often led to actual software development business. The more seasoned specialists got to work in many product areas and became very broad generalists.
At the same time, newer and less experienced support people had plenty of experienced people available, and as they gained experience could get real implementation assignments to supplement their pre- and post-sales support work.
But then again, in those days the money was mostly in the iron and 'people' were a much smaller part of the cost of doing business. As the 'people costs' started to catch up with the cost of iron, the support organizations migrated more to paid consulting for clients and it became more difficult for sales people to get 'part-of-the-deal' hand holding and special projects done for prospective and current clients.
Each of your points about the practice of developing Software based systems... although stated in an extremely negative way... are certainly not 'Off Topic'.
Every one of the points you make is true of far too many inexperienced developers. But IMO it stems from inexperience, not laziness.
Sofware developers too often display the attitudes and practices you list. The SEBOK is an effort to formalize the experience gained over the last 45 years in such a way that newer practicioners won't need 45 more years to find out on their own. And the SEBOK appears to me to be much more complete than the SEI's 'Capability Maturity Model' approach to organizing and formalizing this huge topic area.
A formal and comprehensive statement about what knowledge and skills are needed will allow Academic Institutions to devise cirricula that will impart the necessary information to newcomers. The Academy can do this in far less time and in a far less haphazard way than decades of plugging away to gain experience. That would go a long way toward breaking the bad (naive?)habits you list.
The IEEE does seem to indicate that an individual cannot be a professional unless licensed. Since 'licensing' carries with it the idea of being able to deny or allow practicing the (science? art?) of systems development, there have been many objections to this initiative here on/.
But I think many of these objections are mis-placed because the SEBOK addresses Software Engineering... which includes the social and environmental setting of systems and how those things evolve and are managed. The code that makes them go is a small subset of that much larger picture.
Those who write Applications or Drivers or Database Systems use bits-and-pieces of software engineering but are not Software Engineers, even if popular jargon and Microsoft does try to say that they are, and (I hope)would not be threatened were "Software Engineering" to become a 'licensed' profession.
What is more important, though, is the potential for the SEBOK to greatly reduce the far too widespread 'rookie' attitudes about and approaches to development that you decry.
If ever there was an industry that exemplifies the split between the 'geeks and nerds' world vs. the 'button down collar world' it is retail.
And focus on drivers for neato receipt printers, scanners, and friendly user interfaces (whether it be for system users or development users) is wide of the mark to begin with.
I can testify that that the retail world is the most demanding I have seen, in terms of what retail systems need to do (100s to thousands of outlets supported from and reporting into one single headquarters), in terms of the audience for the user interface to retail systems (clerks who are hostile to the entries enforced by store-level systems, owners who just want to sell and do not want to deal with ornery clerks, buyers who just want summaries and do not want to deal with unreliable data collection systems, developers who are alienated by the strange and specialized clerk monitoring devices needed to prevent employees from stealing more than 14% of the stock).
One of the most important considerations in retail is those strange and specialized clerk monitoring devices (cameras, product recogition devices, etc). State-of-the-art is always moving in that arena -- receipt printers, cash registers, drink measuring interfaces, etc are a dime a dozen. But good observation devices, robust under- and over-ring detection, resistance to deliberate 'soda and chewing gum in the keyboard' is where the big automation paybacks are to be found in the retail world.
It is hard to consider a 'closed' operating system such as the one M$ sells, with its fixed menu of supported devices and drivers, a viable alternative to an 'open' OS that allows retailers to exploit the latest in security and surveillance devices that are needed in an environment where the employees are out to 'steal you blind' if you do not have them.
Slashdot Mirror
"it is not really a matter of what the subject of the bill is these days but rather that it is prudent to not let ANYTHING pass right now [at the Federal level] because we cannot control the time bombs they are writing into them until we get firmer legislation at the State level to protect ourselves from Federal overreach, stupidity, and corruption."
Well said!
"Dvorak reputation factor" aside:
What is it about Wi-Fi that forces hot-spots to be free? If cellular outfits can 'protect' access to their towers with SIM cards, why couldn't Wi-Fi hot spots do the same?
And if hot-spots can be 'protected', why couldn't they impose charges?
And if hot-spots can be charged for, why do they HAVE to be free : muncipality-funded or not?
And given the technological potential, why couldn't such an arrangement be *far* less expensive (even if not costing zero) than today's conventional cellular services?
Hear hear !!
3) Cisco knows full well (but omits to mention) that Cingular will not allow Apple to "do VoIP" on its cells.
I have been thinking that finishing all the details on an arrangement of exactly this kind would be the holdup, a better explanation of what is going on than that Apple just went ahead and announced using the name anyway.
Although it makes sense that Cingular *might* not want this new Apple product able to *also* do VoIP ... Cingular [now AT&T] *is* a big presence provider, Cisco *is* a big presence-infrastructure equipment vendor ... ?
Are you doing more than just speculating when you flat out state that Cingular will not allow Apple to also provide VoIP? Not that my thoughts about what a killer product an iPhone running OSX and able to do *both* cellular *and* VoIP are anything more than speculation :). Should be interesting to see exactly what gets filed with the FCC.
This post is both informative and insightful. It, and the groklaw link it provides, deserve a thoughful read. It deserves a "5" - so, moderators, please bump it up.
Maybe - IANAL. But I encountered a firsthand, up-close-and-personal situation.
... with pattern analysis being done on Linux memory management routines in order to detect non-literal copying violations. But I would sure not consider it fun to come up with the money it took for IBM to defend against those arguments (which is the exact problem ... you may be sure that you are right, but you cannot be sure how a court will rule and it will cost you a lot to get the ruling ... and if you are in the US, there is no 'loser pays the winner' so you can recoup whatever you lost defending yourself, no matter how "SCOish" the challenge may be).
My company (and I) were deemed ineligibile to participate in implementing an OSI stack for an international project. The reason was that I and my team mates had worked on an earlier proprietary implemenation of an OSI stack, and that fact "posioned" us in the eyes of the contracting lawyers - we were ineligible to work on the contract despite - indeed, because of - our expertise in OSI protocols.
It was not a question of whether or not we intended to copy the code we had seen 'word for word'. It was a question of avoiding anything that made it likely that a court would be willing to formally hear an _allegation_ of copying. The contracting lawyers considered the risk of using anyone who had seen the code too great to approve using us.
===
Since IANAL, it might be that you are right, and that the contracting lawyers were worried about patent and not copyright challenges? But I fail to see how that changes the fact that seeing the code is dangerous.
I had fun, reading about the arguments SCO was making
===
My own conclusion is still that it is dangerous to even look at the code. As others beside me have said on other places on this thread, this looks like a trap that the FOSS community would do well to avoid.
Looking is dangerous.
If you later write a piece of software that in any way resembles software for which M$ owns the copyright (where 'resemblance' will be something a lawyer can get to define in a court of law), and if you have looked, you could easily lose the copyright to your own work and be found guilty of copying from M$.
From http://digital-law-online.info/lpdi1.0/treatise27. html:
If you have had access to the source of a computer program, you need to be particularly concerned that you aren't unconsciously copying the original program when you write a similar program.
If what you write is successful enough to attract M$ lawywers, being able to say "I never even looked" could prove to be very important!
This is exactly right. It is really surprising that Intel has focussed so completely, almost obessively, and for so long, on the problem of supplying the maximum number of work-cycles per unit of time (GHZ, Pipelining, Itanium's EPIC design) while seemingly paying so little attention to supply-of-work-to-do (FSB speed and architecture)
AMD has paid quite a bit of attention to the work-supply and has a much more efficiently balanced work-cycle-supply/ data-for-work design. http://www.hypertransport.org/ gives AMD a big leg-up over Intel.
If Intel fails to do something spectacular to FSB speeds, AMD is sure to continue to pull away from Intel. The more cores and threads per CPU, the greater AMD's lead over Intel will become (at least from a performance point of view), until Intel addresses this problem.
"Oh, I have an idea. Lets make OSS illegal since it hurts business".
You have given the best summary of what this author is really selling.
Leads off with IP laws (written before there was such a thing as software) and ends with:
"What we really need from government is an investigation of the long-term effects of OSS on our indigenous software industry, assistance to combat the threat to the industry's livelihood that OSS might pose"
No! What we need is for government to pay less attention to the "threat to the industry's livelihood" and more attention to removing obstacles to the rise of the public domain's interests, as is fostered by FOSS methods of product value development and delivery.
Pretty cute, too, use of "the industry" - as if processes and methods matter more than the public value of, and accessibility to, the product. And as if the 'proprietary' world's processes and methods are "the industry" while FOSS is not.
As pointed out in at least one other post, I think that - for example - IBM, Sun and HP would be surprised to discover that they are not in "the industry".
Brilliantly insightful! Wish I had mod points (hint-hint for any who do).
Interestingly enough, this is EXACTLY the way DEC interfaced with its customer base ... at least through the 70s, when I worked there ... and I believe through the beginning of the 80s as well.
... make no bones about it, sales was 'in charge'.
... which often led to actual software development business. The more seasoned specialists got to work in many product areas and became very broad generalists.
DEC was, until the late 70s, a 'matrix organization' that had several market-focussed sales groups. The market-focussed sales groups drew on and shared a central engineering and manufacturing facility and an essentially independent software support organization. But the 'independence' of the support organization had to do with the matrix-of-product-lines nature of the sales orgainization so that a common support pool could be made available to sales
At field offices, particular software specialists tended to align with particular kinds of sales groups doing the pre-sales technical presentations and proposals and then the post-sales installation and support work
At the same time, newer and less experienced support people had plenty of experienced people available, and as they gained experience could get real implementation assignments to supplement their pre- and post-sales support work.
But then again, in those days the money was mostly in the iron and 'people' were a much smaller part of the cost of doing business. As the 'people costs' started to catch up with the cost of iron, the support organizations migrated more to paid consulting for clients and it became more difficult for sales people to get 'part-of-the-deal' hand holding and special projects done for prospective and current clients.
Each of your points about the practice of developing Software based systems ... although stated in an extremely negative way ... are certainly not 'Off Topic'.
/.
... which includes the social and environmental setting of systems and how those things evolve and are managed. The code that makes them go is a small subset of that much larger picture.
Every one of the points you make is true of far too many inexperienced developers. But IMO it stems from inexperience, not laziness.
Sofware developers too often display the attitudes and practices you list. The SEBOK is an effort to formalize the experience gained over the last 45 years in such a way that newer practicioners won't need 45 more years to find out on their own. And the SEBOK appears to me to be much more complete than the SEI's 'Capability Maturity Model' approach to organizing and formalizing this huge topic area.
A formal and comprehensive statement about what knowledge and skills are needed will allow Academic Institutions to devise cirricula that will impart the necessary information to newcomers. The Academy can do this in far less time and in a far less haphazard way than decades of plugging away to gain experience. That would go a long way toward breaking the bad (naive?)habits you list.
The IEEE does seem to indicate that an individual cannot be a professional unless licensed. Since 'licensing' carries with it the idea of being able to deny or allow practicing the (science? art?) of systems development, there have been many objections to this initiative here on
But I think many of these objections are mis-placed because the SEBOK addresses Software Engineering
Those who write Applications or Drivers or Database Systems use bits-and-pieces of software engineering but are not Software Engineers, even if popular jargon and Microsoft does try to say that they are, and (I hope)would not be threatened were "Software Engineering" to become a 'licensed' profession.
What is more important, though, is the potential for the SEBOK to greatly reduce the far too widespread 'rookie' attitudes about and approaches to development that you decry.
If ever there was an industry that exemplifies the split between the 'geeks and nerds' world vs. the 'button down collar world' it is retail.
And focus on drivers for neato receipt printers, scanners, and friendly user interfaces (whether it be for system users or development users) is wide of the mark to begin with.
I can testify that that the retail world is the most demanding I have seen, in terms of what retail systems need to do (100s to thousands of outlets supported from and reporting into one single headquarters), in terms of the audience for the user interface to retail systems (clerks who are hostile to the entries enforced by store-level systems, owners who just want to sell and do not want to deal with ornery clerks, buyers who just want summaries and do not want to deal with unreliable data collection systems, developers who are alienated by the strange and specialized clerk monitoring devices needed to prevent employees from stealing more than 14% of the stock).
One of the most important considerations in retail is those strange and specialized clerk monitoring devices (cameras, product recogition devices, etc). State-of-the-art is always moving in that arena -- receipt printers, cash registers, drink measuring interfaces, etc are a dime a dozen. But good observation devices, robust under- and over-ring detection, resistance to deliberate 'soda and chewing gum in the keyboard' is where the big automation paybacks are to be found in the retail world.
It is hard to consider a 'closed' operating system such as the one M$ sells, with its fixed menu of supported devices and drivers, a viable alternative to an 'open' OS that allows retailers to exploit the latest in security and surveillance devices that are needed in an environment where the employees are out to 'steal you blind' if you do not have them.