When I research something for my company, and find it has adverse effects, I bury the reports. More specifically, I throw my findings into the project documentation folder, and move on to something else that will work without the problems. Hopefully, nobody will need to look at those reports again. Granted, I'm evaluating software packages, not consumer products, but I'm assuming the concept's the same.
Why waste time and money making a formal report, announcing it to the world, and generally just scaring people when 99% of the time the problems are eventually solved, anyway?
Having a natural resistance to drugs' effects is a good thing, especially if other effects come through fully. Consider the possibility of having strong narcotic-based post-surgery painkillers with fewer or even no adverse effects. This could be a small step in that direction. There's lots of chemicals out there that have great uses, except for the minor detail that they're toxic.
Being outlawed doesn't make a chemical bad. It just makes the chemical illegal.
Yes it is. The broken window fallacy is the mistaken belief that spent money comes out of thin air. John Stossel has a great video on it. He's talking about government spending, but you can replace "government" with "consumer" and get the same idea.
The generally-correct idea is that a lost sale for one industry is a gained sale for another, so pointing out lost sale figures is useless. As stated in the topic, it's a zero-sum game.
If the project were written in assembly, then yes. In my opinion, projects should try to avoid adding extra unnecessary languages. Sure, if you need 500 different parsers for an otherwise-C project, lex is a good way to go. To just read those few data files you need, you should be able to write your own parse, and not significantly increase the maintenance requirements of your project.
Such places already exist, marketing mainly toward the developing countries. They aren't run by the big research-oriented firms. Instead, those little places rely on any information they can gain, such as reverse-engineering and public releases.
Among the research giants, this isn't anything more than PR. Among the villages of rural Africa, this (hopefully) reduces the cost of a low-quality malaria drug from about $4 to $1. That's a big deal.
So yes, that they have there setup in such a way that the code cannot be modified
That's the part we don't know. Their build environment might be some guy flipping through a book of op codes. In that case, the build script (as required by the GPL) might be that book's dog-eared corners. Is it fair or right to claim that guy should be available to compile anyone's program, just because he compiled a GPL program once? Of course not. That one guy can be replaced with any other similarly-performing guy, or even an automatic compiler. The marked pages' numbers might be useless, but they do provide some insight into what's necessary to compile the program.
Arguing for the release of the build environment is an identical situation. The build environment can be replaced by any other build system, GPL or otherwise.
As for violating the spirit of the GPL, let's consider the full implications of requiring the build environment's release. Rather than granting developers the freedom to work in an environment they like, it restricts developers to working with only GPL tools. If I (hypothetically) enjoy working in Visual Studio, I'd be unable to write any GPL programs, so I simply wouldn't. Free software would die very quickly.
Fortunately, the build environment is not included. Everything I write (and thus own the copyright to) can be released as GPL, with no additional strings attached.
In fact, it seems this company is trying to be good. They've apparently released the build scripts they use, rather than trying to hide their existence. They've responded to GPL questions. They're releasing source right up front, rather than wait for someone to notice, like so many other companies. They're also following their legally-binding license agreements, which prevent them from giving away the build environment. If you cannot legally obtain the required build environment, replace it with something else, up to and including some guy with a book.
Vellmont wanted an example, and here it is. It's not clear whether the "firmware utilities" would need to be released, or even what extent of the "build environment" is covered. Do they need to release the circuit diagrams for their ROM programmers? There are so many ambiguities, yet these companies are regarded as "some bastard making money out of stealing somebody else's work".
It's healthy to fight for the GPL, but don't go looking for a fight in response to a question.
Try again. I'm not going to find the source, because I'm a lazy bum, but it's on the FSF site. The most they'd (usually) have to do is cease distribution of the GPL software.
All those formats are readily available, and I'm not asking for detailed implementations. For example, CSV is just a state machine with a buffer. SGML's simplest parser is a primarily a stack. ID3v1 is a fixed-length read from a fixed location.
It's not about being able to write a given parser from memory. It's about recognizing language types and the parser patterns that can handle them efficiently.
The names should be protected at this stage. It's not clear whether they're doing something wrong or not (see the Visual Studio example in a nearby comment), so calling them out and setting loose the/. horde is a bit extreme at this point.
Here's my personal checklist. If, off the top of your head, you can come up with a good plan to approach these formats and situations (using no libraries), I'd love to know where you went to school:
CSV, including escaping
SGML
HTML (including common errors)
WAV
PNG
JSON
Brainfuck, with an extra instruction to interpret the output as brainfuck
A serialized tree structure where each line is a node, and depth is represented by indentation
ID3v1 (possibly including the enhanced tag)
ID3v2
All of the above involving a 1 terabyte file
All of the above streamed over a network, and interrupted at any point. Your parsers must salvage whatever data they can.
Given that it's 1:45 AM, I reserve the right to amend this list when I'm thinking clearly.
You become a butterfly farmer to raise any kind of butterfly you want, rather than just what you already have. Chaos theory is great and all, but embedding infinite complexity into your programs is a good way to fail that ever-upcoming performance review.
This is exactly what I'm referring to. If the grammar isn't readily obvious, can you still write a parser for a language, and do so in a manner that's readable to others?
Last I checked, flex made some pretty large files just to parse out a simple language. How will your coworkers feel about having to maintain a few thousand lines of unnecessary parser code? (Note that this is based on looking at this example.)
What about a network protocol, where the whole structure may not be available at once, and may in fact be larger than your computer's memory can handle?
Sure, you may have learned how lex works, but can you actually apply that to writing a good parser yourself?
Lex, and all compiler theory, is great for compilers. If you have your entire structure in a nice well-defined form, and you're only dealing with a tiny amount of data at a time, compiling practices work fine. Once circumstances get weirder, you need to be able to adapt. Lex doesn't like adapting, and its processes are so abstract as to be ridiculously excessive for most jobs.
Spolsky's got some decent ideas, and knows a lot about what he talks about, but his idea of "good" and "bad" makes me cringe. He's one of those folks who's built up a following on what little they had to talk about, then ceased to think further. Now (and for several years), he writes about half-baked lists of do's-and-don'ts that never even come close to covering exceptions.
My supervisor is (rightfully) wary of regexes, due to their reputation for unreadability. My favorite solution (in Java): Make a bunch of string constants to match various elements, then assemble those strings together into more strings, which are finally assembled into a single real regex. Sure, it takes about 15 lines for a moderately-complicated regex, but readability is superior to using 15 lines of indexof and substr.
And now, to just bring up a topic that I have a personal interest in:
Nobody knows how to write parsers anymore. I've never seen a recent university CS curriculum that covers parsing with respect to different parser constructs for different languages. Sure, the students learn to load up the chosen XML parsing library and pull in XML, and they learn to take text from stdin, but there's seldom any emphasis on what to do with more screwy formats. Maybe, just maybe, they might get exposed to different languages through a compilers class, but generally not how to process different languages outside of lex/yacc. This bothers me greatly.
Slashdot Mirror
When I research something for my company, and find it has adverse effects, I bury the reports. More specifically, I throw my findings into the project documentation folder, and move on to something else that will work without the problems. Hopefully, nobody will need to look at those reports again. Granted, I'm evaluating software packages, not consumer products, but I'm assuming the concept's the same.
Why waste time and money making a formal report, announcing it to the world, and generally just scaring people when 99% of the time the problems are eventually solved, anyway?
That's amazing. I've got the same combination on my luggage.
"Do no evil" is a great motto, except we're living in a world where evil is expected and normal. Anything abnormal is suspicious.
That should have been "drugs' adverse effects'... Sorry.
Having a natural resistance to drugs' effects is a good thing, especially if other effects come through fully. Consider the possibility of having strong narcotic-based post-surgery painkillers with fewer or even no adverse effects. This could be a small step in that direction. There's lots of chemicals out there that have great uses, except for the minor detail that they're toxic.
Being outlawed doesn't make a chemical bad. It just makes the chemical illegal.
Pesky indeed. Your number's off by a factor of 10. The original math is correct.
Yes it is. The broken window fallacy is the mistaken belief that spent money comes out of thin air. John Stossel has a great video on it. He's talking about government spending, but you can replace "government" with "consumer" and get the same idea.
The generally-correct idea is that a lost sale for one industry is a gained sale for another, so pointing out lost sale figures is useless. As stated in the topic, it's a zero-sum game.
Not effective? How is that different from any other aspect of the American airline security policy?
From a visibility standpoint, any activity that ends with Linux showing favorably is a win to some degree.
My fiancée had to take some of those Indian low-quality pills while we were in Africa. Anything that might make 'em a bit better is a good thing.
If the project were written in assembly, then yes. In my opinion, projects should try to avoid adding extra unnecessary languages. Sure, if you need 500 different parsers for an otherwise-C project, lex is a good way to go. To just read those few data files you need, you should be able to write your own parse, and not significantly increase the maintenance requirements of your project.
Such places already exist, marketing mainly toward the developing countries. They aren't run by the big research-oriented firms. Instead, those little places rely on any information they can gain, such as reverse-engineering and public releases.
Among the research giants, this isn't anything more than PR. Among the villages of rural Africa, this (hopefully) reduces the cost of a low-quality malaria drug from about $4 to $1. That's a big deal.
Outside of the pharmaceutical world, this is still better than nothing.
So yes, that they have there setup in such a way that the code cannot be modified
That's the part we don't know. Their build environment might be some guy flipping through a book of op codes. In that case, the build script (as required by the GPL) might be that book's dog-eared corners. Is it fair or right to claim that guy should be available to compile anyone's program, just because he compiled a GPL program once? Of course not. That one guy can be replaced with any other similarly-performing guy, or even an automatic compiler. The marked pages' numbers might be useless, but they do provide some insight into what's necessary to compile the program.
Arguing for the release of the build environment is an identical situation. The build environment can be replaced by any other build system, GPL or otherwise.
As for violating the spirit of the GPL, let's consider the full implications of requiring the build environment's release. Rather than granting developers the freedom to work in an environment they like, it restricts developers to working with only GPL tools. If I (hypothetically) enjoy working in Visual Studio, I'd be unable to write any GPL programs, so I simply wouldn't. Free software would die very quickly.
Fortunately, the build environment is not included. Everything I write (and thus own the copyright to) can be released as GPL, with no additional strings attached.
In fact, it seems this company is trying to be good. They've apparently released the build scripts they use, rather than trying to hide their existence. They've responded to GPL questions. They're releasing source right up front, rather than wait for someone to notice, like so many other companies. They're also following their legally-binding license agreements, which prevent them from giving away the build environment. If you cannot legally obtain the required build environment, replace it with something else, up to and including some guy with a book.
Vellmont wanted an example, and here it is. It's not clear whether the "firmware utilities" would need to be released, or even what extent of the "build environment" is covered. Do they need to release the circuit diagrams for their ROM programmers? There are so many ambiguities, yet these companies are regarded as "some bastard making money out of stealing somebody else's work".
It's healthy to fight for the GPL, but don't go looking for a fight in response to a question.
Try again. I'm not going to find the source, because I'm a lazy bum, but it's on the FSF site. The most they'd (usually) have to do is cease distribution of the GPL software.
All those formats are readily available, and I'm not asking for detailed implementations. For example, CSV is just a state machine with a buffer. SGML's simplest parser is a primarily a stack. ID3v1 is a fixed-length read from a fixed location.
It's not about being able to write a given parser from memory. It's about recognizing language types and the parser patterns that can handle them efficiently.
So the alternative is to say "This magic file is magic. Don't touch it." and expect that to be better? Let's hope there's nobody has to debug it.
The names should be protected at this stage. It's not clear whether they're doing something wrong or not (see the Visual Studio example in a nearby comment), so calling them out and setting loose the /. horde is a bit extreme at this point.
Here's my personal checklist. If, off the top of your head, you can come up with a good plan to approach these formats and situations (using no libraries), I'd love to know where you went to school:
Given that it's 1:45 AM, I reserve the right to amend this list when I'm thinking clearly.
You become a butterfly farmer to raise any kind of butterfly you want, rather than just what you already have. Chaos theory is great and all, but embedding infinite complexity into your programs is a good way to fail that ever-upcoming performance review.
This is exactly what I'm referring to. If the grammar isn't readily obvious, can you still write a parser for a language, and do so in a manner that's readable to others?
Last I checked, flex made some pretty large files just to parse out a simple language. How will your coworkers feel about having to maintain a few thousand lines of unnecessary parser code? (Note that this is based on looking at this example.)
What about a network protocol, where the whole structure may not be available at once, and may in fact be larger than your computer's memory can handle?
Sure, you may have learned how lex works, but can you actually apply that to writing a good parser yourself?
Lex, and all compiler theory, is great for compilers. If you have your entire structure in a nice well-defined form, and you're only dealing with a tiny amount of data at a time, compiling practices work fine. Once circumstances get weirder, you need to be able to adapt. Lex doesn't like adapting, and its processes are so abstract as to be ridiculously excessive for most jobs.
Mostly agreed, and I'll sign my name to it.
Spolsky's got some decent ideas, and knows a lot about what he talks about, but his idea of "good" and "bad" makes me cringe. He's one of those folks who's built up a following on what little they had to talk about, then ceased to think further. Now (and for several years), he writes about half-baked lists of do's-and-don'ts that never even come close to covering exceptions.
My supervisor is (rightfully) wary of regexes, due to their reputation for unreadability. My favorite solution (in Java): Make a bunch of string constants to match various elements, then assemble those strings together into more strings, which are finally assembled into a single real regex. Sure, it takes about 15 lines for a moderately-complicated regex, but readability is superior to using 15 lines of indexof and substr.
And now, to just bring up a topic that I have a personal interest in:
Nobody knows how to write parsers anymore. I've never seen a recent university CS curriculum that covers parsing with respect to different parser constructs for different languages. Sure, the students learn to load up the chosen XML parsing library and pull in XML, and they learn to take text from stdin, but there's seldom any emphasis on what to do with more screwy formats. Maybe, just maybe, they might get exposed to different languages through a compilers class, but generally not how to process different languages outside of lex/yacc. This bothers me greatly.
If everyone is doing it in the same market, then it's not a monopoly, and not a problem.
Guaranteed security: remove all power supplies, user inputs, and network connections, and melt all hard drives.