If UltraSearch.com has a bug whereby a crafty HTTP request can allow me to download the source script instead of the output thereof, does that mean that I'm not allowed to fix the bug in derivative works?
Yeah, and to top it off if you have a bug in your program so that "download source" doesn't work correctly then you're in violation of the license, at least temporarily.
IMO the main problem with this GPL3 idea is that it forces you to become a software distributor when all you really wanted to do was distribute the output/products of the software. At least with the GPL the requirement to provide the source isn't as big of a deal because you were already distributing software.
Lots of odd situations come to mind:
Let's say my GPL3'ed website goes over my bandwidth quota so I have to shut it down. Now the output itself and the GPL3'ed source are both unavailable. Am I still under obligation to all of the people who visited the site while they had a chance to download the output, but did not have a chance to download the source?
GPL3'ed programs with smaller source code are more valuable to me as a website operator now! In fact, it would be very handy to distribute source code with all of the comments stripped and with the shortest possible variable names. Whatever you get from "download source" will be perfectly valid but it will look like an IOCCC entry.
Does this only apply to the web? What if I use a GPL3'ed mixing studio to make a track that somehow ends up in the top 40 on the radio? Do I have to include a notice in the track with my name and address so that everyone who hears the song can request me to distribute them a copy of the mixing studio source code?
From the sound of it the patent wouldn't cover cases where you are playing stolen music on your iPod, because then you're using it as a "portable, pocket-sized multimedia liability player".
"NASA scientists have confirmed that last week's Discovery disaster was caused by a camera that came loose during takeoff and damaged the heat resistent tiles on one of the wings..."
It is far easier to provide backwards compatability to earlier file formats when you are using XML than if you are using binary file formats. With XML, if it sees a tag it doesn't understand, the parser ignores it.
That's kind of a bummer when the ignored tag is the one that contains your document.
Windows XP comes with a thing called the "Indexing Service" that periodically crawls through the disk and builds the index that you speak of. It typically waits to do its indexing when your machine is idle, but I have that service permanently disabled because my disk is loud and the churning causes me to panic for fear that my supposedly idle machine has been 0wn3d.
Standards and "cool features" are sometimes like chicken and egg. If open source developers respond with "fork off" to every non-standard idea, then open source projects will always be playing catch-up with a fragmented codebase.
That's a very good point. Most of the posts on this topic so far have all centered around the signature as an authentication mechanism, which this notion clearly demonstrates that it is not. (Also note that when you pay for things over the phone by credit card you don't sign anything either; all they might have is your caller ID.)
Without measures like signature collection the system would be a farce. (Some people already think this is the case and choose not to participate.) Requiring signatures is just one way to lend some sort of credibility to the credit card billing system by linking some database rows to you in a real way.
Look at it: a large financial institution sends you a monthly bill with arbitrary line items on it. All they want is some piece of evidence that links you to the purchases -- and results from a query in a database owned by the CC company don't count. They can say they require their merchants to collect signatures. It must then fall on you to say you've never even shopped there, or it wasn't you that signed, or the merchant isn't collecting signatures like they should. Now you have something specific about you and the merchant to argue about, which is more than nothing.
When you make a purchase over the phone and don't sign, they can point out that there was a phone call from your home number. You could deny the phone call, or say it wasn't you, but now you are arguing about a phone call on a line owned by you, so you're involved in some material way.
Interestingly enough, I bet that if the only evidence that it's your phone line is that the same credit card was used to pay the bills, that may not be enough to prove that you're actually involved, because they'd be effectively using their database to bear witness to itself.
All other things being equal, a contactless system is less secure, and not because of snooping. I find it disturbing that the only security question the article raised had to do with snooping.
Currently I enjoy the "contact-required" cards' security feature that lets you know anytime your card is being read. You know because you had to take it out of your pocket and swipe it. Contact-free takes away this feature, no matter how much crypto you throw at it.
If VISA is really trying to improve security, I'd rather see credit cards work more like how my smartcard already works. You still have to swipe it, but it uses crypto to prevent the key from being stolen.
I refuse to believe that crypto technology to prevent the card key from being stolen can only be used in a "contact-free" system.
Raising the gas tax would cause more people to switch to hybrids, which would cause even less gas taxes to be collected, which would cause an even larger shortfall in the state's transportation fund.
Brilliant! So you hike the gas tax some more, and then people are forced to find more fuel efficient vehicles, so you need to hike the gas tax again, and so on until all of our vehicles run on tax instead of gas. Thus we eliminate our petroleum dependency.
But seriously, the original poster does raise a good question about why they'd want to put GPS in there. I mean, it seems obvious that cars already have low-tech odometers that're more accurate than GPS, so why not just use those to report mileage?
Here are some reasons I thought of:
Is it for accuracy?
I doubt it. GPS tends to yield mileage calculations that are on the low side because it uses a finite set of samples to define a polygonal estimate of your route. And you lose samples when you drive under trees and bridges or in valleys with steep walls, etc. There are little hiccups every now and then though: One time a friend of mine was hiking here in WA and his GPS receiver recorded a few oddball samples as being somewhere off the coast of Hawaii. This instantly logged over 5,000 miles to his day hike.
Maybe it's good lobbying by the guys that will get to install their hardware in cars owned by millions of consumers who don't have a choice?
Could be! If so then I need to get them working for me!
Maybe it's big brother getting his foot in the door?
Heh. Moving along...
The only other reason I could think of had to do with what a bunch of other people have also raised: "Does this mean I have to get charged for my mileage on my private road just because I fill up at a public gas station?"... There's a lot in that actually. There are many different classes of roads and they're funded in different ways. I used to live in a housing development where as residents we all had to pay to maintain our own access roads, and I'd log about 3 miles round trip on that road everytime I needed to go anywhere. It is also an interesting fact that certain stretches of beach in WA are considered public highways that you can drive on.
Presumably GPS would be used to "toll" you depending on which sections of road you drove on, and how far. (Hey maybe you can eliminate toll booths then.)
IMO it's far too complex and invasive to be worth it. A much better idea would be to simply let things go as they are and maintain the roads less. As they become bumpier, your fuel efficiency will decline, and you'll pay more and find a new equilibrium of road maintenance.;-)
"Proprietary" isn't too far off, given those non-standard extensions for encoding executable code that weren't in the original standard... It's a feature!
Consider, for a moment, that this is already possible through procreation and has been going on for thousands of years. One way of reading the article is as a challenge to our concept of identity.
A lot more than 80 years of wandering has been done by our collective human identity. Entire cities built over hundreds or thousands of years already do exist.
Who told us that our identity is limited to one pile of gray mush conditioned by a single set of attached sensory inputs? That is a weak identity that can be destroyed by a snake bite, a misplaced step, or disease. 1,000 extra years doesn't alleviate any problems with this since it's only a drop in the bucket of time.
A stronger identity is a collective one that carries through generations of people. Identity is preserved through the spirit that you pass on to the next generation. Teaching, sharing, and fellowship all serve to pass on the identity. There is also the darker side passed on through selfishness, hate, and war.
In the end, the stronger sense of identity will prevail. Pass on a good spirit to the next generation. By paying kindness and proper attention to those around you -- especially children -- you are doing far more to preserve a good identity than 1,000 extra years in a "mortal coil" could ever afford.
DDL
P.S. In keeping with the spirit of collective identity, keep those machines patched and up to date!
In Seattle we don't get ice on the lakes or the sound, and it's not much cooler here in the winter than it is in the summer. Deeper water is still cooler here though. It doesn't take ice melting to get that way, or even a much colder winter.
Seems to me that there are really a few levels of automated testing: there's automatically generating and running test cases, and there's having the ability to automatically repeat test cases you've manually created and run in the past.
Just being able to repeat manually created test cases is a big help. It sounds really simple -- create a harness that you can plug test cases into and start writing test cases -- but scheduling and coordinating that sort of thing starts to get really difficult on large projects.
Where I work (a certain large software company) we have about as many full-time testers as we have developers, and it takes work from all of us to keep the test framework up to date and running. Our testers actually write a lot of code as part of their job; their code isn't shipped as part of the product -- it's used to test it. They write test cases and create infrastructure for running test cases. The developers also create test cases that can plug into the test harnesses. It actually took a lot of work to get all of that running smoothly for a project that is large and has a lot of people checking in every day.
Before every checkin we can submit our change to a server farm that runs a smoke build (to verify that things build) and also runs a suite of basic functionality tests (written by developers) to make sure nothing is outright broken by the checkin. It really goes a long way toward ensuring that you have a good build almost every day.
We also run separate automated test passes that take a lot longer but are much more thorough. They include a lot of manually developed cases with some written according to a plan and others arising as specific regression tests. (Having a big regression suite is very important when you're supporting/maintaining previous versions of your software with service packs and hotfixes!)
Automated deployment is also a biggie! Since the software product we work on is intended to be deployed as a distributed system, we also do a lot of testing with multiple nodes deployed. My group spent a lot of man-hours preparing a system than can automatically wipe and install multi-server topologies and then run test cases across them. So basically you get two things: hands-free setup of all installation and config for a large number of machines, and test case coordination between nodes (e.g. something runs on node A, then waits for node B to do something, then checks a result on node C). If you need to verify a fix that only affects scenarios with at least 5 servers involved it can really take a lot of time if you have to set up and test the scenario manually! (Also it is a pity that some software can get complicated enough that new problems will only appear after you have at least a certain number of nodes, but that is another story.)
As far as automatic test case generation goes, we don't have a lot of that. It has its place, but I have to agree with something another poster stated which is that as long as there is a human user involved you need a human tester at the other end. (There's no one-size-fits-all tool that you can run against your software that will magically return "true" iff it is flawless.)
One thing that automatic tools are good at is checking fundamental things at code level, and we do use some tools that do that. One of our tools instruments our binaries by marking every code block so that when you run it you can get "code coverage" output. This helps you see a couple of things: you can get a feel for the complexity of your code (you'll see the number of blocks and arcs for each function or group of functions), and you can see which code gets hit and how many times when you run a particular test case. This allows you to do a few things -- target complex areas of code to try and make simplifications, and target potential dead code areas for removal. This recognizes a couple of fundamental rules of software: complicated code is generally more bug-prone, and dead code is an accident waiting to happen. In the spirit of using automatic tools, this information by itself doesn't mean anything -- it's only good if it's used as feedback to the development process.
Dial-up has the advantage that your machine is safer since it isn't connected to the network 24/7. And even if you do still get 0wn3d while you're dialed in, your box will only be able to start spraying spam at 56K dial-up speed, which is better for everyone else.
...and conventional ovens have the added advantage that you don't have to worry about all that dangerous radiation leaking out of your microwave!! (Just kidding.)
Slashdot already has this feature. You simply post your changes in a reply to your original post, as is clearly demonstrated in this thread. Moderation from the original post is not applied to the reply; replies to the original post are not listed as replies to the changed post, and the changed post has a link to the original posting labeled "parent".
What the heck? Does the severity of a bug depend upon how much people are affected?
To a certain degree, yeah -- it's a cruel world.
<tongue in="cheek">And why doesn't the Department of Homeland Security just leave the threat level at "severe" everyday because on any given day someone, somewhere, might be attacked?</tongue>
Sure, severity is heavily based on the impact the bug has if you hit it, but it also takes into account any significant factors that mitigate damages to lower the risk.
Issues with awful consequences that affect someone using the software with the default settings are typically riskier than those that only affect, say, those of us using some obscure feature with a few uncommon configuration changes.
Bottom line is that the severity isn't a moral statement; its goal here is to make the security bulletins more useful by giving people a way to filter them, if they know how the system works. If everything is posted "critical", there's no point in using that field anymore. Not everyone thinks about this, but when you change your configuration or software usage scenario even the slightest bit away from the beaten path, you may also need to change your system for supporting the software. If you don't use the default settings for a piece of software, it might be a good idea to treat those "important" bulletins as "critical".
If you don't understand the system, or just want to spite it, ignore that field and just treat everything as critical, and if you don't agree with the system, post on Slashdot.
Slashdot Mirror
If they spend 99% of their uptime running MS software, then whose processors are they? ;-)
So why don't they add some kind of in-game court of appeals where other players can come watch and/or vote?
D
If UltraSearch.com has a bug whereby a crafty HTTP request can allow me to download the source script instead of the output thereof, does that mean that I'm not allowed to fix the bug in derivative works?
Yeah, and to top it off if you have a bug in your program so that "download source" doesn't work correctly then you're in violation of the license, at least temporarily.
IMO the main problem with this GPL3 idea is that it forces you to become a software distributor when all you really wanted to do was distribute the output/products of the software. At least with the GPL the requirement to provide the source isn't as big of a deal because you were already distributing software.
Lots of odd situations come to mind:
D
Your most excellent rhetoric reminds me of one of my favorite Strong Bad e-mails!
From the sound of it the patent wouldn't cover cases where you are playing stolen music on your iPod, because then you're using it as a "portable, pocket-sized multimedia liability player".
D
"NASA scientists have confirmed that last week's Discovery disaster was caused by a camera that came loose during takeoff and damaged the heat resistent tiles on one of the wings..."
D
That's kind of a bummer when the ignored tag is the one that contains your document.
Windows XP comes with a thing called the "Indexing Service" that periodically crawls through the disk and builds the index that you speak of. It typically waits to do its indexing when your machine is idle, but I have that service permanently disabled because my disk is loud and the churning causes me to panic for fear that my supposedly idle machine has been 0wn3d.
D
Those who have experienced such a thing can't post on Slashdot. Let's face it: Slashdot is biased against the dead.
Standards and "cool features" are sometimes like chicken and egg. If open source developers respond with "fork off" to every non-standard idea, then open source projects will always be playing catch-up with a fragmented codebase.
You sound pissed off!
That's a very good point. Most of the posts on this topic so far have all centered around the signature as an authentication mechanism, which this notion clearly demonstrates that it is not. (Also note that when you pay for things over the phone by credit card you don't sign anything either; all they might have is your caller ID.)
Without measures like signature collection the system would be a farce. (Some people already think this is the case and choose not to participate.) Requiring signatures is just one way to lend some sort of credibility to the credit card billing system by linking some database rows to you in a real way.
Look at it: a large financial institution sends you a monthly bill with arbitrary line items on it. All they want is some piece of evidence that links you to the purchases -- and results from a query in a database owned by the CC company don't count. They can say they require their merchants to collect signatures. It must then fall on you to say you've never even shopped there, or it wasn't you that signed, or the merchant isn't collecting signatures like they should. Now you have something specific about you and the merchant to argue about, which is more than nothing.
When you make a purchase over the phone and don't sign, they can point out that there was a phone call from your home number. You could deny the phone call, or say it wasn't you, but now you are arguing about a phone call on a line owned by you, so you're involved in some material way.
Interestingly enough, I bet that if the only evidence that it's your phone line is that the same credit card was used to pay the bills, that may not be enough to prove that you're actually involved, because they'd be effectively using their database to bear witness to itself.
All other things being equal, a contactless system is less secure, and not because of snooping. I find it disturbing that the only security question the article raised had to do with snooping.
Currently I enjoy the "contact-required" cards' security feature that lets you know anytime your card is being read. You know because you had to take it out of your pocket and swipe it. Contact-free takes away this feature, no matter how much crypto you throw at it.
If VISA is really trying to improve security, I'd rather see credit cards work more like how my smartcard already works. You still have to swipe it, but it uses crypto to prevent the key from being stolen.
I refuse to believe that crypto technology to prevent the card key from being stolen can only be used in a "contact-free" system.
Brilliant! So you hike the gas tax some more, and then people are forced to find more fuel efficient vehicles, so you need to hike the gas tax again, and so on until all of our vehicles run on tax instead of gas. Thus we eliminate our petroleum dependency.
But seriously, the original poster does raise a good question about why they'd want to put GPS in there. I mean, it seems obvious that cars already have low-tech odometers that're more accurate than GPS, so why not just use those to report mileage?
Here are some reasons I thought of:
Is it for accuracy?
I doubt it. GPS tends to yield mileage calculations that are on the low side because it uses a finite set of samples to define a polygonal estimate of your route. And you lose samples when you drive under trees and bridges or in valleys with steep walls, etc. There are little hiccups every now and then though: One time a friend of mine was hiking here in WA and his GPS receiver recorded a few oddball samples as being somewhere off the coast of Hawaii. This instantly logged over 5,000 miles to his day hike.
Maybe it's good lobbying by the guys that will get to install their hardware in cars owned by millions of consumers who don't have a choice?
Could be! If so then I need to get them working for me!
Maybe it's big brother getting his foot in the door?
Heh. Moving along...
The only other reason I could think of had to do with what a bunch of other people have also raised: "Does this mean I have to get charged for my mileage on my private road just because I fill up at a public gas station?"... There's a lot in that actually. There are many different classes of roads and they're funded in different ways. I used to live in a housing development where as residents we all had to pay to maintain our own access roads, and I'd log about 3 miles round trip on that road everytime I needed to go anywhere. It is also an interesting fact that certain stretches of beach in WA are considered public highways that you can drive on.
Presumably GPS would be used to "toll" you depending on which sections of road you drove on, and how far. (Hey maybe you can eliminate toll booths then.)
IMO it's far too complex and invasive to be worth it. A much better idea would be to simply let things go as they are and maintain the roads less. As they become bumpier, your fuel efficiency will decline, and you'll pay more and find a new equilibrium of road maintenance. ;-)
"Proprietary" isn't too far off, given those non-standard extensions for encoding executable code that weren't in the original standard... It's a feature!
D
Those of you who live to 1000 will be living with the descendants of the losers. ;-)
Consider, for a moment, that this is already possible through procreation and has been going on for thousands of years. One way of reading the article is as a challenge to our concept of identity.
A lot more than 80 years of wandering has been done by our collective human identity. Entire cities built over hundreds or thousands of years already do exist.
Who told us that our identity is limited to one pile of gray mush conditioned by a single set of attached sensory inputs? That is a weak identity that can be destroyed by a snake bite, a misplaced step, or disease. 1,000 extra years doesn't alleviate any problems with this since it's only a drop in the bucket of time.
A stronger identity is a collective one that carries through generations of people. Identity is preserved through the spirit that you pass on to the next generation. Teaching, sharing, and fellowship all serve to pass on the identity. There is also the darker side passed on through selfishness, hate, and war.
In the end, the stronger sense of identity will prevail. Pass on a good spirit to the next generation. By paying kindness and proper attention to those around you -- especially children -- you are doing far more to preserve a good identity than 1,000 extra years in a "mortal coil" could ever afford.
DDL
P.S. In keeping with the spirit of collective identity, keep those machines patched and up to date!
...Yeah, it'll be drawn-out at least 10 times as long as at present.
In Seattle we don't get ice on the lakes or the sound, and it's not much cooler here in the winter than it is in the summer. Deeper water is still cooler here though. It doesn't take ice melting to get that way, or even a much colder winter.
Seems to me that there are really a few levels of automated testing: there's automatically generating and running test cases, and there's having the ability to automatically repeat test cases you've manually created and run in the past.
Just being able to repeat manually created test cases is a big help. It sounds really simple -- create a harness that you can plug test cases into and start writing test cases -- but scheduling and coordinating that sort of thing starts to get really difficult on large projects.
Where I work (a certain large software company) we have about as many full-time testers as we have developers, and it takes work from all of us to keep the test framework up to date and running. Our testers actually write a lot of code as part of their job; their code isn't shipped as part of the product -- it's used to test it. They write test cases and create infrastructure for running test cases. The developers also create test cases that can plug into the test harnesses. It actually took a lot of work to get all of that running smoothly for a project that is large and has a lot of people checking in every day.
Before every checkin we can submit our change to a server farm that runs a smoke build (to verify that things build) and also runs a suite of basic functionality tests (written by developers) to make sure nothing is outright broken by the checkin. It really goes a long way toward ensuring that you have a good build almost every day.
We also run separate automated test passes that take a lot longer but are much more thorough. They include a lot of manually developed cases with some written according to a plan and others arising as specific regression tests. (Having a big regression suite is very important when you're supporting/maintaining previous versions of your software with service packs and hotfixes!)
Automated deployment is also a biggie! Since the software product we work on is intended to be deployed as a distributed system, we also do a lot of testing with multiple nodes deployed. My group spent a lot of man-hours preparing a system than can automatically wipe and install multi-server topologies and then run test cases across them. So basically you get two things: hands-free setup of all installation and config for a large number of machines, and test case coordination between nodes (e.g. something runs on node A, then waits for node B to do something, then checks a result on node C). If you need to verify a fix that only affects scenarios with at least 5 servers involved it can really take a lot of time if you have to set up and test the scenario manually! (Also it is a pity that some software can get complicated enough that new problems will only appear after you have at least a certain number of nodes, but that is another story.)
As far as automatic test case generation goes, we don't have a lot of that. It has its place, but I have to agree with something another poster stated which is that as long as there is a human user involved you need a human tester at the other end. (There's no one-size-fits-all tool that you can run against your software that will magically return "true" iff it is flawless.)
One thing that automatic tools are good at is checking fundamental things at code level, and we do use some tools that do that. One of our tools instruments our binaries by marking every code block so that when you run it you can get "code coverage" output. This helps you see a couple of things: you can get a feel for the complexity of your code (you'll see the number of blocks and arcs for each function or group of functions), and you can see which code gets hit and how many times when you run a particular test case. This allows you to do a few things -- target complex areas of code to try and make simplifications, and target potential dead code areas for removal. This recognizes a couple of fundamental rules of software: complicated code is generally more bug-prone, and dead code is an accident waiting to happen. In the spirit of using automatic tools, this information by itself doesn't mean anything -- it's only good if it's used as feedback to the development process.
D
This device is a perfect candidate for modding into a 1TB file server!
D
Dial-up has the advantage that your machine is safer since it isn't connected to the network 24/7. And even if you do still get 0wn3d while you're dialed in, your box will only be able to start spraying spam at 56K dial-up speed, which is better for everyone else.
...and conventional ovens have the added advantage that you don't have to worry about all that dangerous radiation leaking out of your microwave!! (Just kidding.)
Slashdot already has this feature. You simply post your changes in a reply to your original post, as is clearly demonstrated in this thread. Moderation from the original post is not applied to the reply; replies to the original post are not listed as replies to the changed post, and the changed post has a link to the original posting labeled "parent".
DDL
To a certain degree, yeah -- it's a cruel world.
<tongue in="cheek">And why doesn't the Department of Homeland Security just leave the threat level at "severe" everyday because on any given day someone, somewhere, might be attacked?</tongue>
Sure, severity is heavily based on the impact the bug has if you hit it, but it also takes into account any significant factors that mitigate damages to lower the risk.
Issues with awful consequences that affect someone using the software with the default settings are typically riskier than those that only affect, say, those of us using some obscure feature with a few uncommon configuration changes.
Bottom line is that the severity isn't a moral statement; its goal here is to make the security bulletins more useful by giving people a way to filter them, if they know how the system works. If everything is posted "critical", there's no point in using that field anymore. Not everyone thinks about this, but when you change your configuration or software usage scenario even the slightest bit away from the beaten path, you may also need to change your system for supporting the software. If you don't use the default settings for a piece of software, it might be a good idea to treat those "important" bulletins as "critical".
If you don't understand the system, or just want to spite it, ignore that field and just treat everything as critical, and if you don't agree with the system, post on Slashdot.
DDL