So a forked right version quite obviously would have multiple copyright holders, for the new and old code. Right? Right. What happens to the forked version if and when the copyright holder decides to re-license their code under a more stringent license? Are they now forced to either license the code or drop the product?
Definitely not! Once code has been released under the GPL, the copyright holder cannot later change their mind and revoke that license! Just because they offer it under an additional license later does not in any way affect use under the GPL.
Re:Podcasting is right up there with blog...
on
Podcasting
·
· Score: 2, Insightful
Podcasting: It's snob for "streaming audio."
That would be funny, except it's wrong.
Podcasting refers to subscribing to audio clips containing regularly updated and timely content and automatically downloading them them so that you can listen to them later, then automatically copying them to a portable music device so that you can listen away from your computer and Internet connection. (So it's not streaming audio at all; the audio files are downloaded in batch.)
All of these concepts existed before, but nobody had ever put them together into a somewhat standardized system, and there was no critical mass of content providers until recently.
The technology is not revolutionary. The idea seems obvious once you hear of it. But until Podcasting, nobody listened to timely, but non-real-time audio programs before. Now millions of people do. That's why there's a word for it.
Listen, I hate buzzwords too. Podcasting is probably overhyped. But that doesn't mean that it's just the same as streaming audio, and that there aren't any interesting new ideas there, either.
I thought they worked for the passengers on September 11th?
Yes, you're right. Cell phones do work in the air. In fact part of the problem is that they work too well - cells on the ground have a hard time keeping up. If everyone in the air tried to use their cell phones, it would be like a denial-of-service attack on cell towers.
Carnegie-Mellon these are the guys who love to quantify the unquantifiable.
Didn't they also give us the "Capability Maturity Model"?
FYI, CMM came from Carnegie Mellon's Software Engineering Institute, an affiliated but wholly separate spinoff. This rating system comes from Carnegie Mellon West, a new spinoff campus in Silicon Valley (on the other side of the country from their main campus in Pittsburgh). Neither of these systems come from CMU's main School of Computer Science. Plus, I believe Carnegie Mellon has more computer science researchers than any other university in the world, so it's silly to look at a CMU project and say "these are the same guys" who did anything...
ASP: Advantage - one of the largest pools of experienced developers. Disadvantage - ties you to Windows; can't take advantage of much free/open-source software.
PHP: Designed specifically for web programming but not proprietary like Microsoft. Disadvantage - it's rarely used by anyone outside of Web programming, so it's hard to find PHP software libraries or example code to do anything not commonly done on a web server.
Python: Some would argue, one of the nicest languages for rapid prototyping, but scales quite well to large applications. Disadvantage - smaller pool of experienced developers, plus unique syntax that some people don't like.
Java: Very large pool of knowledgeable developers, powerful class libraries, and better performance than scripting languages. Disadvantage - very verbose syntax; it often takes a lot more code to accomplish something than any of the scripting languages (above).
C: No good reason to use C to develop the whole backend. Use C to implement a few extensions where performance is critical, and use a higher-level language to implement the rest.
C++: Advantage - Huge developer pool, great performance, a little less verbose than Java, and lots of free software to re-use. Disadvantage - you have to compile your code before running it, you worry about memory management and buffer overflows, and in general it's not as nimble as scripting languages.
You didn't make it clear who is doing the development.
If you're doing the development by yourself, then obviously you should weigh the choices and pick the language that will work best for you. Development time, for example, is highly dependent on how well you already know the languages.
However, if you already have a developer, or a team of developers, to do this development, then whatever you do don't force them to use what you think is the best language. That's a guaranteed way to lower productivity and morale if they think it's a poor choice! Ask them to make recommendations. Maybe even spend a couple of days prototyping various things in different languages first.
One of the nicest things about back ends is that it doesn't matter what language you use (nobody can tell from the outside) and you can easily mix and match languages. There's nothing wrong with writing the majority of the code in PHP or Python for rapid development, but using Java or C++ extensions for a few of the computationally-intensive algoritihms.
So, umm, how long - exactly - does it take to upload 560 GB over a broadband connection?
On the order of a week. But how much of that data changes on a daily basis? For most users, maybe just a few tens of megabytes or less. For a small fraction of users who generate tens of gigabytes of new data every day which absolutely must be backed up, offsite online is not the best solution. But it works great for everyone else. And it is still useful for the most critical fraction of the heavy data user's data.
I've got to disagree with you about the South Park movie. I thought it was as good as the best South Park episodes, but the slightly slower pacing of the jokes and plot made it a lot more accessible to people who weren't already huge South Park fans.
Is it "Floppy is dead" or "removable mass media is dead"?
I think it's the latter, because of ubiquitous network storage. It's faster to copy the file to a network volume, or even just email it to yourself, than it would be to copy it to a floppy. And if you do need to copy something really large, then burning a CD is actually quite efficient.
Microsoft takes a lot of flak for abominably bloated software filled with bells and whistles that nobody uses. Maybe we shouldn't criticize them for freezing the features and fixing the bugs.
Except that PowerPoint still has all of the same bugs that the 1997 version did. Not the ones that crash - those have been fixed - but the little annoyances that have workarounds are still there.
Check out Keynote sometime; it will show you what PowerPoint SHOULD be. In the course of two years, Apple came out with a package that runs circles around virtually every feature that PowerPoint has, is easier to use, nicer looking, and on top of it all can actually import PowerPoint files too!
People keep talking like Java has failed and is now dead and gone.
Java as a language is far from dead - it's more popular than ever, no question. However, Java as a tool for delivering interactive web applications is nearly dead. Why? Internet Explorer doesn't include a recent version of Java by default, and it's way too large for most people to download. Not only that, but Java's widgets are still flaky and subtly different than native ones, and there's very little browser integration. So there are very few web tools for which Java is the best solution, even though the language itself is good and getting better.
People have been working on this problem for a long time. Check out papers published at ISMIR (International Symposium/Conference on Music Information Retrieval) for the academic work. The algorithms and technology are there, no question - the problem is the business model and the licensing. It seems simple, until you try to talk to record executives who don't want to license you access to their music catalog. It seems counterintuitive, since in theory it would make them more money, but they apparently don't see it that way.
Also, while it's technically feasible, it does get significantly more difficult computationally when you want to search an entire library of songs.
Here's an example of a free site that has the technology implemented, just without the database of popular songs (it works great for classical melodies).
Not trying to discourage you - the point being, either go into this because you think the tech is cool but don't expect to make money, or if your goal is to get rich, become a business major and be prepared to spend all of your time meeting with VC execs and recording industry leaders, rather than building cool tech.
A large part of a diamond's appeal is that something so stunningly beautiful was formed naturally. We can produce pretty, sparkly stones, but they can never be as beautiful simply because we produced them.
Nice try. Natural diamonds are hardly beautiful. Only when you carefully cut them exactly the right way, and polish them properly, do they appear so beautiful. And it's really hard to argue that diamonds are more beautiful than any other gemstone - almost all of which can be created in the lab now, by the way.
No, diamonds are just the most expensive gem. For no good reason. And thankfully, perhaps not for much longer.
Not arguing about the ISS being a waste, but I'm not sure it's a bad idea that different space agencies are all developing their own launch vehicles. A small amount of competition in terms of engineering will be better for everyone in the long run, right? Obviously everyone should still share science data and results, though.
I don't get. If it's not a geosync, then it's going to be moving, so they could just use 2 images from a few seconds apart to get the required images. No?
Yes, some satellites do this now; the camera takes one image, then a minute later rotates and takes an image of the same area from a different angle. In order to do this a lot, though, the camera would have to constantly rotate, and the data would have to be recalibrated each time because of imprecision in its ability to rotate to a precise angle. By mounting two cameras at a fixed angular separation, they don't need the cameras to be able to move as often, and they can take images continuously from both cameras simultaneously.
Uh, can't they already determine heights to high degree of accuracy with GPS or other radio wave methods?
Yes.
How would a picture be more accurate?
Well, among the most accurate topographical maps available are from the Shuttle Radar Topography mission, which gave us the entire earth at roughly 30-m resolution, with a height precision of about 16 meters.
India's new satellite has 2.5-meter resolution, and its vertical accuracy after proper stereoscopic matching would be of the same order of magnitude so clearly in this case, it is more accurate.
Plus, the SRTM mission is over. It doesn't help if you're trying to measure a new building, for example.
You could probably get more accurate with a specialized radar or lidar instrument, but those give you point measurements, not images. And passive imaging requires far less power. So, there are lots of advantages to stereo images.
There's probably TWO cameras, one for visible light, one for infrared. Not two cameras for binocular vision. The two "eyes" would be too close together for any usable stereoscopic effect.
No, if you look up the technical specifications, you'll see that the satellite has two cameras pointed in different directions. Each camera has only one panchromatic spectral band, sensitive to 500 nm to 850 nm (visible through near-infrared).
Most satellite imagers do have multiple spectral bands - usually far more than just 1 or 2. I'm guessing that in this case they decided to trade spectral resolution for stereo, plus the maximum possible spatial resolution. That makes sense, because there's no shortage of satellites that image with lots of spectral bands, though at lower resolution.
This isn't the first stereographic satellite that's accessible to the general public; that would be MISR - NASA's Multi-angle Imaging Spectroradiometer, built by JPL, with nine cameras pointed in different directions along its direction of travel in polar orbit, ranging from nadir (straight down) to 70 degrees in either direction. Compared to India's new high-resolution satellite, MISR seems very low resolution - 275 meters per pixel - however, it covers the entire surface of the Earth every few days and all of the data is available for free at this resolution, while India's satellite is "targeting"; it only images a particular area when it is programmed to do so. MISR is used primarily to study clouds and aerosols.
To see some 3-D images taken by MISR or some animations of its 9 cameras' views of different scenes, check out their gallery.
Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.
Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.
I totally agree. There is an interesting exception, though: sometimes I've seen people write a very complicated algorithm in a high-level language (Perl, Python, Matlab, etc.) that has great theoretical runtime, but huge overhead. I write the same thing in straight C using the naive algorithm and it ends up being 10x faster in practice, with 1/10 as many lines of code. So it does go both ways.
For example - how much faster do you think it would be to use the SSE2 16 byte registers to memcpy() instead of the C stdlib way of doing it byte by byte? Answer? A *LOT* faster. Which is good if you're moving a lot of data real time.
While glibc's memcpy wasn't very efficient (before gcc 4.0, which I think improves it), the memcpy implementation for most proprietary operating systems (Windows, Mac OS X, Solaris, etc.) tends to be very efficient, using vector registers, etc.
Comments are very important, however you need to figure out the right level of detail that provides as much documentation as possible, without taking too much time away from coding (because then you'll be likely to leave the comments out).
Incorrect comments are worse than no comments at all. In an ideal world, you'd figure out what you want to do, write the documentation for the function, then implement it, documenting any lines that aren't obvious. However, life is never like that. Sometimes you need to modify a function to make it do something else. If your comments are too long and verbose, you'll be tempted to not change them, which is worse than not having them there at all!
Therefore, you should keep your comments concise. Don't waste your time writing detailed comments for a simple function, or one that is likely to change tomorrow. But when you finish a complicated function and get it to work, definitely make sure it's well-commented, so you don't have to worry about it again.
Why didn't Apple ship a DVD _and_ CDs? They could have put the CDs in a special, extra layer of packaging, with a warning: "you don't need these CDs unless you have a Mac without a DVD drive".
For instance, I know several people on various SourceForge projects who basically gave up trying to work with SourceForge CVS because it's so damn complicated to get set up and working. Even when CVS hosting is offered for FREE people choose not to use it because it's such a pain in the ass. That right there should tell you something.
Now, I'd be the first to admit that CVS has some major flaws, but for small to medium-sized projects with a dozen or fewer developers, it works quite well. I've been using CVS on SourceForge for five years, and I think it works great. The only complicated thing is that they require you to access it securely via SSH, but there are detailed instructions on how to do this available for all major platforms.
Slashdot Mirror
So a forked right version quite obviously would have multiple copyright holders, for the new and old code. Right? Right. What happens to the forked version if and when the copyright holder decides to re-license their code under a more stringent license? Are they now forced to either license the code or drop the product?
Definitely not! Once code has been released under the GPL, the copyright holder cannot later change their mind and revoke that license! Just because they offer it under an additional license later does not in any way affect use under the GPL.
Podcasting: It's snob for "streaming audio."
That would be funny, except it's wrong.
Podcasting refers to subscribing to audio clips containing regularly updated and timely content and automatically downloading them them so that you can listen to them later, then automatically copying them to a portable music device so that you can listen away from your computer and Internet connection. (So it's not streaming audio at all; the audio files are downloaded in batch.)
All of these concepts existed before, but nobody had ever put them together into a somewhat standardized system, and there was no critical mass of content providers until recently.
The technology is not revolutionary. The idea seems obvious once you hear of it. But until Podcasting, nobody listened to timely, but non-real-time audio programs before. Now millions of people do. That's why there's a word for it.
Listen, I hate buzzwords too. Podcasting is probably overhyped. But that doesn't mean that it's just the same as streaming audio, and that there aren't any interesting new ideas there, either.
I thought they worked for the passengers on September 11th?
Yes, you're right. Cell phones do work in the air. In fact part of the problem is that they work too well - cells on the ground have a hard time keeping up. If everyone in the air tried to use their cell phones, it would be like a denial-of-service attack on cell towers.
Carnegie-Mellon these are the guys who love to quantify the unquantifiable.
Didn't they also give us the "Capability Maturity Model"?
FYI, CMM came from Carnegie Mellon's Software Engineering Institute, an affiliated but wholly separate spinoff. This rating system comes from Carnegie Mellon West, a new spinoff campus in Silicon Valley (on the other side of the country from their main campus in Pittsburgh). Neither of these systems come from CMU's main School of Computer Science. Plus, I believe Carnegie Mellon has more computer science researchers than any other university in the world, so it's silly to look at a CMU project and say "these are the same guys" who did anything...
ASP: Advantage - one of the largest pools of experienced developers. Disadvantage - ties you to Windows; can't take advantage of much free/open-source software.
PHP: Designed specifically for web programming but not proprietary like Microsoft. Disadvantage - it's rarely used by anyone outside of Web programming, so it's hard to find PHP software libraries or example code to do anything not commonly done on a web server.
Python: Some would argue, one of the nicest languages for rapid prototyping, but scales quite well to large applications. Disadvantage - smaller pool of experienced developers, plus unique syntax that some people don't like.
Java: Very large pool of knowledgeable developers, powerful class libraries, and better performance than scripting languages. Disadvantage - very verbose syntax; it often takes a lot more code to accomplish something than any of the scripting languages (above).
C: No good reason to use C to develop the whole backend. Use C to implement a few extensions where performance is critical, and use a higher-level language to implement the rest.
C++: Advantage - Huge developer pool, great performance, a little less verbose than Java, and lots of free software to re-use. Disadvantage - you have to compile your code before running it, you worry about memory management and buffer overflows, and in general it's not as nimble as scripting languages.
You didn't make it clear who is doing the development.
If you're doing the development by yourself, then obviously you should weigh the choices and pick the language that will work best for you. Development time, for example, is highly dependent on how well you already know the languages.
However, if you already have a developer, or a team of developers, to do this development, then whatever you do don't force them to use what you think is the best language. That's a guaranteed way to lower productivity and morale if they think it's a poor choice! Ask them to make recommendations. Maybe even spend a couple of days prototyping various things in different languages first.
One of the nicest things about back ends is that it doesn't matter what language you use (nobody can tell from the outside) and you can easily mix and match languages. There's nothing wrong with writing the majority of the code in PHP or Python for rapid development, but using Java or C++ extensions for a few of the computationally-intensive algoritihms.
So, umm, how long - exactly - does it take to upload 560 GB over a broadband connection?
On the order of a week. But how much of that data changes on a daily basis? For most users, maybe just a few tens of megabytes or less. For a small fraction of users who generate tens of gigabytes of new data every day which absolutely must be backed up, offsite online is not the best solution. But it works great for everyone else. And it is still useful for the most critical fraction of the heavy data user's data.
I've got to disagree with you about the South Park movie. I thought it was as good as the best South Park episodes, but the slightly slower pacing of the jokes and plot made it a lot more accessible to people who weren't already huge South Park fans.
Is it "Floppy is dead" or "removable mass media is dead"?
I think it's the latter, because of ubiquitous network storage. It's faster to copy the file to a network volume, or even just email it to yourself, than it would be to copy it to a floppy. And if you do need to copy something really large, then burning a CD is actually quite efficient.
Given that the English Wikipedia is more than twice as big as the next largest, it seems a little silly to have it in the middle of Europe.
Yeah, since no Europeans speak English...
Microsoft takes a lot of flak for abominably bloated software filled with bells and whistles that nobody uses. Maybe we shouldn't criticize them for freezing the features and fixing the bugs.
Except that PowerPoint still has all of the same bugs that the 1997 version did. Not the ones that crash - those have been fixed - but the little annoyances that have workarounds are still there.
Check out Keynote sometime; it will show you what PowerPoint SHOULD be. In the course of two years, Apple came out with a package that runs circles around virtually every feature that PowerPoint has, is easier to use, nicer looking, and on top of it all can actually import PowerPoint files too!
People keep talking like Java has failed and is now dead and gone.
Java as a language is far from dead - it's more popular than ever, no question. However, Java as a tool for delivering interactive web applications is nearly dead. Why? Internet Explorer doesn't include a recent version of Java by default, and it's way too large for most people to download. Not only that, but Java's widgets are still flaky and subtly different than native ones, and there's very little browser integration. So there are very few web tools for which Java is the best solution, even though the language itself is good and getting better.
People have been working on this problem for a long time. Check out papers published at ISMIR (International Symposium/Conference on Music Information Retrieval) for the academic work. The algorithms and technology are there, no question - the problem is the business model and the licensing. It seems simple, until you try to talk to record executives who don't want to license you access to their music catalog. It seems counterintuitive, since in theory it would make them more money, but they apparently don't see it that way.
Also, while it's technically feasible, it does get significantly more difficult computationally when you want to search an entire library of songs.
Here's an example of a free site that has the technology implemented, just without the database of popular songs (it works great for classical melodies).
Not trying to discourage you - the point being, either go into this because you think the tech is cool but don't expect to make money, or if your goal is to get rich, become a business major and be prepared to spend all of your time meeting with VC execs and recording industry leaders, rather than building cool tech.
A large part of a diamond's appeal is that something so stunningly beautiful was formed naturally. We can produce pretty, sparkly stones, but they can never be as beautiful simply because we produced them.
Nice try. Natural diamonds are hardly beautiful. Only when you carefully cut them exactly the right way, and polish them properly, do they appear so beautiful. And it's really hard to argue that diamonds are more beautiful than any other gemstone - almost all of which can be created in the lab now, by the way.
No, diamonds are just the most expensive gem. For no good reason. And thankfully, perhaps not for much longer.
Not arguing about the ISS being a waste, but I'm not sure it's a bad idea that different space agencies are all developing their own launch vehicles. A small amount of competition in terms of engineering will be better for everyone in the long run, right? Obviously everyone should still share science data and results, though.
I don't get. If it's not a geosync, then it's going to be moving, so they could just use 2 images from a few seconds apart to get the required images. No?
Yes, some satellites do this now; the camera takes one image, then a minute later rotates and takes an image of the same area from a different angle. In order to do this a lot, though, the camera would have to constantly rotate, and the data would have to be recalibrated each time because of imprecision in its ability to rotate to a precise angle. By mounting two cameras at a fixed angular separation, they don't need the cameras to be able to move as often, and they can take images continuously from both cameras simultaneously.
Uh, can't they already determine heights to high degree of accuracy with GPS or other radio wave methods?
Yes.
How would a picture be more accurate?
Well, among the most accurate topographical maps available are from the Shuttle Radar Topography mission, which gave us the entire earth at roughly 30-m resolution, with a height precision of about 16 meters.
India's new satellite has 2.5-meter resolution, and its vertical accuracy after proper stereoscopic matching would be of the same order of magnitude so clearly in this case, it is more accurate.
Plus, the SRTM mission is over. It doesn't help if you're trying to measure a new building, for example.
You could probably get more accurate with a specialized radar or lidar instrument, but those give you point measurements, not images. And passive imaging requires far less power. So, there are lots of advantages to stereo images.
Also, concievably, they could take color images.
Conceivably, yes, though it turns out that this satellite has just one spectral band (grayscale).
You're right, though, that stereo height retrievals have many advantages over other methods for many applications.
There's probably TWO cameras, one for visible light, one for infrared. Not two cameras for binocular vision. The two "eyes" would be too close together for any usable stereoscopic effect.
No, if you look up the technical specifications, you'll see that the satellite has two cameras pointed in different directions. Each camera has only one panchromatic spectral band, sensitive to 500 nm to 850 nm (visible through near-infrared).
Most satellite imagers do have multiple spectral bands - usually far more than just 1 or 2. I'm guessing that in this case they decided to trade spectral resolution for stereo, plus the maximum possible spatial resolution. That makes sense, because there's no shortage of satellites that image with lots of spectral bands, though at lower resolution.
This isn't the first stereographic satellite that's accessible to the general public; that would be MISR - NASA's Multi-angle Imaging Spectroradiometer, built by JPL, with nine cameras pointed in different directions along its direction of travel in polar orbit, ranging from nadir (straight down) to 70 degrees in either direction. Compared to India's new high-resolution satellite, MISR seems very low resolution - 275 meters per pixel - however, it covers the entire surface of the Earth every few days and all of the data is available for free at this resolution, while India's satellite is "targeting"; it only images a particular area when it is programmed to do so. MISR is used primarily to study clouds and aerosols.
To see some 3-D images taken by MISR or some animations of its 9 cameras' views of different scenes, check out their gallery.
This has always bugged me.
Some people spend 10 hours tweaking compiler settings and optimizations to get an extra 5% performance from their code.
Other people spend 2 hours selecting the proper algorithm in the first place and get an extra 500% performance from their code.
I totally agree. There is an interesting exception, though: sometimes I've seen people write a very complicated algorithm in a high-level language (Perl, Python, Matlab, etc.) that has great theoretical runtime, but huge overhead. I write the same thing in straight C using the naive algorithm and it ends up being 10x faster in practice, with 1/10 as many lines of code. So it does go both ways.
For example - how much faster do you think it would be to use the SSE2 16 byte registers to memcpy() instead of the C stdlib way of doing it byte by byte? Answer? A *LOT* faster. Which is good if you're moving a lot of data real time.
While glibc's memcpy wasn't very efficient (before gcc 4.0, which I think improves it), the memcpy implementation for most proprietary operating systems (Windows, Mac OS X, Solaris, etc.) tends to be very efficient, using vector registers, etc.
Comments are very important, however you need to figure out the right level of detail that provides as much documentation as possible, without taking too much time away from coding (because then you'll be likely to leave the comments out).
Incorrect comments are worse than no comments at all. In an ideal world, you'd figure out what you want to do, write the documentation for the function, then implement it, documenting any lines that aren't obvious. However, life is never like that. Sometimes you need to modify a function to make it do something else. If your comments are too long and verbose, you'll be tempted to not change them, which is worse than not having them there at all!
Therefore, you should keep your comments concise. Don't waste your time writing detailed comments for a simple function, or one that is likely to change tomorrow. But when you finish a complicated function and get it to work, definitely make sure it's well-commented, so you don't have to worry about it again.
Why didn't Apple ship a DVD _and_ CDs? They could have put the CDs in a special, extra layer of packaging, with a warning: "you don't need these CDs unless you have a Mac without a DVD drive".
For instance, I know several people on various SourceForge projects who basically gave up trying to work with SourceForge CVS because it's so damn complicated to get set up and working. Even when CVS hosting is offered for FREE people choose not to use it because it's such a pain in the ass. That right there should tell you something.
Now, I'd be the first to admit that CVS has some major flaws, but for small to medium-sized projects with a dozen or fewer developers, it works quite well. I've been using CVS on SourceForge for five years, and I think it works great. The only complicated thing is that they require you to access it securely via SSH, but there are detailed instructions on how to do this available for all major platforms.