The audible range is 20-20000 Hz (or 20Hz - 20kHz -- easy to remember). Of course, everyone's hearing is different. Some can hear more of a range, and some can hear less (I can hear from about 30Hz to 19kHz), but that's the approximate range.
Notice that xiph.org is a.org and not.com domain. Then notice that their web page states that they are a non-profit corporation, and that there is a link for donating to them. Re-read the writup in this article and see that it also has a link to their donation page.
Yeah, I guess "easy" is a relative term. I usually associate "easy" with "practical", which I suppose disqualifies me from doing work in theoretical computer science.;-) (I am doing theoretical CS, but not complexity theory.)
Yes. Nobody is going to come up with an n^1000000000000000000 algorithm, though. Chances are, an algorithm with that kind of running time would be so complicated, nobody would understand it.
To me, having PRIMES in P means that there is more hope of being able to do it efficiently. If it was shown to be NP complete, I would have much less hope. In this case, for example, although the running time is O((log n)^12), which isn't too impressive, the researchers say that they did not fully optimize the algorithm, as they were only interested is showing it was possible.
P is a pretty nice group to deal with, because it happens to be fairly robust between different models of computation. (i.e. P doesn't change if you go from Turing machines, to random access machines, etc.) But there are always researchers interested in getting things down to linear, quadratic, cubic, etc. time. I don't think anybody's going to let this paper be the final word on the complexity of PRIMES. But this is a significant step in finding an efficient algorithm for it.
Is it quadratic in the magnitude of the number, or quadratic in the bit size of the number? i.e. if I wanted to test if 907 is prime, would it be c*907^2 time, or c*log(907)^2?
Nope. You can have huge constants, or huge exponents, or both. P only describes (somewhat loosely) how much harder the problem becomes as the size of the input grows. But if the problem already takes an impossibly long time with an input size of two, you aint goin very far.
In addition, it is possible to know that a problem is in P, but not have an algorithm for it. (e.g. Robertson and Seymour's huge graph minor theorem, a series of about 20 papers which you probably don't want to read (I don't).)
Or, if you want to build as a normal user, put "fakeroot" before each make-kpkg (i.e. "fakeroot make-kpkg..."). If you're building as a normal user, obviously you won't have write access to/usr/src, so you'll have to tell make-kpkg where to find the module sources: set MODULE_LOC to the base directory of the module sources.
I believe that the Fast Save issue was solved a long time ago. Equations, I don't know; I don't use them in Word. Pagination and line breaks, not even Microsoft does it properly. Even between the same version of Word, on two different machines, it can be different. But everyone should know that if you need pagination and line breaks to be the same, use PDF or PostScript instead of Word. Word was never meant to get those things right.
The C++ ABI changed. So only C++ programs will break. C stuff should work fine. It's not really a matter of shipping with two compilers -- C++ programs compiled with one compiler will not be able to use C++ libraries compiled with another.
security.debian.org doesn't say anything about testing, woody's security archive didn't appear until some short time before it was released, and my own experience is being corrected by Wichert (from the Debian security team, at least I think it was Wichert, but it was definitely someone who knew the security process) when I made a post on a Debian list stating that I thought that testing would get security fixes. Anyways, we'll see when the next security announcement comes, if it contains fixes for sarge. There should be one coming up soon -- a bug was found in PHP4. At least there is a sarge directory on the security server, so maybe things have changed since Wichert's comment.
So, really, a faster release process isn't strictly required.
A faster release process is required if we expect newbies (Debian newbies -- not Linux newbies) to install Debian and have a fairly up-to-date set of packages. Although testing is fairly stable, it is still possible to run into the odd packaging problem, which newbies could have a hard time figuring out. Plus the fact that testing has a serious security problem (security updates won't show up until about two weeks after they are packaged since they have to go through unstable first). But that's just my opinion.
What else would be in Debian's future?
Hurd and *BSD ports. (Hopefully both will be in sarge, though I'm not too confident about Hurd being there on time.) There are also rumors of a Win32 port, although there doesn't seem to be much work being done on that front. Then there's work on using Progeny's Debian installer as a user-friendly alternative/replacement to Debian's default installer. And they'll probably add a few more architectures to the mix too.
My mom has trouble setting the clock in her car radio. Do you think she would be able to fix the radiator if it leaks? Replace the brake pads? And we're letting her drive? Give me a break.
You don't have to build kernels or install RPMs to use Linux. My mom doesn't install software or drivers in Windows anyways.
What are you talking about? Note that Yahoo! by default searches its categorized directory first. If you click on the "Web Page Matches" link, you get a "Powered by Google" search.
Interesting. This page suggests that putting NiMH in a freezer prolongs their life. I guess your link is referring to the effect of cold on batteries in use, while mine is referring to batteries not in use.
Slashdot Mirror
The audible range is 20-20000 Hz (or 20Hz - 20kHz -- easy to remember). Of course, everyone's hearing is different. Some can hear more of a range, and some can hear less (I can hear from about 30Hz to 19kHz), but that's the approximate range.
And don't forget that "English" (as are all languages, religions, and some other things) is always capitalized.
Notice that xiph.org is a .org and not .com domain. Then notice that their web page states that they are a non-profit corporation, and that there is a link for donating to them. Re-read the writup in this article and see that it also has a link to their donation page.
Yeah, I guess "easy" is a relative term. I usually associate "easy" with "practical", which I suppose disqualifies me from doing work in theoretical computer science. ;-) (I am doing theoretical CS, but not complexity theory.)
Yes. Nobody is going to come up with an n^1000000000000000000 algorithm, though. Chances are, an algorithm with that kind of running time would be so complicated, nobody would understand it.
To me, having PRIMES in P means that there is more hope of being able to do it efficiently. If it was shown to be NP complete, I would have much less hope. In this case, for example, although the running time is O((log n)^12), which isn't too impressive, the researchers say that they did not fully optimize the algorithm, as they were only interested is showing it was possible.
P is a pretty nice group to deal with, because it happens to be fairly robust between different models of computation. (i.e. P doesn't change if you go from Turing machines, to random access machines, etc.) But there are always researchers interested in getting things down to linear, quadratic, cubic, etc. time. I don't think anybody's going to let this paper be the final word on the complexity of PRIMES. But this is a significant step in finding an efficient algorithm for it.
Is it quadratic in the magnitude of the number, or quadratic in the bit size of the number? i.e. if I wanted to test if 907 is prime, would it be c*907^2 time, or c*log(907)^2?
Nope. You can have huge constants, or huge exponents, or both. P only describes (somewhat loosely) how much harder the problem becomes as the size of the input grows. But if the problem already takes an impossibly long time with an input size of two, you aint goin very far.
In addition, it is possible to know that a problem is in P, but not have an algorithm for it. (e.g. Robertson and Seymour's huge graph minor theorem, a series of about 20 papers which you probably don't want to read (I don't).)
(And please always capitalize Turing. Nobel too.)
> What if you're using Grub and don't have lilo installed? Does it still try to do lilo anyway?..
You can set it up to run update-grub instead.
They're both part of the AGNULA (A GNU/Linux Audio distribution) project. (DeMuDi's home page mentions the AGNULA project as well.)
You don't have to worry about forgetting to make/install the modules, and running LILO. It does that all for you.
Or, if you want to build as a normal user, put "fakeroot" before each make-kpkg (i.e. "fakeroot make-kpkg ..."). If you're building as a normal user, obviously you won't have write access to /usr/src, so you'll have to tell make-kpkg where to find the module sources: set MODULE_LOC to the base directory of the module sources.
I believe that the Fast Save issue was solved a long time ago. Equations, I don't know; I don't use them in Word. Pagination and line breaks, not even Microsoft does it properly. Even between the same version of Word, on two different machines, it can be different. But everyone should know that if you need pagination and line breaks to be the same, use PDF or PostScript instead of Word. Word was never meant to get those things right.
Sure it will. Smaller files -> faster download times.
The C++ ABI changed. So only C++ programs will break. C stuff should work fine. It's not really a matter of shipping with two compilers -- C++ programs compiled with one compiler will not be able to use C++ libraries compiled with another.
security.debian.org doesn't say anything about testing, woody's security archive didn't appear until some short time before it was released, and my own experience is being corrected by Wichert (from the Debian security team, at least I think it was Wichert, but it was definitely someone who knew the security process) when I made a post on a Debian list stating that I thought that testing would get security fixes. Anyways, we'll see when the next security announcement comes, if it contains fixes for sarge. There should be one coming up soon -- a bug was found in PHP4. At least there is a sarge directory on the security server, so maybe things have changed since Wichert's comment.
A faster release process is required if we expect newbies (Debian newbies -- not Linux newbies) to install Debian and have a fairly up-to-date set of packages. Although testing is fairly stable, it is still possible to run into the odd packaging problem, which newbies could have a hard time figuring out. Plus the fact that testing has a serious security problem (security updates won't show up until about two weeks after they are packaged since they have to go through unstable first). But that's just my opinion.
Hurd and *BSD ports. (Hopefully both will be in sarge, though I'm not too confident about Hurd being there on time.) There are also rumors of a Win32 port, although there doesn't seem to be much work being done on that front. Then there's work on using Progeny's Debian installer as a user-friendly alternative/replacement to Debian's default installer. And they'll probably add a few more architectures to the mix too.
Well today is (Release Manager) aj's mother's birthday, and I'm afraid she has priority over you. Sorry 'bout that.
Corel Linux is based on Debian.
You don't have to build kernels or install RPMs to use Linux. My mom doesn't install software or drivers in Windows anyways.
I'm surprised noone as modded you as "troll" yet.
("cite", not "site") It's also meaningless unless we have the numbers for gasoline as well to compare against.
grammar. Not grammer.
What are you talking about? Note that Yahoo! by default searches its categorized directory first. If you click on the "Web Page Matches" link, you get a "Powered by Google" search.
Interesting. This page suggests that putting NiMH in a freezer prolongs their life. I guess your link is referring to the effect of cold on batteries in use, while mine is referring to batteries not in use.