"Many people on short-term missions are highly motivated individuals, very achievement-seeking. Sometimes these people can get very frustrated when their goals aren't accomplished right away," he says. For longer missions, astronauts - or, in Palinkas's research, members of polar missions - need to be prepared for changes of plan, contingencies, and the possibility that goals won't be achieved."
High tolerance to frustration? Being used to changes of plans, and goals that aren't achieved in time? Well... with these requirements, it's clear which people are perfect for the job: SOFTWARE DEVELOPERS!
Shouldn't be hard to find some who are used to not having sex for 30 months, too.
"All sampling is lossy" - no it isn't, see the sampling theorem (Nyquist/Shannon).
Assuming that the input signal is band limited, and the sampling frequency is at least twice as high as the highest frequency in the input signal, sampling is NOT lossy.
In practice, sound is not typically precisely band limited; however, human hearing is: To about 20kHz (for children/young people; I'm proud that I can still hear 16kHz alright after 15 years of going to techno clubs:)).
So in theory, a 40kHz sampling frequency would be enough. BUT... the input signals are not band limited, and in reality, there's no such thing as an ideal low-pass. Therefore, to compensate for non-ideal low-pass filters, we need a sampling frequency higher than 40kHz. 44.1kHz was chosen for CD, which is sufficient; for DAT and DVD, 48kHz was chosen, which is really perfect and we can't expect any improvement beyond that. For SACD & Co, 96kHz was chosen, but for marketing reasons, not technical. Anyone who has a clue about digital signal processing will agree that 96kHz sampling makes no sense, unless you are recording for a non-human audience (dogs, bats, aliens from outer space...).
Still, even if sampling is perfect, quantization never is. 16 bit quantization is sufficient for playback. The noise from the recording microphone will be substantially higher than the additional noise introduced by quantization. However, during repeated digital processing in the studio, quantization errors accumulate; therefore, in a studio/processing environment, choosing 24bit quantization makes perfect sense.
so what music did you listen to? I think The Orb would have done fine, e.g. the "morphine drip" remix of Little Fluffy Clouds (from the 'Live 93' album):-)
They don't even need to license it. Today, GPUs are more complex than standard x86 CPUs. So if nVidia can handle GPUs, they can handle CPUs. They have the tools, the know-how, and the engineers. Developing their own x86 CPU shouldn't be too hard for them.
if I wanted tabs/buttons to be shaded and round-edged, then I would have selected a GTK theme with these features.
But I haven't, and APPLICATIONS SHOULD RESPECT THAT!!!
Why does Firefox 2.0rc2 use its own look & feel for the tabs, instead of respecting the theme that is currently set in the desktop environment (like Firefox 1.X did)? The tabs look ugly and don't match other GTK apps at all.
Also, nuisances that have been present for quite a while still aren't taken care of. E.g. after doing a search via the search field, the field doesn't auto-clear itself - so you can't just do another search later by pressing the middle mouse button in the search field to paste a keyword. Instead, you have to clear the field manually.
1300 movies?! The average torrent site has more choice.
But what the movies/music industry hasn't understood: Most often, people pirate not because it's free, but because it's convenient and better (more choice, file formats used for piracy have wide hardware support, no DRM crap).
So why not make it better than what's available illegaly. It doesn't have to be free. Really. People will pay for it if it's good. But 1300 movies just isn't good enough, even as a start.
Ok, 350 TV series, that's good indeed. But somehow I doubt it's really 350 complete TV series, probably it's just 350 seasons, or maybe just 350 _episodes_.
I have spent quite an amount trying to "join the dots" before jumping to my conclusion. The primary accusation against you is that you have not released the complete source code of your work on FreeDB2. I have checked out the URLs you posted, and while there is some source code there, the code that is available is not even remotely sufficient for setting up a service similar to what you are offering on freedb2.org.
So my conclusion is that the accusations against you are indeed correct.
I'd be happy to be proven wrong by someone showing me the complete source code for setting up a freedb2-like service.
If you don't want people to think that YOU are the one who is the reason for FreeDB shutting down, then just RELEASE THE SOURCE CODE. Don't give us any "didn't have time to document/post" crap. You can still document it later on. For now, it will be sufficient if you just pack up the code you have to a tar.gz file, and post it on your site. It's just 5 minutes of work, and it will show the world that you are not the one responsible for the FreeDB disaster.
I think the argument "it's free, you can't expect much" just doesn't count nowadays. The Debian concept shouldn't be "it's inferior, but at least it's free".
Concerning the problem of having old-old-stable, old-stable, etc... WELL... right now, Woody is stable. Next week, it may become old-stable. No problem, right? Only when the next stable release after sarge comes out (who knows when... maybe 2008), THEN woody would become old-old-stable... by that time, security support could indeed be discontinued. But not in 12 months!
I can understand when cutting-edge distros who always have the latest package versions, like Gentoo or Ubuntu, don't provide long security support for old versions (actually, even Ubuntu provides security updates of old releases for one year after the new release came out!). But those who really want a rock-solid system, and go through all the pain of still using Woody because of that, deserve more than that.
Of course one could simply do a dist-upgrade. And yes, this is free and it's much less hassle to upgrade than with ANY other distro. But still, in a highly customized server that's running in production use, you can't just type apt-get dist-upgrade, and expect that everything works like before.
bye, Till
Only 12 months security support of old releases?
on
Debian Sarge Coming Soon
·
· Score: 5, Insightful
Hi,
only 12 months of security support for the old Debian release, after a new release has come out?
Isn't that a bit short? If Microsoft had stopped supporting Windows 2000 in 2002 (one year after Windows XP came out), everybody would have gone NUTS about it.
Considering that Debian "stable" is targeted at users who are very conservative about upgrades, Woody should be supported for at least a few more years. IMHO.
I didn't say that C# is perfect for everything, and all future Linux apps should be written in C#. What I focused on is portable GUI development.
If you're developing a GUI app, it is helpful if the development environment you're using has good support for GUI development.
I'm certainly not going to get into a general C# vs Java discussion. Or in a C++ vs Java/C# discussion. Although I personally try to avoid C++ whenever it's possible.
you're making my sound stupid by quoting incomplete sentences:-)
Here's what I wrote: "But, as far as typical DESKTOP applications are concerned, Java has failed to gain popularity both with users and developers"
If you disagree - tell me: How many of the typical DESKTOP applications that you use (web browser, word processor, email client,...) are written in Java?
Concerning your other points: They are valid; but I was mainly talking about commercial software, not Open Source. If you develop software for a customer, the customer wants it fast. And RAD can help you do that.
Hi,
yes, that's what I'm saying. When you're developing software you plan to sell, your aim is to deliver what people want and what people are gonna buy. And what people want is not Java apps. What the majority of (ignorant, Windows-using) people want is a.exe file they can double-click on, and that looks and behaves like those other Windows apps they're using.
Be realistic. How many of the typical desktop applications you're using (web browser, email client, office suite, graphics program...) are written in Java? Anyone still remember Corel Office?
Of course that is sad. There's nothing wrong with Java. It would have been great if Java had succeeded for desktop apps like it has succeeded in other areas. We'd all be using apps written in Java, there would be much less security issues, more people would have moved away from Windows, etc. Great fantasy. Unfortunately, it didn't work out that way.
Maybe if Sun had - from the beginning on - made Java use native widgets (Windows, or GTK or QT on UNIX) instead of a proprietary interface, or some "emulation" that somewhat looks like the OS' widgets, it would have worked out. But that's really a different issue.
Concerning the ease of building graphical apps - it has advantages and disadvantages. The disadvantage is that it allows total idiots to make apps that LOOK professional. Especially when VB is involved.
The advantage is that it simply saves time, even for experienced programmers.
And in.NET, using the GUI builder is quite transparent; the generated code is well-structured. No comparison to the code mess generated by the VC++ 6 GUI builder, for example. I can't really compare it to VB though; the last BASIC dialect I used was AppleSoft BASIC in the 1980s;-)
bye,
Till
I can perfectly understand that many hate Mono simply because of the fact that it was Microsoft who designed.NET. That is a valid argument; however, it must be considered that Mono is something that, in the future, is really required for the Linux/UNIX world.
I suppose that those bashing Mono have never actually worked with C#. Personally, I'm really an anti-MS guy, but at work I was basically "forced" to use C#, and I must admit, it absolutely rocks. It is simply a much more productive language than C or C++, especially for GUI development. When you get a specific task, you're simply much more likely to get it done and get it stable within a given time in C#. The biggest productivity gain (besides the syntax candy, like foreach loops) comes from the garbage collection. Sure, other languages like Java have that, too. But, as far as typical DESKTOP applications are concerned, Java has failed to gain popularity both with users and developers (I suppose the major reason is that Sun took way too long to finally allow Java GUI apps to integrate themselves seemlessly in the desktop by adapting a "native" look & feel; but that's another issue).
Linux apps have done a great job in the past years in getting competitive to their Windows counterparts. So, if Linux wants to stay competitive with Windows in the future as well, there must be a similarly productive language for GUI development on Linux. Standard C/C++ with GTK+ and QT can certainly compete with the horrors of MFC easily. But, in my opinion, not necessarily with the combination of C#/Windows.Forms, as far as speed of development is concerned.
Also, if we want to see more commercial applications to run on Linux, there must be a way to easily develop portable GUI apps. Imagine you're the boss of a smaller software company. You develop Windows apps, your customers all use Windows (welcome to the real world!). Maybe 3% of your customers consider switching to Linux. And now you're starting that new software project that must be finished within a certain time. What are you gonna do? Buy QT, and tell your developers to start learning it? Use GTK, with all related problems on the Windows platform, and tell your developers to start learning it? Nope, that's not what the typical boss is gonna decide. He'll let the developers use what they're used to, M$ visual studio, where they can click together the GUI. He'll tell the 3% of the customers that Linux isn't supported.
And this is exactly what may change with Mono!
And talking about the patent issue: Giving up on Mono because of potential patent issues would mean giving up on the patent issue itself. Mono could be the best "bad" example how software patents support a monopoly and limit interoperability. The fight against software patents isn't over yet. At least not in Old Europe.
Slashdot Mirror
Hi,
from the article:
"Many people on short-term missions are highly motivated individuals, very achievement-seeking. Sometimes these people can get very frustrated when their goals aren't accomplished right away," he says. For longer missions, astronauts - or, in Palinkas's research, members of polar missions - need to be prepared for changes of plan, contingencies, and the possibility that goals won't be achieved."
High tolerance to frustration? Being used to changes of plans, and goals that aren't achieved in time?
Well... with these requirements, it's clear which people are perfect for the job: SOFTWARE DEVELOPERS!
Shouldn't be hard to find some who are used to not having sex for 30 months, too.
bye,
Till
"All sampling is lossy" - no it isn't, see the sampling theorem (Nyquist/Shannon).
:)).
Assuming that the input signal is band limited, and the sampling frequency is at least twice as high as the highest frequency in the input signal, sampling is NOT lossy.
In practice, sound is not typically precisely band limited; however, human hearing is: To about 20kHz (for children/young people; I'm proud that I can still hear 16kHz alright after 15 years of going to techno clubs
So in theory, a 40kHz sampling frequency would be enough. BUT... the input signals are not band limited, and in reality, there's no such thing as an ideal low-pass. Therefore, to compensate for non-ideal low-pass filters, we need a sampling frequency higher than 40kHz. 44.1kHz was chosen for CD, which is sufficient; for DAT and DVD, 48kHz was chosen, which is really perfect and we can't expect any improvement beyond that. For SACD & Co, 96kHz was chosen, but for marketing reasons, not technical. Anyone who has a clue about digital signal processing will agree that 96kHz sampling makes no sense, unless you are recording for a non-human audience (dogs, bats, aliens from outer space...).
Still, even if sampling is perfect, quantization never is. 16 bit quantization is sufficient for playback. The noise from the recording microphone will be substantially higher than the additional noise introduced by quantization. However, during repeated digital processing in the studio, quantization errors accumulate; therefore, in a studio/processing environment, choosing 24bit quantization makes perfect sense.
Hi,
:-)
so what music did you listen to? I think The Orb would have done fine, e.g. the "morphine drip" remix of Little Fluffy Clouds (from the 'Live 93' album)
bye,
Till
Hamid: What's that? Rambo: It's blue light. Hamid: What does it do? Rambo: It turns blue. - from Rambo III
They don't even need to license it. Today, GPUs are more complex than standard x86 CPUs. So if nVidia can handle GPUs, they can handle CPUs. They have the tools, the know-how, and the engineers. Developing their own x86 CPU shouldn't be too hard for them.
Hi,
if I wanted tabs/buttons to be shaded and round-edged, then I would have selected a GTK theme with these features.
But I haven't, and APPLICATIONS SHOULD RESPECT THAT!!!
Why does Firefox 2.0rc2 use its own look & feel for the tabs, instead of respecting the theme that is currently set in the desktop environment (like Firefox 1.X did)? The tabs look ugly and don't match other GTK apps at all.
Also, nuisances that have been present for quite a while still aren't taken care of. E.g. after doing a search via the search field, the field doesn't auto-clear itself - so you can't just do another search later by pressing the middle mouse button in the search field to paste a keyword. Instead, you have to clear the field manually.
bye,
Till
Hi,
sweet! First planet named after an IRC network!
Long live EFnet!
bye,
Till
Hi,
1300 movies?! The average torrent site has more choice.
But what the movies/music industry hasn't understood: Most often, people pirate not because it's free, but because it's convenient and better (more choice, file formats used for piracy have wide hardware support, no DRM crap).
So why not make it better than what's available illegaly. It doesn't have to be free. Really. People will pay for it if it's good. But 1300 movies just isn't good enough, even as a start.
Ok, 350 TV series, that's good indeed. But somehow I doubt it's really 350 complete TV series, probably it's just 350 seasons, or maybe just 350 _episodes_.
bye,
Tillmann
I have spent quite an amount trying to "join the dots" before jumping to my conclusion. The primary accusation against you is that you have not released the complete source code of your work on FreeDB2. I have checked out the URLs you posted, and while there is some source code there, the code that is available is not even remotely sufficient for setting up a service similar to what you are offering on freedb2.org.
So my conclusion is that the accusations against you are indeed correct. I'd be happy to be proven wrong by someone showing me the complete source code for setting up a freedb2-like service.
If you don't want people to think that YOU are the one who is the reason for FreeDB shutting down, then just RELEASE THE SOURCE CODE. Don't give us any "didn't have time to document/post" crap. You can still document it later on. For now, it will be sufficient if you just pack up the code you have to a tar.gz file, and post it on your site. It's just 5 minutes of work, and it will show the world that you are not the one responsible for the FreeDB disaster.
bye,
Tillmann
Hi, did they pick a name for the animal yet? Or are they going to sell naming rights on eBay? bye, Till
Hi,
I think the argument "it's free, you can't expect much" just doesn't count nowadays. The Debian concept shouldn't be "it's inferior, but at least it's free".
Concerning the problem of having old-old-stable, old-stable, etc... WELL... right now, Woody is stable. Next week, it may become old-stable. No problem, right? Only when the next stable release after sarge comes out (who knows when... maybe 2008), THEN woody would become old-old-stable... by that time, security support could indeed be discontinued. But not in 12 months!
I can understand when cutting-edge distros who always have the latest package versions, like Gentoo or Ubuntu, don't provide long security support for old versions (actually, even Ubuntu provides security updates of old releases for one year after the new release came out!). But those who really want a rock-solid system, and go through all the pain of still using Woody because of that, deserve more than that.
Of course one could simply do a dist-upgrade. And yes, this is free and it's much less hassle to upgrade than with ANY other distro. But still, in a highly customized server that's running in production use, you can't just type apt-get dist-upgrade, and expect that everything works like before.
bye,
Till
Hi,
only 12 months of security support for the old Debian release, after a new release has come out?
Isn't that a bit short? If Microsoft had stopped supporting Windows 2000 in 2002 (one year after Windows XP came out), everybody would have gone NUTS about it.
Considering that Debian "stable" is targeted at users who are very conservative about upgrades, Woody should be supported for at least a few more years. IMHO.
bye,
Till
Hi,
I didn't say that C# is perfect for everything, and all future Linux apps should be written in C#. What I focused on is portable GUI development.
If you're developing a GUI app, it is helpful if the development environment you're using has good support for GUI development.
I'm certainly not going to get into a general C# vs Java discussion. Or in a C++ vs Java/C# discussion. Although I personally try to avoid C++ whenever it's possible.
bye,
Till
Hi,
:-)
...) are written in Java?
you're making my sound stupid by quoting incomplete sentences
Here's what I wrote:
"But, as far as typical DESKTOP applications are concerned, Java has failed to gain popularity both with users and developers"
If you disagree - tell me: How many of the typical DESKTOP applications that you use (web browser, word processor, email client,
Concerning your other points: They are valid; but I was mainly talking about commercial software, not Open Source. If you develop software for a customer, the customer wants it fast. And RAD can help you do that.
bye,
Till
Hi, yes, that's what I'm saying. When you're developing software you plan to sell, your aim is to deliver what people want and what people are gonna buy. And what people want is not Java apps. What the majority of (ignorant, Windows-using) people want is a .exe file they can double-click on, and that looks and behaves like those other Windows apps they're using.
Be realistic. How many of the typical desktop applications you're using (web browser, email client, office suite, graphics program...) are written in Java? Anyone still remember Corel Office?
Of course that is sad. There's nothing wrong with Java. It would have been great if Java had succeeded for desktop apps like it has succeeded in other areas. We'd all be using apps written in Java, there would be much less security issues, more people would have moved away from Windows, etc. Great fantasy. Unfortunately, it didn't work out that way.
Maybe if Sun had - from the beginning on - made Java use native widgets (Windows, or GTK or QT on UNIX) instead of a proprietary interface, or some "emulation" that somewhat looks like the OS' widgets, it would have worked out. But that's really a different issue.
Concerning the ease of building graphical apps - it has advantages and disadvantages. The disadvantage is that it allows total idiots to make apps that LOOK professional. Especially when VB is involved.
The advantage is that it simply saves time, even for experienced programmers.
And in .NET, using the GUI builder is quite transparent; the generated code is well-structured. No comparison to the code mess generated by the VC++ 6 GUI builder, for example. I can't really compare it to VB though; the last BASIC dialect I used was AppleSoft BASIC in the 1980s ;-)
bye,
Till
Hi,
.NET. That is a valid argument; however, it must be considered that Mono is something that, in the future, is really required for the Linux/UNIX world.
I can perfectly understand that many hate Mono simply because of the fact that it was Microsoft who designed
I suppose that those bashing Mono have never actually worked with C#. Personally, I'm really an anti-MS guy, but at work I was basically "forced" to use C#, and I must admit, it absolutely rocks. It is simply a much more productive language than C or C++, especially for GUI development. When you get a specific task, you're simply much more likely to get it done and get it stable within a given time in C#. The biggest productivity gain (besides the syntax candy, like foreach loops) comes from the garbage collection. Sure, other languages like Java have that, too. But, as far as typical DESKTOP applications are concerned, Java has failed to gain popularity both with users and developers (I suppose the major reason is that Sun took way too long to finally allow Java GUI apps to integrate themselves seemlessly in the desktop by adapting a "native" look & feel; but that's another issue).
Linux apps have done a great job in the past years in getting competitive to their Windows counterparts. So, if Linux wants to stay competitive with Windows in the future as well, there must be a similarly productive language for GUI development on Linux. Standard C/C++ with GTK+ and QT can certainly compete with the horrors of MFC easily. But, in my opinion, not necessarily with the combination of C#/Windows.Forms, as far as speed of development is concerned.
Also, if we want to see more commercial applications to run on Linux, there must be a way to easily develop portable GUI apps. Imagine you're the boss of a smaller software company. You develop Windows apps, your customers all use Windows (welcome to the real world!). Maybe 3% of your customers consider switching to Linux. And now you're starting that new software project that must be finished within a certain time. What are you gonna do? Buy QT, and tell your developers to start learning it? Use GTK, with all related problems on the Windows platform, and tell your developers to start learning it? Nope, that's not what the typical boss is gonna decide. He'll let the developers use what they're used to, M$ visual studio, where they can click together the GUI. He'll tell the 3% of the customers that Linux isn't supported.
And this is exactly what may change with Mono!
And talking about the patent issue: Giving up on Mono because of potential patent issues would mean giving up on the patent issue itself. Mono could be the best "bad" example how software patents support a monopoly and limit interoperability. The fight against software patents isn't over yet. At least not in Old Europe.
bye,
Till