The Audacity Wiki is a community-maintained site for organizing information and resources relating to Audacity. It's publicly editable, so if you want to put download links there, you're welcome to do so!
Still no support for plugins on Linux. What's with that?
We can't include support for VST plug-ins directly, because the VST SDK doesn't let you redistribute the source code.
However, Audacity does support LADSPA plug-ins on all platforms. On the Mac and Windows we provide a VST Enabler (a LADSPA/VST bridge) and on Linux there is at least one project that enables you to access VST plug-ins through LADSPA.
And in this you see one of the major problems I feel open source has today.
None of the programs you describe are trying to do something new and imaginative, their aim is simply to clone someone else as efficently as possible.
That's not entirely true. OpenOffice is a good example of this; it clones Microsoft Office way too much in my opinion. Yes, there are differences, and some more substantial ones in 1.1, but it's still very much a clone. Then again, that's probably the only way to get lots of people to switch away from Microsoft Office.
The Gimp is not a clone of Photoshop. Obviously it's not as powerful, but for non-professional users, it's just different. Does certain things in a different way. Sometimes easier - for example I think it's easier to work with transparency in the Gimp.
Audacity is not a clone of any audio editor. It has some superficial similarities to some other programs, but that's only because they have some similar capabilities. Audacity was designed from the beginning to be as intuitive and easy-to-use as possible, while making as many professional capabilities available as possible.
We need more OSS apps which aim to be good in their own right, not simply because they are "a free replacement for X".
That sounds good in theory, but it seems like more than half of the posts in this article are saying "Audacity is good, but it will never replace audio editor X until it has feature Y". And in half of the cases, Audacity already does have feature Y - it just implements it in a different way.
Well, just had a look at the "new" audacity. I don't find it so innovative ; indeed, I was expecting for many features which were not included here. Some are pretty simple ; for example, I would like the FFT filter to have a "log scale" option, which would make it much more interesting and usable.
This is available with the Equalizer effect. I agree, it's a little confusing. These effects will be merged in a future version.
Please add your other ideas to the Audacity Feature Requests page!
This program looks like it's off to a good start, but it's not gonna replace cooledit for me. Namely, it lacks a lot of basic plugins (ADSR, amplification envelopes, fade ins/outs that don't suck, spectrum analysis, etc). Hopefully, the VST enabler project will take care of most of this.
Audacity has built-in amplification envelopes with linear-dB interpolation - i.e. fades that don't suck. You can also use built-in or plug-in effects for other types of fades. It has lots of spectrum analysis, including a spectrogram display and a frequency plot window.
And Audacity does have VST support - but currently it's limited because the VST SDK does not let us distribute the source code to it, which means that we can't integrate it directly into Audacity. Right now quite a few VST effects plug-ins work, without their GUI, and hopefully soon we will have full VSTGUI support and support for more advanced VST plug-ins, too.
For me, Audacity 1.0 is just fine for what I do - digitizing tapes and records, simple home-studio recordings. What I always missed: -fade in and out tools
Either use fade in/out effects or plug-ins, or use the built-in amplitude envelope editor - just click on the tool that looks like two triangles surrounding a control point.
-what you said
Audacity 1.2 displays the line showing the current playback/recording position
-and to be able to chose the soundcard, if you have more than 1 installed
That's always been there, in the preferences dialog.
There are already recording studios that use Sweep. I know that diversity is always good, but it doesn't look like Audacity gives anything that Sweep doesn't already, and has been doing for some time.
One huge difference is that Sweep only runs on Linux (and a few other Unix-like systems). Audacity runs natively on Linux, Windows, and Mac OS.
Also, last time I checked, Sweep is still an in-memory audio editor. Good luck trying to mix an entire CD-length album if you only have 256 MB of RAM. Audacity is disk-based and can do all of its processing in non-real-time, so you can edit and mix a large album with many tracks on a slow computer with only a little bit of RAM.
Sweep has a lot of neat features, though. They're both free, so if you use Linux, why not grab both, and use each where appropriate?
Does Audiocity [sic] really rank up there with Protools, reason and/or other expensive software apps that are used now??
Of course not. But it's free, it runs natively on 3+ platforms, it's good enough for probably 90% of the people who need to do some simple sound recording, editing, and mixing, and it has some unique useful features that are helpful even to professionals. Plus, it's open-source, so it's possible to customize it for specific needs.
I'm a huge fan of open source tools, but there's just no software out there to compete with the big boys. Audacity is great as a learning tool, but you'll never find it in a professional recording studio. Steinberg's Cubase and Nuendo, and Digi's Pro Tools, and Apple's Logic division are not worrying about the free competition yet.
There's a big difference: Audacity is free, and so there's no reason professional recording studios couldn't use Audacity in addition to everything else. If Audacity does just one thing better (or faster, or easier), then there's no reason not to keep it around.
And OK I'm not trolling here, but Audacity is just not that great. I tried using it to record a simple demo, and I just didn't find it useful. I'm glad its open source and it'll surely improve, but the simple free program that came with my Mac to record audio is better.
I don't think you've tried Audacity since version 1.0. Or maybe I forgot and the Mac sound recorder had support for 32-bit-float samples, on-the-fly resampling, and noise removal?
This post is from August 25th of 1998, more than five years ago. It's the first mention of the movies being made that I could find on Slashdot. No comments, but it's interesting to realize that tonight's awards ceremony has been the the culmination of a story we've all been following here for more than half a decade.
Ah yes, and I remember the first UF cartoon after the trailer was released: here - note that userfriendly.org discourages deep linking, but you can copy and paste the URL into a new browser window and then it should work.
Why no solution to remove dust
on
Mars Rovers Update
·
· Score: 3, Insightful
A lot of people are discussing ideas to remove dust from solar panels. Something people are forgetting is that there's a downside to having the mission last longer than originally expected: it costs more. JPL designed the rovers to last about 90 days, and NASA gave them enough money to pay the hundreds of engineers and scientists it takes to operate the rovers for 90 days each. They of course have the option of extending the mission for longer than 90 days, but the money to pay for that extension will come right out of NASA's Mars program, which means less money for future Mars missions (including Mars Reconaissance Orbiter 2005, which is already well under way and needs every penny it can get).
Sorry, but that can't be done: Python is a nice language, but it is not designed to be compiled as efficiently as C#.
While there's some truth to that, you might want to check out Psyco - a just-in-time compiler for Python.
By using run-time optimizations, it might be possible for code written in a high-level language like Python to actually run faster than C code. That's still a long ways away, though...
The article doesn't seem to address all of the different types of bugs, nor how to best address them. Anyone care to add to or refine this list?
1. Algorithmic bugs - you have a function with well-defined input and output, and it does the wrong thing (may include giving the wrong answer, looping forever, leaking memory, or taking too long to return). Can be avoided with a combination of code review, unit tests, and correctness proofs when possible. 2. Interface bugs - this includes validating input, both from the user and over the network or other ways in which your program gets input data. These bugs include buffer overruns, GUI bugs caused by an unanticipated sequence of clicks, etc. These bugs are mostly found by testing, but sometimes also with automatic code checkers or memory debuggers that highlight potential problems. 3. Bugs in the operating system or in sublibraries - any large project depends on large volumes of operating system code and usually lots of other libraries. These systems almost certainly have bugs or at the very least undocumented or inconsistent behavior. The only way to avoid this is to validate all OS responses and do lots of testing. 4. Cross-platform bugs - a program could work perfectly on one system, but not on another. Best way to address this is to abstract all of the parts of your program that are specific to the environment, but mostly this just requires lots of testing and porting. 5. Complexity bugs - bugs that start to appear when a program or part of a program gets too complicated, such that changing any one piece causes so many unintended side-effects that it becomes impossible to keep track of them. This is one of the few areas where good object-oriented design will probably help. 6. Poor specifications - these are not even necessarily bugs, just cases where a program doesn't behave as expected because the specifications were wrong or ambiguous. The way to avoid this is to make sure that the specifications are always clear. Resolve any potential ambiguities in the specs before finishing the code.
My overall feeling is that there are so many different types of bugs in a real-world programming project, and any one technique (like object-oriented design) only helps address one type of bug.
..each Recipient, upon receipt of the Subject Software, is requested to register with NASA by visiting the following website...
I doubt this statement satisfies the open-source definition. I am *certain* that it doesn't satisfy the Debian Free Software definition, because it fails both the "desert island" and the "chinese dissident" tests.
It's a nonbinding request. There are no consequences if you don't obey the request. I don't see how this is incompatible with the open-source definition. In fact this is common - I've seen a lot of software released under a BSD license plus a nonbinding request to please forward all changes to the original author as a courtesy.
For over 30 years NASA code was available through a program called COSMIC which was administered at the University of Georgia.
Since 1998 the code has been available through the Open Channel Foundation
http://www.openchannelfoundation.org/cosmic/
I work at JPL. Unfortunately, Open Channel Foundation seems to be taking advantage of the popularity of the word "open source" - Open Channel is not really all that open. Yes, all of the Cosmic software is there, but it's not all free. And you can't just click and download it; the process is more complicated.
The worst part is that I want to release some of the software I've written - particularly some machine learning code - but my only options are to license it to individual recipients (what I'm doing now) or release through Open Channel, which makes it almost impossible to find and a pain to download, and doesn't really encourage much feedback.
Apparently it is possible to release open-source code from JPL if you modify an existing GPL project. I'll have to see if I can do that in the future.
The overwhelming majority of programmers, engineers, and scientists at JPL would be more than happy to release all of their code to the public with no restrictions, or under a standard OSS license. Unfortunately the administration hasn't come around yet. This new NASA open source license is news to me, and I think it's great. Even if there are major problems with the license as it currently stands, it's a great effort on the part of NASA administrators and lawyers.
As someone who has done retail computer service since the early eighties, let me point out that MS-FUD is not an issue here. This is a real problem.
I have seen quite a few machines where windows wouldn't boot due to accidental file renaming, and quite a few from deliberate renaming through ignorance.
This would never happen in Mac OS X. If you try to rename a system file, it asks for your password, clearly showing that you shouldn't be doing this unless you know what you're doing.
When the problem is pointed out, the response has pretty much the same: "Why does it let me do it, then?" or "Why is it so easy to do if it's wrong?"
I've also seen systems where children have done dramatic file renaming, because it's easily within their grasp.
Guess what? Right-clicking is also easily within their grasp. No, I much prefer that you can rename something without needing to right-click, as on the Mac. It means that the interface is more discoverable. People learn how to rename _because_ they do it by accident. They never have to ask how because it's obvious - just click and wait a second, then type.
Granted, this is not a huge problem, but it is consistant. More common is the bulk movement of system files via drag & drop.
That's why in OS X you can Undo any operation in the Finder, including renaming, copying, moving files, etc.
From a technical standpoint, the double-click rename "feature" is actually a weak point in longterm system security/stability.
Again, OS X proves that this doesn't have to be the case if you implement it right.
My solution for friends and family that ask for technical support is simply that I will help them out if they have a Macintosh. Otherwise, there is no way I have the time to troubleshoot and support Windows, Linux or other Unix operating systems.
In other words, to paraphrase "I am no longer competent to administer or help out with anything more complicated than a toaster, as I haven't worked in the field in years. But rather than admit my own shortcomings, I'm going to blame my atrophied skillset and laziness on you and make you feel guilty for having chosen to run an operating system I am no longer familiar with. Furthermore, I'm going to take that guilt and leverage it into evangelizing the One and Only Computer System(tm) according to My Doctrine(tm): Apple."
Which would be fine, except for the blaming others, guilt trips, and blind evangelism.
I too encourage anyone and everyone who will listen to use something (anything!) other than Microsoft products, and actively encourage people to switch to FreeBSD, Linux, or Apple, but I do not refuse to help friends and family out when they're in a bind, regardless of what they use, and I certainly don't mask my own incompetence in blind evangelism, and make them feel somehow inadequate for my own failings.
But what if I'm just more familiar with Macs? Yes, I'm a clever guy, and given enough time, I could solve your Windows problems, but it's going to take me a lot longer than somebody else who's a Windows guru. On the other hand, I use Macs all day long, so if you have a Mac problem, I can probably solve it very quickly for you, or if not I'll at least be able to show you exactly what to do.
As everyone else is saying, this is just security by obscurity. That doesn't mean that you shouldn't use it, because it probably would help a lot in keeping out script kiddies and casual hackers. But the flip side, as always, is that you're giving yourself and your users a false sense of security when you pretend that measures like this will actually prevent motivated hackers from getting past it.
The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer. Once you can see the traffic to the host running this port knocking system, it would be easy to discover the pattern. In fact, port knocking is less secure than a lot of other nonstandard authentication mechanisms because you could figure out the secret simply by looking at packet headers (since they contain the port numbers).
The other problem I see with this system is that it requires users to either memorize the secret knock, or use a program that automatically knocks for them. Since most people have a hard time even remembering all of their usernames and passwords, you'd see a lot of people writing down the knock, sending it via email, or writing scripts to knock for them. Dozens of opportunities to a hacker, especially one skilled in social engineering, to figure out the knock.
That's a funny quote and all but I don't know if it's entirely true in this case. A lot of the cost involved was put towards getting the technology together and paying the people involved. Once one was built, the other one just required the same set of parts and a team to assemble and test it. No R&D costs were repeated.
While it's not exactly assembly line type savings, there is a reduced cost for building a duplicate of something that already has been built.
That's true, and FYI, they actually built three rovers, just in case there was an accident with one of them before launch.
What differentiates Itanium2 from any Xeon is not the register width, but is the combintion the revoluationary EPIC architecture
...that turns out not to scale as well as originally hoped...
and auto parallelizing compilers
...which don't exist yet.
IA64 can speed through tasks that deal with 32-bit numbers and 32-bit addresses with great efficiency, and it will beat a similarly clocked Xeon hands down running native compiled code.
Yeah, but that's not a fair comparison because you can get a 3.2 GHz Xeon for a third the price of a 1.5 GHz Itanium. Or you could get a 2.0 GHz Opteron for about half the price. Both are faster. Who cares if the Itanium is faster clock-for-clock if they can't get its clock speed very high?
Xeon + 64-bit registers is no threat to Itanium except in the minds of simpletons who look at the marketing bullets and say "gee, 64 sure is a big number!"
OK, now I realize this is just a troll. The truth is that both AMD's Opteron and IBM/Apple's G5 are blowing away the Itanium on almost all benchmark apps, and the few where Itanium is better, the Opteron, G5, and Xeon are all far better in price/performance ratio.
I think iTunes is pretty good too, but one of the things you rarely see mentioned here is that there's a huge gap in feature set between the Mac and Windows versions. No, it's not in the app or music libraries, it's in the support of players. The Mac version of iTunes supports any mp3 player capable of playing MP3 or AAC which is pretty much everybody if you don't want to play the music you bought at the iTMS (they're all AAC).
Huh?
You mean there are Mac users that have portable players other than iPods?
You mean iTunes for Mac actually supports these players? Are you sure?
The Windows version of iTunes is identical in functionality to the Mac version if you have an iPod. But it appears that iTunes Windows won't sync with anything other than iPods.
Why in the world would Apple want to support competing players for Windows users? It's a free product, it wouldn't be making them any money at all. Right now iTunes is free because Mac users are helping to pay for it by buying a Mac and buying Mac OS X, and Windows users are helping to pay for it by buying iPods.
So really, what everyone here is saying, is that it's OK to crack proprietary code ("code must be free"), steal copyrighted works ("music must be free") and get away with it. Aperently most of you still live at home (like DVD Jon) and don't directly have to pay bills, except for maybe your stash and some Dew now and then.
No, what we're saying is that it's legal to reverse-engineer hardware and software for the purposes of interoperability and exercising your fair-use rights. In other words, it's perfectly legal to crack the CSS encryption on DVDs so that you can watch the DVDs that you legally purchased on your Linux computer, which after all these years still has no commercial DVD playing software.
We also recognize that there's a big difference between stealing (depriving someone of a physical product they own) and copyright infringement (making a digital copy of something, which doesn't deprive the owner of their copy nor does it deprive the copyright holder of any revenue if you otherwise wouldn't have purchased it). We also recognize that morally there is a big difference between downloading a few MP3s off the Internet (just for fun, to try out new bands, for albums that are not being produced anymore - which is no more immoral than borrowing a book or a CD from a friend) and wholesale mass-copying (people who burn 'pirated' CDs and sell them in the streets).
Slashdot Mirror
From the wiki page: ...
Maybe it's just me, but where's the frickin' download link?
The Audacity homepage is http://audacity.sourceforge.net. There are nice, big, download links there.
The Audacity Wiki is a community-maintained site for organizing information and resources relating to Audacity. It's publicly editable, so if you want to put download links there, you're welcome to do so!
Still no support for plugins on Linux. What's with that?
We can't include support for VST plug-ins directly, because the VST SDK doesn't let you redistribute the source code.
However, Audacity does support LADSPA plug-ins on all platforms. On the Mac and Windows we provide a VST Enabler (a LADSPA/VST bridge) and on Linux there is at least one project that enables you to access VST plug-ins through LADSPA.
And in this you see one of the major problems I feel open source has today.
None of the programs you describe are trying to do something new and imaginative, their aim is simply to clone someone else as efficently as possible.
That's not entirely true. OpenOffice is a good example of this; it clones Microsoft Office way too much in my opinion. Yes, there are differences, and some more substantial ones in 1.1, but it's still very much a clone. Then again, that's probably the only way to get lots of people to switch away from Microsoft Office.
The Gimp is not a clone of Photoshop. Obviously it's not as powerful, but for non-professional users, it's just different. Does certain things in a different way. Sometimes easier - for example I think it's easier to work with transparency in the Gimp.
Audacity is not a clone of any audio editor. It has some superficial similarities to some other programs, but that's only because they have some similar capabilities. Audacity was designed from the beginning to be as intuitive and easy-to-use as possible, while making as many professional capabilities available as possible.
We need more OSS apps which aim to be good in their own right, not simply because they are "a free replacement for X".
That sounds good in theory, but it seems like more than half of the posts in this article are saying "Audacity is good, but it will never replace audio editor X until it has feature Y". And in half of the cases, Audacity already does have feature Y - it just implements it in a different way.
Dominic
Audacity Lead Developer
Well, just had a look at the "new" audacity. I don't find it so innovative ; indeed, I was expecting for many features which were not included here. Some are pretty simple ; for example, I would like the FFT filter to have a "log scale" option, which would make it much more interesting and usable.
This is available with the Equalizer effect. I agree, it's a little confusing. These effects will be merged in a future version.
Please add your other ideas to the Audacity Feature Requests page!
Dominic
Audacity Lead Developer
This program looks like it's off to a good start, but it's not gonna replace cooledit for me. Namely, it lacks a lot of basic plugins (ADSR, amplification envelopes, fade ins/outs that don't suck, spectrum analysis, etc). Hopefully, the VST enabler project will take care of most of this.
Audacity has built-in amplification envelopes with linear-dB interpolation - i.e. fades that don't suck. You can also use built-in or plug-in effects for other types of fades. It has lots of spectrum analysis, including a spectrogram display and a frequency plot window.
And Audacity does have VST support - but currently it's limited because the VST SDK does not let us distribute the source code to it, which means that we can't integrate it directly into Audacity. Right now quite a few VST effects plug-ins work, without their GUI, and hopefully soon we will have full VSTGUI support and support for more advanced VST plug-ins, too.
Dominic
Audacity Lead Developer
For me, Audacity 1.0 is just fine for what I do - digitizing tapes and records, simple home-studio recordings. What I always missed:
-fade in and out tools
Either use fade in/out effects or plug-ins, or use the built-in amplitude envelope editor - just click on the tool that looks like two triangles surrounding a control point.
-what you said
Audacity 1.2 displays the line showing the current playback/recording position
-and to be able to chose the soundcard, if you have more than 1 installed
That's always been there, in the preferences dialog.
There are already recording studios that use Sweep. I know that diversity is always good, but it doesn't look like Audacity gives anything that Sweep doesn't already, and has been doing for some time.
One huge difference is that Sweep only runs on Linux (and a few other Unix-like systems). Audacity runs natively on Linux, Windows, and Mac OS.
Also, last time I checked, Sweep is still an in-memory audio editor. Good luck trying to mix an entire CD-length album if you only have 256 MB of RAM. Audacity is disk-based and can do all of its processing in non-real-time, so you can edit and mix a large album with many tracks on a slow computer with only a little bit of RAM.
Sweep has a lot of neat features, though. They're both free, so if you use Linux, why not grab both, and use each where appropriate?
Dominic
Audacity Lead Developer
Does Audiocity [sic] really rank up there with Protools, reason and/or other expensive software apps that are used now??
Of course not. But it's free, it runs natively on 3+ platforms, it's good enough for probably 90% of the people who need to do some simple sound recording, editing, and mixing, and it has some unique useful features that are helpful even to professionals. Plus, it's open-source, so it's possible to customize it for specific needs.
Dominic
Audacity Lead Developer
I'm a huge fan of open source tools, but there's just no software out there to compete with the big boys. Audacity is great as a learning tool, but you'll never find it in a professional recording studio. Steinberg's Cubase and Nuendo, and Digi's Pro Tools, and Apple's Logic division are not worrying about the free competition yet.
There's a big difference: Audacity is free, and so there's no reason professional recording studios couldn't use Audacity in addition to everything else. If Audacity does just one thing better (or faster, or easier), then there's no reason not to keep it around.
And OK I'm not trolling here, but Audacity is just not that great. I tried using it to record a simple demo, and I just didn't find it useful. I'm glad its open source and it'll surely improve, but the simple free program that came with my Mac to record audio is better.
I don't think you've tried Audacity since version 1.0. Or maybe I forgot and the Mac sound recorder had support for 32-bit-float samples, on-the-fly resampling, and noise removal?
Dominic
Audacity Lead Developer
2004-2000 = ~ 2 years
To clarify, it has been two years since we last released a stable version of Audacity, version 1.0.
Dominic
Audacity Lead Developer
This post is from August 25th of 1998, more than five years ago. It's the first mention of the movies being made that I could find on Slashdot. No comments, but it's interesting to realize that tonight's awards ceremony has been the the culmination of a story we've all been following here for more than half a decade.
Ah yes, and I remember the first UF cartoon after the trailer was released: here - note that userfriendly.org discourages deep linking, but you can copy and paste the URL into a new browser window and then it should work.
A lot of people are discussing ideas to remove dust from solar panels. Something people are forgetting is that there's a downside to having the mission last longer than originally expected: it costs more. JPL designed the rovers to last about 90 days, and NASA gave them enough money to pay the hundreds of engineers and scientists it takes to operate the rovers for 90 days each. They of course have the option of extending the mission for longer than 90 days, but the money to pay for that extension will come right out of NASA's Mars program, which means less money for future Mars missions (including Mars Reconaissance Orbiter 2005, which is already well under way and needs every penny it can get).
Sorry, but that can't be done: Python is a nice language, but it is not designed to be compiled as efficiently as C#.
While there's some truth to that, you might want to check out Psyco - a just-in-time compiler for Python.
By using run-time optimizations, it might be possible for code written in a high-level language like Python to actually run faster than C code. That's still a long ways away, though...
The article doesn't seem to address all of the different types of bugs, nor how to best address them. Anyone care to add to or refine this list?
1. Algorithmic bugs - you have a function with well-defined input and output, and it does the wrong thing (may include giving the wrong answer, looping forever, leaking memory, or taking too long to return). Can be avoided with a combination of code review, unit tests, and correctness proofs when possible.
2. Interface bugs - this includes validating input, both from the user and over the network or other ways in which your program gets input data. These bugs include buffer overruns, GUI bugs caused by an unanticipated sequence of clicks, etc. These bugs are mostly found by testing, but sometimes also with automatic code checkers or memory debuggers that highlight potential problems.
3. Bugs in the operating system or in sublibraries - any large project depends on large volumes of operating system code and usually lots of other libraries. These systems almost certainly have bugs or at the very least undocumented or inconsistent behavior. The only way to avoid this is to validate all OS responses and do lots of testing.
4. Cross-platform bugs - a program could work perfectly on one system, but not on another. Best way to address this is to abstract all of the parts of your program that are specific to the environment, but mostly this just requires lots of testing and porting.
5. Complexity bugs - bugs that start to appear when a program or part of a program gets too complicated, such that changing any one piece causes so many unintended side-effects that it becomes impossible to keep track of them. This is one of the few areas where good object-oriented design will probably help.
6. Poor specifications - these are not even necessarily bugs, just cases where a program doesn't behave as expected because the specifications were wrong or ambiguous. The way to avoid this is to make sure that the specifications are always clear. Resolve any potential ambiguities in the specs before finishing the code.
My overall feeling is that there are so many different types of bugs in a real-world programming project, and any one technique (like object-oriented design) only helps address one type of bug.
Software, is requested to register with NASA by visiting the following
website...
I doubt this statement satisfies the open-source definition. I am *certain* that it doesn't satisfy the Debian Free Software definition, because it fails both the "desert island" and the "chinese dissident" tests.
It's a nonbinding request. There are no consequences if you don't obey the request. I don't see how this is incompatible with the open-source definition. In fact this is common - I've seen a lot of software released under a BSD license plus a nonbinding request to please forward all changes to the original author as a courtesy.
For over 30 years NASA code was available through a program called COSMIC which was administered at the University of Georgia.
Since 1998 the code has been available through the Open Channel Foundation
http://www.openchannelfoundation.org/cosmic/
I work at JPL. Unfortunately, Open Channel Foundation seems to be taking advantage of the popularity of the word "open source" - Open Channel is not really all that open. Yes, all of the Cosmic software is there, but it's not all free. And you can't just click and download it; the process is more complicated.
The worst part is that I want to release some of the software I've written - particularly some machine learning code - but my only options are to license it to individual recipients (what I'm doing now) or release through Open Channel, which makes it almost impossible to find and a pain to download, and doesn't really encourage much feedback.
Apparently it is possible to release open-source code from JPL if you modify an existing GPL project. I'll have to see if I can do that in the future.
The overwhelming majority of programmers, engineers, and scientists at JPL would be more than happy to release all of their code to the public with no restrictions, or under a standard OSS license. Unfortunately the administration hasn't come around yet. This new NASA open source license is news to me, and I think it's great. Even if there are major problems with the license as it currently stands, it's a great effort on the part of NASA administrators and lawyers.
As someone who has done retail computer service since the early eighties, let me point out that MS-FUD is not an issue here. This is a real problem.
I have seen quite a few machines where windows wouldn't boot due to accidental file renaming, and quite a few from deliberate renaming through ignorance.
This would never happen in Mac OS X. If you try to rename a system file, it asks for your password, clearly showing that you shouldn't be doing this unless you know what you're doing.
When the problem is pointed out, the response has pretty much the same: "Why does it let me do it, then?" or "Why is it so easy to do if it's wrong?"
I've also seen systems where children have done dramatic file renaming, because it's easily within their grasp.
Guess what? Right-clicking is also easily within their grasp. No, I much prefer that you can rename something without needing to right-click, as on the Mac. It means that the interface is more discoverable. People learn how to rename _because_ they do it by accident. They never have to ask how because it's obvious - just click and wait a second, then type.
Granted, this is not a huge problem, but it is consistant. More common is the bulk movement of system files via drag & drop.
That's why in OS X you can Undo any operation in the Finder, including renaming, copying, moving files, etc.
From a technical standpoint, the double-click rename "feature" is actually a weak point in longterm system security/stability.
Again, OS X proves that this doesn't have to be the case if you implement it right.
My solution for friends and family that ask for technical support is simply that I will help them out if they have a Macintosh. Otherwise, there is no way I have the time to troubleshoot and support Windows, Linux or other Unix operating systems.
In other words, to paraphrase "I am no longer competent to administer or help out with anything more complicated than a toaster, as I haven't worked in the field in years. But rather than admit my own shortcomings, I'm going to blame my atrophied skillset and laziness on you and make you feel guilty for having chosen to run an operating system I am no longer familiar with. Furthermore, I'm going to take that guilt and leverage it into evangelizing the One and Only Computer System(tm) according to My Doctrine(tm): Apple."
Which would be fine, except for the blaming others, guilt trips, and blind evangelism.
I too encourage anyone and everyone who will listen to use something (anything!) other than Microsoft products, and actively encourage people to switch to FreeBSD, Linux, or Apple, but I do not refuse to help friends and family out when they're in a bind, regardless of what they use, and I certainly don't mask my own incompetence in blind evangelism, and make them feel somehow inadequate for my own failings.
But what if I'm just more familiar with Macs? Yes, I'm a clever guy, and given enough time, I could solve your Windows problems, but it's going to take me a lot longer than somebody else who's a Windows guru. On the other hand, I use Macs all day long, so if you have a Mac problem, I can probably solve it very quickly for you, or if not I'll at least be able to show you exactly what to do.
As everyone else is saying, this is just security by obscurity. That doesn't mean that you shouldn't use it, because it probably would help a lot in keeping out script kiddies and casual hackers. But the flip side, as always, is that you're giving yourself and your users a false sense of security when you pretend that measures like this will actually prevent motivated hackers from getting past it.
The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer. Once you can see the traffic to the host running this port knocking system, it would be easy to discover the pattern. In fact, port knocking is less secure than a lot of other nonstandard authentication mechanisms because you could figure out the secret simply by looking at packet headers (since they contain the port numbers).
The other problem I see with this system is that it requires users to either memorize the secret knock, or use a program that automatically knocks for them. Since most people have a hard time even remembering all of their usernames and passwords, you'd see a lot of people writing down the knock, sending it via email, or writing scripts to knock for them. Dozens of opportunities to a hacker, especially one skilled in social engineering, to figure out the knock.
That's a funny quote and all but I don't know if it's entirely true in this case. A lot of the cost involved was put towards getting the technology together and paying the people involved. Once one was built, the other one just required the same set of parts and a team to assemble and test it. No R&D costs were repeated.
While it's not exactly assembly line type savings, there is a reduced cost for building a duplicate of something that already has been built.
That's true, and FYI, they actually built three rovers, just in case there was an accident with one of them before launch.
What differentiates Itanium2 from any Xeon is not the register width, but is the combintion the revoluationary EPIC architecture
...that turns out not to scale as well as originally hoped...
...which don't exist yet.
and auto parallelizing compilers
IA64 can speed through tasks that deal with 32-bit numbers and 32-bit addresses with great efficiency, and it will beat a similarly clocked Xeon hands down running native compiled code.
Yeah, but that's not a fair comparison because you can get a 3.2 GHz Xeon for a third the price of a 1.5 GHz Itanium. Or you could get a 2.0 GHz Opteron for about half the price. Both are faster. Who cares if the Itanium is faster clock-for-clock if they can't get its clock speed very high?
Xeon + 64-bit registers is no threat to Itanium except in the minds of simpletons who look at the marketing bullets and say "gee, 64 sure is a big number!"
OK, now I realize this is just a troll. The truth is that both AMD's Opteron and IBM/Apple's G5 are blowing away the Itanium on almost all benchmark apps, and the few where Itanium is better, the Opteron, G5, and Xeon are all far better in price/performance ratio.
After seeing that ad I searched for "hardrive" and found hundreds! Some are quite good deals.
Remember when the iPod came out just a couple years ago? First of all, it was a bit underwhelming--$500 for a 5 GB player.
Actually it was $399.
I think iTunes is pretty good too, but one of the things you rarely see mentioned here is that there's a huge gap in feature set between the Mac and Windows versions. No, it's not in the app or music libraries, it's in the support of players. The Mac version of iTunes supports any mp3 player capable of playing MP3 or AAC which is pretty much everybody if you don't want to play the music you bought at the iTMS (they're all AAC).
Huh?
You mean there are Mac users that have portable players other than iPods?
You mean iTunes for Mac actually supports these players? Are you sure?
The Windows version of iTunes is identical in functionality to the Mac version if you have an iPod. But it appears that iTunes Windows won't sync with anything other than iPods.
Why in the world would Apple want to support competing players for Windows users? It's a free product, it wouldn't be making them any money at all. Right now iTunes is free because Mac users are helping to pay for it by buying a Mac and buying Mac OS X, and Windows users are helping to pay for it by buying iPods.
So really, what everyone here is saying, is that it's OK to crack proprietary code ("code must be free"), steal copyrighted works ("music must be free") and get away with it. Aperently most of you still live at home (like DVD Jon) and don't directly have to pay bills, except for maybe your stash and some Dew now and then.
No, what we're saying is that it's legal to reverse-engineer hardware and software for the purposes of interoperability and exercising your fair-use rights. In other words, it's perfectly legal to crack the CSS encryption on DVDs so that you can watch the DVDs that you legally purchased on your Linux computer, which after all these years still has no commercial DVD playing software.
We also recognize that there's a big difference between stealing (depriving someone of a physical product they own) and copyright infringement (making a digital copy of something, which doesn't deprive the owner of their copy nor does it deprive the copyright holder of any revenue if you otherwise wouldn't have purchased it). We also recognize that morally there is a big difference between downloading a few MP3s off the Internet (just for fun, to try out new bands, for albums that are not being produced anymore - which is no more immoral than borrowing a book or a CD from a friend) and wholesale mass-copying (people who burn 'pirated' CDs and sell them in the streets).