A question for an artist familiar with the RIAA
on
Dealing with the RIAA?
·
· Score: 2, Insightful
We constantly hear of artists getting screwed. Yet artists willfully sign over their rights to the record labels, RIAA, or whoever. (You might take exception to the term "willfully", but I haven't yet heard of anyone having a gun held to their head.)
Way-back-when, volume distribution channels made sense to obtain economies of scale that no one individual could obtain.
Today that economy of scale argument doesn't apply (at least is significantly), which is why mom-and-pop web stores can reach an audience as large as the big guys. At least for Internet-capable consumers, which seems to be the core consumer group of concen.
The technology exists today for artists to form their own version of the RIAA. It wouldn't even require a central organization/site, but could be distributed. (Simple model: songs contain the URL of where to pay.)
The problem isn't technical. It would only take a handful (or 1) of successful artists to bankroll the development (I'm sure there are plenty of open source developers who would jump at the chance).
So why haven't the artists created such an entity?
Obviously this won't do anything for back catalogs. But the problem will remain unless someone takes the first step.
Hmmmm.... I'm willing to believe I have misread, or misunderstand some of the TCPA specs, but I'm wondering if anyone else in this discussion has even read any of the specs.
TCPA is quite specific in its intent: to provided a trusted path that can not (or at least not easily) be subverted. "Trusted path" means that I know who and where it came from; what I do with that information is up to me. Note that anyone who has ever tried to solve this problem ends up in about the same place as the TCPA. If you have a way to solve it differently, then there are a lot of people who would like to hire you.
I agree that making external interfaces secure is important, but it is far from sufficient. Stopping at the interface is the "hard and crunchy on the outside, soft and chewy on the inside", and a very sophmoric, approach to security. If that's your solution, wonderful--but to suggest internal checkes are "not a good way to run a reliable system" is ludicrous. Sorry, I digress...
We're talking about increasing reliability and failure detection, not viruses (although viruses can obviously lead to reduced reliability).
Using your analogy, the appropriate solution to detecting a failure would be ensure that the system never breaks, and if there is a failure, we simply let the entire system crater, and maybe kill someone? I prefer a system that attemtps to detect--and recover from--a failure before it misbehaves too badly.
It's not the technology that's "bad", it's how the technology is applied.
Anyone who has tried to construct a "secure" system has run into the same problem TCPA/DRM is addressing: How can you assure that the code you are executing is trusted? Specifically, that it hasn't been corrupted, either intentionally or unintentionally.
Every life- or safety-critical system goes through (or should) a process of verification at startup, and runs self-checks at regular intervals. The same mechanism that is used for TCP/DRM could provide a simpler and higher level of assurance that something bad hasn't happened to your code (or data).
(In a previous life building safety-critical embedded systems, I went to extreme lengths during startup, and during idle periods, to (re)verify checksums on code and data structures. That was to detect corruption and initiate recovery if something bad happened. It wasn't perfect, but it was better than nothing. And it worked. What those systems might have done had those checks not detected those failures makes me shudder.)
Think about using that same TCPA/DRM technology to ensure the integrity of the system's code and data. Think about that same TCPA/DRM technology to ensure the integrity (and maybe privacy) of data consumed or generated by a system, especially medical systems. Those applications of the TCPA/DRM technology could be extremely benficial.
As several have already mentioned--and at the risk of being redundant--here's some hard numbers on using cheap HD's vs. DVD-x.
Cost for HD solution: $5.11/Gb. Do a little trimming and you can get that to $4/Gb. Note that this is for a full-blown file server: dual procs; 1Gb DDR ECC; 1Gb ether; RAID 5 (details below).
Cost DVD-whatever solution: Using a very optimistic assumtion of $60/drive (with cheap controllers for the gaggle of drives you'll need, each of which gives you 4.7Gb online. That's almost $12.76/Gb.
Configuration/cost of HD file server (this is a bit dated; I'm sure you can do better)...
Mobo: Tyan Tiger 2460MP $212.00 x 1 = $212.00 Memory: Corsair 512Mb DDR2100 ECC reg $227.00 x 2 = $454.00 CPU: AMD Athlon MP 1800+ $228.00 x 1 = $228.00 Video: Generic: $125.00 x 1 = $125.00 Ethernet: 3Com 10/100/1000 3C996B-T $150.00 x 1 = $150.00 Sys disk: WD 1200JB $215.00 x 2 $430.00 CD/DVD: Generic $40.00 x 1 = $40.00 Floppy: Generic $10.00 x 1 = $10.00 Case: Enlight 8950 $160.00 x 1 = $160.00 Case: Rackmount kit $109.00 x 1 = $109.00 PS: ENERMAX550W $155.00 x 1 = $155.00 Controller: Escalade 7850 $505.00 x 1 = $505.00 Drive bays: Hot-swap Cages $245.00 x 3 = 735.00 Disks: Maxtor 160Gb $225.00 x 8 = $1,800.00 ----- Total: $5,113.00
To paraphrase someone else, saying you're not suppose to write OO in assembly language is like saying you can't write readable prose using a typewriter.
OO programming is a state of mind, not a language. OO code is a function of the programmer, not the language. I've seen some of the worst [non-OO code] written in in C++ and Java; I've seen some of the most beautiful [OO-oriented code] written in assembly language.
Other posts have indicated why most companies need to keep the CC#. However, in a properly architected system, sensitive data such as CC#'s should be compartmentalized and isolated. A couple simplified examples:
There's *no* reason why CC# verification logic needs access to the database containing CC#'s. E.g., put the CC# database on a separate machine (with internal firewall, proxy, etc.), with external access limited to "verify this CC#" or "verify this CC# for this amount".
In the unfortunate event that the application isn't well architected, a shadow CC# database can be constructed using one way hashes of the CC#'s; the "real" database is kept elsewhere, and is only directly accessible to systems that require the real CC#. This achieves a reasonable level of protection without (usually) having to gut the application.
In short, the effectiveness of the security for these types of systems is heavily dependent on the application's architecture. (You can't retrofit systemic security.)
If you have a CPU utilization indicator, I think you'll find that the noise correlates with the CPU utilization or, more precisely, with the power drawn from your power supply. (Can also be a result of thermal fan control, but if it's high pitched or whiney, it's probably an artifact of the [switching] power supply.) To get rid of the noise: 1) you need a bigger power supply; or 2) you need a better power supply.
it's always been about the compilers
on
Inside the Itanium
·
· Score: 4, Interesting
Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)
Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.
That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.
On the other hand "staying at home" is what most of humanity has done for most of its existence.
I think we might (again) start to put as much weight on the physical aspects of community. And would that be such a bad thing? (Given typical urban commutes, how much time do you spend--and how well do you know--the people in the community around you?)
Modern communications has simply shown us that we aren't limited by physical boundaries. But that has only highlighted the differences--not eliminated them.
If you fall outside the norm for an organization (the "normal majority"), you're going to be subject to pressure to conform to the organization's--specifically the people who make up the organization's--view of normalcy. That "normalcy" takes many forms, some good and some bad, but it's universal, and likely to remain so.
The choice is simple: fit yourself to the organization, or find an organization that fits you. It sounds like you're motivated and intelligent, but maybe don't have the self confidence to take that road. You're young and you have plenty of time to make mistakes and correct.
Just like debugging any problem... If you're stalled, change something and see what happens.
One minor piece of career advice: Focus on your own problems, not others. (You'll get plenty of that--and wish you didn't--when you become a manager.:) Thinking you can solve your career problems by "solving" others personal, cultural, age or whatever hang-ups almost never works--and usually backfires.
Just like dealing with legacy systems... there are some things you can't fix--recognize it and move on to what you can fix.
(p.s. My road meant working in select groups within larger organizations, or working in startups--environments where function mattered more than form. I started doing that from the time I was your age. It's many years later and I don't regret it. The journey has not always been happy, but always challenging, and never boring.)
Unfortunately, this won't work for all WA customers; see:
http://slashdot.org/comments.pl?sid=24373&thresh ol d=0&commentsort=0&mode=thread&pid=2642220#2642407
Found the same at my location (in Seattle). I noticed that (according to my fw logs) probes stopped at about 4:15AM PST.
However, I've discovered a few intersting items while waiting (annoyingly) for word from AT&T...
The original gateway still answers, but doesn't seem to go anywhere. Found another gateway at 10.82.2.1 and pings answering at 10.82.2.xxx and 10.82.3.xxx. Unfortunately, I haven't found a way out of the maze yet.
I can still get to my @home email using the same old pop host/account (getting to it through my trusty old netcom/earthlink account).
I also found that my @home accont/password works at AT&T broadband (attbi.com) for signing in and to pick up email at "athomeusername@attbi.com".
I tried configuring my system as attbi suggests (dhcp), but no luck. In short, it looks like AT&T has completed populating their attbi replacement service for everything except actual the actual connectivity. *sigh*
The economics of telework are fairly well understood, and an ROI can be easily calculated based on factors including increased productivity; increased retention; reduced sick time; etc.
Most notably, one of them most significant barriers to telework is middle management, who must manage to deliverables, not face time. Interestingly, telework training aimed at managers is largely remedial in nature; telework exacerbates management problems.
One of the other issues faced by telework programs is some basic misconceptions about what works, and what doesn't. For example, telework is *not* a substitute for child or elder care.
For basic telework Q&A that answers many of these questions, see:
It depends on what you--and the customer--defines as "quality". The simple answer: "enough [but not too much]". A solution needs only the quality sufficient to perform its job; any less makes it unreliable; any more makes it less cost effective.
Can you have too much quality? Yes. Web applications typically don't need, nor can they afford, the level of quality demanded by life- or safey-critical applications. (And speaking from experience, most programmers won't, or can't, tolerate the demands of such critical development. I approached work every day with the perspective of "if this harms someone, can I state honestly and credibly to a court of law that I did everything in my power to prevent it". Now do that for a couple years; it gets very old very fast.)
Before you start in on management about "quality", have a good definition of it is you're after, what is enough, and why you think what you're providing custmers isn't sufficient.
"...it sold a staggering 100,000 kits, far beyond the 12,000 units the company had projected. To Lego's surprise, some 70 percent of Mindstorms customers in the heady early months following its launch were old enough to vote..."
What would you do if your a product found and unexpected successful market? I think Lego knows they've stumbled into an opportunity, but they're unsure of how to execute.
Instead of focusing on "Should Lego sue?", focus on "How should Lego leverage this opportunity?" The simple answer IMHO: co-opt the individual efforts; make an "adult" product version or addons. Make Mindstorm *real* plug-and-play software/hardware.
Most interesting perspective; and following that line of reasoning...
Maybe SO's efforts would be better directed to producing a plug-in (low/zero cost) replacement for older version(s) of MSO.
Make a virtue out of being "behind". Cater to the same resistance/inertia that hampers adoption of SO. And assuage the irritation caused by being forced to pay for upgrades rationalized on new features that few need, want or use.
Personally, the only reason I've upgraded MSO is to keep current with file formats sent to me by other people who've upgraded their versions of MSO. All because MSO's filters for their own (older) file formats--read or write--have never been reliable (which I suspect is intentional and simply adds insult to injury).
Agree that synch has become dogma for too many of today's engineers. However, it looks like their design technology/methodology--which, from what I read, appears to be a significant element of their IP--may be a first step back towards the use and acceptance of asynch/clockless on a much larger scale than seen for the last decade (or two? or three?). Unfortunately the potential significance of that (which, as you point out, is much more interesting) appears to be getting drowned out the GHz clockers.
As others have noted, end-to-end encryption is the best bet. However...
If there are control functions used by 802.11 nodes that depend on WEP for their integrity/privacy, the network could still be susceptible (even if your application data is secured end-to-end).
Would someone familiar with 802.11x internals shed some light on this? Thanks.
A cynical view of why VeriSign is doing this now:
A significant portion of their revenue appears to come from domain registration (if I'm interpolating data from their 3/31 10Q correctly). If that revenue flattens, their stock is going to take a bath, just like the rest of the techs have (so far VeriSign appears to have weathered better than most techs). And since their last quarter closed at the end of June, they don't have much time for damage control. To quote:
Our web presence services will account for a significant portion of our revenue in at least the near term. Our future success will depend largely on:
. continued new domain name registrations;
. re-registration rates of our customers;
...
. our ability to provide a superior customer service infrastructure for our web presence services.
From VeriSign 10Q (period ending 3/31, filed 5/11):
http://www.sec.gov/Archives/edgar/data/1014473/000 101287001500729/d10q.txt
Most standards bodies have dealt with the issue of IP in standards by requiring vendors to relinquish or license any IP incorporated into a standard.
A good (old) example: HP's agreement with the IEEE to license HPIB/IEEE488 to anyone for $1 (if my memory serves me correct). A bad (old) example: Any standard that mandated the use of RSA, without any formal agreement as to what constituted "reasonable" licensing with RSA. (Many here can relate to that one:)
Does anyone know what ECMA's IP-standards policies are? I've looked around their site, but didn't find anything definitive.
While copyright law may be clear (as you state), the provisions of the GPL in cases such as this are not. The FSF appears to recognize this is a fuzzy area; from the FSF faq http://www.fsf.org/copyleft/gpl-faq.html:
"...This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)."
And, as this case didn't go to court, it;s still a fuzzy area.
The story isn't about "a kid playing lawyer on the Internet".
The story is the author's journey--obviously a struggle for him--trying to come to terms with how and why, and the implications for the world as he knows it.
The author did an excellent job; you can't help but empathize, even while you want to scream at him "don't you get it!".
How would you tell that story?
Re:Here's the appeal of the Net in a nutshell
on
IANAL
·
· Score: 1
"On the Internet, nobody knows you're a dog."
-- 1993
"On the Internet, nobody cares you're a dog--if you can perform."
-- 2000
Most interesting is the use of "Faking it" in the title. Most kids probably wouldn't think that--the kid came clean in the end, with no harm to his rep.
An example of even informed adults being too inhibited by preconceived notions to lay claim to the Internet Age? The author even seems to recognize that at some level, and his angst comes through loud and clear.
It's ok for kids to think up cool new uses for technology--but heaven forbid they upset our social or professional norms? "Rock 'n Roll" is right! Take a close look in the mirror before you start bashing.
Slashdot Mirror
We constantly hear of artists getting screwed. Yet artists willfully sign over their rights to the record labels, RIAA, or whoever. (You might take exception to the term "willfully", but I haven't yet heard of anyone having a gun held to their head.)
Way-back-when, volume distribution channels made sense to obtain economies of scale that no one individual could obtain.
Today that economy of scale argument doesn't apply (at least is significantly), which is why mom-and-pop web stores can reach an audience as large as the big guys. At least for Internet-capable consumers, which seems to be the core consumer group of concen.
The technology exists today for artists to form their own version of the RIAA. It wouldn't even require a central organization/site, but could be distributed. (Simple model: songs contain the URL of where to pay.)
The problem isn't technical. It would only take a handful (or 1) of successful artists to bankroll the development (I'm sure there are plenty of open source developers who would jump at the chance).
So why haven't the artists created such an entity?
Obviously this won't do anything for back catalogs. But the problem will remain unless someone takes the first step.
Hmmmm.... I'm willing to believe I have misread, or misunderstand some of the TCPA specs, but I'm wondering if anyone else in this discussion has even read any of the specs.
TCPA is quite specific in its intent: to provided a trusted path that can not (or at least not easily) be subverted. "Trusted path" means that I know who and where it came from; what I do with that information is up to me. Note that anyone who has ever tried to solve this problem ends up in about the same place as the TCPA. If you have a way to solve it differently, then there are a lot of people who would like to hire you.
I agree that making external interfaces secure is important, but it is far from sufficient. Stopping at the interface is the "hard and crunchy on the outside, soft and chewy on the inside", and a very sophmoric, approach to security. If that's your solution, wonderful--but to suggest internal checkes are "not a good way to run a reliable system" is ludicrous. Sorry, I digress...
We're talking about increasing reliability and failure detection, not viruses (although viruses can obviously lead to reduced reliability).
Using your analogy, the appropriate solution to detecting a failure would be ensure that the system never breaks, and if there is a failure, we simply let the entire system crater, and maybe kill someone? I prefer a system that attemtps to detect--and recover from--a failure before it misbehaves too badly.
It's not the technology that's "bad", it's how the technology is applied.
Anyone who has tried to construct a "secure" system has run into the same problem TCPA/DRM is addressing: How can you assure that the code you are executing is trusted? Specifically, that it hasn't been corrupted, either intentionally or unintentionally.
Every life- or safety-critical system goes through (or should) a process of verification at startup, and runs self-checks at regular intervals. The same mechanism that is used for TCP/DRM could provide a simpler and higher level of assurance that something bad hasn't happened to your code (or data).
(In a previous life building safety-critical embedded systems, I went to extreme lengths during startup, and during idle periods, to (re)verify checksums on code and data structures. That was to detect corruption and initiate recovery if something bad happened. It wasn't perfect, but it was better than nothing. And it worked. What those systems might have done had those checks not detected those failures makes me shudder.)
Think about using that same TCPA/DRM technology to ensure the integrity of the system's code and data. Think about that same TCPA/DRM technology to ensure the integrity (and maybe privacy) of data consumed or generated by a system, especially medical systems. Those applications of the TCPA/DRM technology could be extremely benficial.
As several have already mentioned--and at the risk of being redundant--here's some hard numbers on using cheap HD's vs. DVD-x.
Cost for HD solution: $5.11/Gb. Do a little trimming and you can get that to $4/Gb. Note that this is for a full-blown file server: dual procs; 1Gb DDR ECC; 1Gb ether; RAID 5 (details below).
Cost DVD-whatever solution: Using a very optimistic assumtion of $60/drive (with cheap controllers for the gaggle of drives you'll need, each of which gives you 4.7Gb online. That's almost $12.76/Gb.
Configuration/cost of HD file server (this is a bit dated; I'm sure you can do better)...
Mobo: Tyan Tiger 2460MP $212.00 x 1 = $212.00
Memory: Corsair 512Mb DDR2100 ECC reg $227.00 x 2 = $454.00
CPU: AMD Athlon MP 1800+ $228.00 x 1 = $228.00
Video: Generic: $125.00 x 1 = $125.00
Ethernet: 3Com 10/100/1000 3C996B-T $150.00 x 1 = $150.00
Sys disk: WD 1200JB $215.00 x 2 $430.00
CD/DVD: Generic $40.00 x 1 = $40.00
Floppy: Generic $10.00 x 1 = $10.00
Case: Enlight 8950 $160.00 x 1 = $160.00
Case: Rackmount kit $109.00 x 1 = $109.00
PS: ENERMAX550W $155.00 x 1 = $155.00
Controller: Escalade 7850 $505.00 x 1 = $505.00
Drive bays: Hot-swap Cages $245.00 x 3 = 735.00
Disks: Maxtor 160Gb $225.00 x 8 = $1,800.00
-----
Total: $5,113.00
To paraphrase someone else, saying you're not suppose to write OO in assembly language is like saying you can't write readable prose using a typewriter.
OO programming is a state of mind, not a language. OO code is a function of the programmer, not the language. I've seen some of the worst [non-OO code] written in in C++ and Java; I've seen some of the most beautiful [OO-oriented code] written in assembly language.
Get a clue.
Other posts have indicated why most companies need to keep the CC#. However, in a properly architected system, sensitive data such as CC#'s should be compartmentalized and isolated. A couple simplified examples:
There's *no* reason why CC# verification logic needs access to the database containing CC#'s. E.g., put the CC# database on a separate machine (with internal firewall, proxy, etc.), with external access limited to "verify this CC#" or "verify this CC# for this amount".
In the unfortunate event that the application isn't well architected, a shadow CC# database can be constructed using one way hashes of the CC#'s; the "real" database is kept elsewhere, and is only directly accessible to systems that require the real CC#. This achieves a reasonable level of protection without (usually) having to gut the application.
In short, the effectiveness of the security for these types of systems is heavily dependent on the application's architecture. (You can't retrofit systemic security.)
If you have a CPU utilization indicator, I think you'll find that the noise correlates with the CPU utilization or, more precisely, with the power drawn from your power supply. (Can also be a result of thermal fan control, but if it's high pitched or whiney, it's probably an artifact of the [switching] power supply.) To get rid of the noise:
1) you need a bigger power supply; or
2) you need a better power supply.
Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)
Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.
That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.
On the other hand "staying at home" is what most of humanity has done for most of its existence.
I think we might (again) start to put as much weight on the physical aspects of community. And would that be such a bad thing? (Given typical urban commutes, how much time do you spend--and how well do you know--the people in the community around you?)
Modern communications has simply shown us that we aren't limited by physical boundaries. But that has only highlighted the differences--not eliminated them.
If you fall outside the norm for an organization (the "normal majority"), you're going to be subject to pressure to conform to the organization's--specifically the people who make up the organization's--view of normalcy. That "normalcy" takes many forms, some good and some bad, but it's universal, and likely to remain so.
:) Thinking you can solve your career problems by "solving" others personal, cultural, age or whatever hang-ups almost never works--and usually backfires.
The choice is simple: fit yourself to the organization, or find an organization that fits you. It sounds like you're motivated and intelligent, but maybe don't have the self confidence to take that road. You're young and you have plenty of time to make mistakes and correct.
Just like debugging any problem... If you're stalled, change something and see what happens.
One minor piece of career advice: Focus on your own problems, not others. (You'll get plenty of that--and wish you didn't--when you become a manager.
Just like dealing with legacy systems... there are some things you can't fix--recognize it and move on to what you can fix.
(p.s. My road meant working in select groups within larger organizations, or working in startups--environments where function mattered more than form. I started doing that from the time I was your age. It's many years later and I don't regret it. The journey has not always been happy, but always challenging, and never boring.)
Unfortunately, this won't work for all WA customers; see:h ol d=0&commentsort=0&mode=thread&pid=2642220#2642407
http://slashdot.org/comments.pl?sid=24373&thres
Found the same at my location (in Seattle). I noticed that (according to my fw logs) probes stopped at about 4:15AM PST.
However, I've discovered a few intersting items while waiting (annoyingly) for word from AT&T...
The original gateway still answers, but doesn't seem to go anywhere. Found another gateway at 10.82.2.1 and pings answering at 10.82.2.xxx and 10.82.3.xxx. Unfortunately, I haven't found a way out of the maze yet.
I can still get to my @home email using the same old pop host/account (getting to it through my trusty old netcom/earthlink account).
I also found that my @home accont/password works at AT&T broadband (attbi.com) for signing in and to pick up email at "athomeusername@attbi.com".
I tried configuring my system as attbi suggests (dhcp), but no luck. In short, it looks like AT&T has completed populating their attbi replacement service for everything except actual the actual connectivity. *sigh*
The economics of telework are fairly well understood, and an ROI can be easily calculated based on factors including increased productivity; increased retention; reduced sick time; etc.
Most notably, one of them most significant barriers to telework is middle management, who must manage to deliverables, not face time. Interestingly, telework training aimed at managers is largely remedial in nature; telework exacerbates management problems.
One of the other issues faced by telework programs is some basic misconceptions about what works, and what doesn't. For example, telework is *not* a substitute for child or elder care.
For basic telework Q&A that answers many of these questions, see:
http://www.10icorp.com/services/questions.htm
It depends on what you--and the customer--defines as "quality". The simple answer: "enough [but not too much]". A solution needs only the quality sufficient to perform its job; any less makes it unreliable; any more makes it less cost effective.
Can you have too much quality? Yes. Web applications typically don't need, nor can they afford, the level of quality demanded by life- or safey-critical applications. (And speaking from experience, most programmers won't, or can't, tolerate the demands of such critical development. I approached work every day with the perspective of "if this harms someone, can I state honestly and credibly to a court of law that I did everything in my power to prevent it". Now do that for a couple years; it gets very old very fast.)
Before you start in on management about "quality", have a good definition of it is you're after, what is enough, and why you think what you're providing custmers isn't sufficient.
"...it sold a staggering 100,000 kits, far beyond the 12,000 units the company had projected. To Lego's surprise, some 70 percent of Mindstorms customers in the heady early months following its launch were old enough to vote..."
What would you do if your a product found and unexpected successful market? I think Lego knows they've stumbled into an opportunity, but they're unsure of how to execute.
Instead of focusing on "Should Lego sue?", focus on "How should Lego leverage this opportunity?" The simple answer IMHO: co-opt the individual efforts; make an "adult" product version or addons. Make Mindstorm *real* plug-and-play software/hardware.
Most interesting perspective; and following that line of reasoning...
Maybe SO's efforts would be better directed to producing a plug-in (low/zero cost) replacement for older version(s) of MSO.
Make a virtue out of being "behind". Cater to the same resistance/inertia that hampers adoption of SO. And assuage the irritation caused by being forced to pay for upgrades rationalized on new features that few need, want or use.
Personally, the only reason I've upgraded MSO is to keep current with file formats sent to me by other people who've upgraded their versions of MSO. All because MSO's filters for their own (older) file formats--read or write--have never been reliable (which I suspect is intentional and simply adds insult to injury).
RMS can rightly claim to be the parent of the FSF/GNU movement.
However, the Linux/Linus prodigy has taken the spotlight. (Do your own survey: Who's heard of GNU/RMS; who's heard of Linux/Linus?)
Your children have outgrown you RMS; let them go. Be proud, not envious, of their accomplishments.
Agree that synch has become dogma for too many of today's engineers. However, it looks like their design technology/methodology--which, from what I read, appears to be a significant element of their IP--may be a first step back towards the use and acceptance of asynch/clockless on a much larger scale than seen for the last decade (or two? or three?). Unfortunately the potential significance of that (which, as you point out, is much more interesting) appears to be getting drowned out the GHz clockers.
As others have noted, end-to-end encryption is the best bet. However...
If there are control functions used by 802.11 nodes that depend on WEP for their integrity/privacy, the network could still be susceptible (even if your application data is secured end-to-end).
Would someone familiar with 802.11x internals shed some light on this? Thanks.
Our web presence services will account for a significant portion of our revenue in at least the near term. Our future success will depend largely on:
. continued new domain name registrations;
. re-registration rates of our customers;
...
. our ability to provide a superior customer service infrastructure for our web presence services.
From VeriSign 10Q (period ending 3/31, filed 5/11): http://www.sec.gov/Archives/edgar/data/1014473/000 101287001500729/d10q.txt
Most standards bodies have dealt with the issue of IP in standards by requiring vendors to relinquish or license any IP incorporated into a standard.
:)
A good (old) example: HP's agreement with the IEEE to license HPIB/IEEE488 to anyone for $1 (if my memory serves me correct). A bad (old) example: Any standard that mandated the use of RSA, without any formal agreement as to what constituted "reasonable" licensing with RSA. (Many here can relate to that one
Does anyone know what ECMA's IP-standards policies are? I've looked around their site, but didn't find anything definitive.
While copyright law may be clear (as you state), the provisions of the GPL in cases such as this are not. The FSF appears to recognize this is a fuzzy area; from the FSF faq http://www.fsf.org/copyleft/gpl-faq.html: "...This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." And, as this case didn't go to court, it;s still a fuzzy area.
The story isn't about "a kid playing lawyer on the Internet".
The story is the author's journey--obviously a struggle for him--trying to come to terms with how and why, and the implications for the world as he knows it.
The author did an excellent job; you can't help but empathize, even while you want to scream at him "don't you get it!".
How would you tell that story?
"On the Internet, nobody knows you're a dog."
-- 1993
"On the Internet, nobody cares you're a dog--if you can perform."
-- 2000
Most interesting is the use of "Faking it" in the title. Most kids probably wouldn't think that--the kid came clean in the end, with no harm to his rep.
An example of even informed adults being too inhibited by preconceived notions to lay claim to the Internet Age? The author even seems to recognize that at some level, and his angst comes through loud and clear.
It's ok for kids to think up cool new uses for technology--but heaven forbid they upset our social or professional norms? "Rock 'n Roll" is right! Take a close look in the mirror before you start bashing.