Real men use phase change coolers as defined by Drexler and Henson in US Patent #4,759,404 also briefly discussed in Section 11.5 of Nanosystems . That is because the heat capacity of solids going to liquids is higher than that of liquids going to gases.
Nah, real men doesn't like these newfangled nanotech thingies. Real men like it simple and robust. A suitably manly solution is to just drop the computer into liquid nitrogen.
I don't know why you absolutely want your kids to take apart your computer and eat the contents. I'm sure you have other toxic things in your house too...
(Ever wondered what you use in your dishwasher? Or what some of the stuff in your garage does?)
"Not very toxic at all" is quite comfortable for me. Of course, I also want to know how it reacts in case of fire, if it destroys my floor if it ever leaks out, if it's environmentally friendly, etc.. But according to the MSDS I shouldn't need to worry about any of those...
This makes them picked on by the rest of Linux world for "outdated, ancient software", but thanks to their policies I can run Debian Testing on production servers
Whoa there... You shouldn't run testing on servers. Testing is a middle-ground between stable and unstable. Unstable gets all the latest and greatest fixes. Stable has a security team. Testing has none of the above.
If there is a security problem, the security team will take care of it in stable, and because unstable is the development branch, it will be fixed there as well. Testing will only get the fixes after the fix has been lying dormant for a few weeks in unstable...
If you are running production servers, please use a distribution where someone will look after security problems. Most main-stream distributions do that, but Debian testing is one of the few that don't!
You wrote: You better tell that to the guys who wrote the scheme spec (R5RS). They certainly seem to think that Scheme is a dialect of Lisp. To quote from R5RS:
Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman.
Ok then. But obviously you already know what they mean because you also say:
Scheme and Common Lisp are both dialects of Lisp. They're not the same language, but if you grok one, you can pretty easily figure out the other.
Which is true, of course. For some reason, all languages using lots of silly parens are "lisp dialects", no matter how different they are. And for some other reason we don't call all languages with infix syntax Fortran-dialects.
And if you can read some scheme (or common lisp), you can probably read some common lisp (or scheme) too. (Just as with Pascal and C++). But be aware: the semantic gap between how things are typically done in each of those languages, is huge.
Huh, brainfuck? It's even nicer than most assemblers I know. If you wan't to talk difficult, you've got to do better than that... Did you even look at the link I provided for Malbolge...
Let's be accurate. Common LISP is to Scheme as C++ is to, perhaps, C - both dialects of the same basic language, but one far more feature-rich that the other
No. This is false. And it doesn't really matter that you or many other people believe it to be true. It's still false.
Scheme is a block-structured language modeled on Algol. Common Lisp is a natural evolution of LISP 1.5. As part of the evolution, sure, some features from Scheme have been sneaked back into Common Lisp, but they are really very different languages.
LISP is to Scheme as BASIC is to Microsoft BASIC. One is a dialect of the other.
No, it isn't. Scheme and Common Lisp are no more dialects than Pascal or C++ is. And I really mean what I say. C++ is an evolution of C, which itself is an evolution of B. Something similar can be said of Common Lisp.
Pascal is an ivory-tower language written to prove a point, that later, with various extensions, almost got useful, and were actually used for real programming. Something similar can be said of Scheme.
And they are certainly not dialects. They are far too different.
Scheme has tons in common with Common LISP.
Pascal also has tons in common with C++. I.e. they are both block-structured imperative languages.
Sure Scheme has tons in common with Common Lisp. But there are also tons of differences, and many of these differences are important! Such as scheme being block-structered, and Common Lisp not being block-structured.
If you try to look a bit further than superficial syntactic issues, you will find that the languages are quite different.
It's the same story as with Java and Javascript. People without a clue believe them to be similar. People with a clue know they aren't.
Re:This is not a troll, but a query...
on
Practical Common Lisp
·
· Score: 2, Informative
Could someone proficient in LISP give me three cogent reasons to learn the language?
Lisp is to scheme, as,uhmm..., C++ is to Pascal. Apart from the parenthesis-heavy syntax, they have very little in common.
It's the hardest language to write for IMHO just cause it's out of ordinary.
Well, then you haven't looked very far. The hardest language language to write for is probably Malbolge.
But there are plenty of more mainstream languages that are harder to write for than lisp. As a matter of fact, most mainstream languages are harder to write for than lisp. It just doesn't seem that way to you, because you grew up using different languages, and have not been interested enough to put at least some effort into learning it.
So while lisp seems hard to you, it's certainly not particulary hard for e.g. someone who doesn't already know how to program in some other language.
There was a story of a hacker stole one of the A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing paranthesis. That should sum up how nasty the language is.
First, what makes you think this story is true. I hereby present the following story as true, there once was a hacker that stole another A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing braces. That should sum up how nasty C is.
Just give them a sheet with the commands on like ctrl+f = forward , and they will pick it up quickly enough as the basics are fairly logical.
Now, why would any user need to know that? It's not like keyboards doesn't have arrow keys on them. Alright, it's happened to me on some weird occasions running emacs on a terminal through a telnet session, or something like that, but in that case, backspace would also bring up help, making the system completely useless for new users anyway.
The useful commands an emacs user would need to learn are: C-x C-f, C-x C-s, C-x s, C-x w, C-x k, C-x b, C-x C-b, C-x k, C-x 2, C-x 0, C-x 1, and C-x C-c. On the other hand, all of these commands are available through the menu. So, in fact, for a complete beginner, there are no useful commands to memorize. Ok, there is one: whenever you get into trouble, type C-g a few times.
So if you want a completely user-friendly system, replace emacs with an editor that doesn't require you to type C-g:-)
From your example of compiling the kernel; imagine if file A depends on file B. You have to deal with file B first, parallelism can't help.
Absolutely. Some tasks can't be parallelized. If you want a newborn baby, you still have to wait 9 months, no matter how many women you can get;-)
But the majority of the time in compiling the kernel is taken up by compiling, not "make depend", and not linking. If you have 100 processors, this step will take almost 1% of the time it otherwise would.
(Well, maybe you can pull some fancy tricks with header files and the like in this case, but you see my point).
Not too unlikely. Maybe it even would be worthwile. But it's also likely to just be a problem with C (and C++).
On a practical level, as most of the software I have now doesn't take advantage of parallelism, I'm going to need new versions all round - probably involving significant cost - a multi-core processor won't provide instant gratification like a "faster" one would.
It would be a practical advantage for multitasking. IMHO, it might even be considered an advantage that most apps aren't multithreaded, because then you are guaranteed that they will never hog more than one CPU/core (remember, we are still talking about two cores at the consumer-level, and 4-16 in the server market). Having even a few CPU/cores going unused shouldn't be a too big problem, since they will probably idle at a reduced clock-frequency instead of consuming power and generating heat (unless Intel/AMD are completely braindead).
When we start getting hundreds or thousands of processors, apps will definitely need to start taking advantage of them, though... Otherwise we would waste a lot of potential resources. But that is still a long time away. And when it happens, it's not too unlikely that the software that would benefit from it have catched up. AFAIK, that's already happened. The kind of apps that really need lots of compute-power (servers), are usually already parallelized.
So much so that Intel and AMD have had to resort to flogging multi-core chips, rather than actual faster chips.
And it's about time too. I don't want my single-CPU system to slow down interactive performance to a crawl, just because I'm doing a few CPU-intensive things in the background. How many things do you do now, that actually requires a faster processor instead of more of them?
Ok, there are a few problems of theoretical interest, and even fewer of practical interest, that can't easily be parallelized. But the majority of work I do on a computer, would benefit just as well from just stuffing it with a few more CPUs. Such as compiling the linux kernel while recoding DVD's and burning them, and serve some web-pages, while interactively make music with software synths and effects.
Even if it's just one task you are interested in solving as fast as possible, in most cases it's possible to parallelize it. Otherwise scientists and large corporations wouldn't be interested in building clusters and supercomputers anymore. More processors are useful!
It's a major pain to try and parallelize existing algorithms, and for many it won't be possible at all. Not to mention the huge bulk of existing software that operates in a strictly linear fasion.
Ok, name one un-parallelizable algorithm that you are actually interested in getting faster. Theoretical problems doesn't count. Let's face it, most computer stuff is about moving bits and bytes around. It doesn't involve fancy algorithms.
Most stuff that computers are too slow at today, is slow because it involves heaps of data, not because it uses fancy algorithms. Processing heaps of data can easily be parallelized. Solving tricky problems can't, but tricky problems are usually of exponential complexity, meaning that even an exponential growth in the speed of computers, still only give us a linear gain.
How would you feel if you went to buy a top of the range Ferrari, only to be told that "well, it only does 100mph, but it does have two engines"?
Bad, but then again, I'm not the kind of guy that buys ferraris. I'm the kind of guy that looks at the price of a Ferrari, and realizes that for that price, I can get myself a brand new Hyundai every second year for the rest of my life, and still have some money to spare on a yacht, a cabin in the mountains, a health-plan for the entire family, and a night out every week.
Shouldn't it be called Moore's Theory since a Law is proven without a doubt to be fact?
In theory of science, a theory is a hypothesis that has been been strengthened through many experiments, and never been falsified. The concept of law doesn't exist in the theory of science. It's just an unfortunate fact of history that some well-established simple-to-state theories have been known as "laws".
In everyday language, a law is something drafted by legislators, and used in courts. A theory is either (a:) a rough guess, or (b:) something that scientists come up with to explain things that would be hard to understand without them.
Thus, yes, perhaps Moore's law should be called Moore's theory, since theory meets both everyday language standards and scientific language standards better. But that isn't restricted to Moore's law. E.g. Newton's laws should also be called Newton's theories if you follow this argument.
On the other hand, it's hard to change things that works. When someone speaks of Newton's laws or Moore's law, the listener know exactly which law(s) the speaker intended. If you keep renaming stuff, it hinders understanding. So, in response to your question, I would say NO.
Enough of the linguistic perspective. What you probably wanted to say, was that Moore's law is not a scientific theory we can put the same faith in, as e.g. Newton's laws. That could be true. If that's the case, then it would be better to rename Moore's law to something like e.g. Moore's observation.
1st of all, Since nVidia (or ATI, or VIA) made the card, I'm pretty sure they know best how the hardware works and therefore they should know how to make the drivers.
Absolutely, that's why we all run an operating system made by Intel engineers
2nd, I'd be scared of having some serious issues with OSS drivers. For the same reasons talked about above.
Again I agree. I much prefer binary rpms of drivers hooking into a vendor-built kernel. I have never had any trouble with making them work. On the other hand, the drivers included with the stock linux kernel always gives me trouble.
Lately, I'm having issues with my RAID. Specifically, closed source drivers for my RAID card that only support Red Hat 9. So I've decided to Ebay the card, and try to figure out how to turn 4 SATA drives into a software driven RAID 5 setup. Yes, I know I'll lose all the data, and I'm not worried about it. Finding a 4 port (or more) SATA controller card, that's well supported under Linux, has been difficult. Everyone wants to slap on their own RAID chip and charge you another 100$ for the pleasure.
But can't you just use your raid card as a SATA card, and ignore the raid functionality? Why do you absolutely need it to be non-RAID? I'm sorry, but I'm having real trouble understanding what's the difficulty here...
If they created a.sex domain it would make porn sights much easier to block.
No. That is wishful thinking.
If they created a.sex domain, it is possible that some porn site would use it. But certainly not every porn site. Because porn sites, just like everyone else, are not interested in getting blocked. They want to reach the widest audience possible.
Now, you might try to argue that porn sites should be required by law to have a.sex top-level domain. But this is patently stupid. First, you have to define what constitutes a porn site. Nudity can't be it, since there are plenty of valid reasons to show naked people (medical, educational, artistic, etc...). Now, hard-core porn might be easier to define, but that leaves you with the problem of still offending a lot of people, while similarly blocking a few sites of medical, educational, artistic, etc,... interest.
Secondly, not every web-site contains either all porn or not porn. You may have a web-page that contains one or a few naked images of e.g. Tera Patrick (because you are a fan of her), although the majority of the content is about e.g. computer programming. Should the site have to live under the.sex TLD because of that?
It seems to me that adding a.sex TLD would be no worse and no better than todays relatively arbitrary filtering programs, and that makes adding it relatively pointless. You might still argue that adding it is a good idea, but then the same argument can be used to add almost any other TLD, such as.food,.programming,.comic,.film,.bank,.shop,.circus, or.jew.
Well, I was joking about it being easy to understand.
But befunge is easy to understand. Anyone with even rudimentary understanding of it, is able to mock up an interpreter. It's slightly harder to program, though. And granted, it can become very hard to understand someone elses program.
Fair Use is a uniquely American concept, although there are countries who use similar concepts.
Probably true. In Norway we have
right to make a limited number of copies for private use (assuming the work to be copied has been made public). This does not cover computer programs.
right to limited copying for use in education or religious service (this means it's ok for a school to make copies of out of print books), but the copyright holder has the right to get some royalties anyway
right to sell your legal copy to others.
right to lend your copy to others (but not lease). This does not cover computer programs.
right to display, show, or perform (as in theatre, musical work, etc) your copy to others for educational/religious purposes
right to quote from a public work when it's reasonable and in context (i.e. not a quote book)
and some other rights that usually involve royalties
All of these rights are fairly specific, and will when combined mean something not entirely distinct from the american concept of "fair use". But they all have different paragraphs in "åndsverksloven" (law of intellectual works).
It is not very unlikely that some of these rights will be more limited in the future, as the laws were written at a time when copy-machines or CD/DVD-burners were fairly uncommon.
Yeah, yeah. Nvidia is binary crappiness. ATI is just as bad. So where can one buy a decent graphics card that linux supports (not one that "supports linux")?
So it'd be more like this:
* Stable
* Current (formally known as unstable)
* Development (formally known as testing)
No! The parent was right.
Originally, there were only stable and unstable. Testing was added in between stable and unstable in order to give some extra quality checks so they could release stable more often.
The effect was probably the opposite. Instead of being a testing ground for the next stable release, testing ended up being another intermediary step packages had to go through before they were declared stable. And since any bugs in testing would only be fixed in unstable, the end result was that nothing new would ever end up in stable.
Testing was and is a mistake. For it to work as intended, it should only exist for a month or so before each new stable release, and in this brief period, people should actually care to fix bugs in testing. After the new stable release, testing should go away, and everything should happen in unstable
Instead we have a situation with a testing release that seemingly forever blocks anything from ever reaching stable, because nobody fixes bugs there.
From the user perspective, it's also confusing. Many people are afraid of running unstable, and prefers testing, assuming the packages there have at least a little bit more quality assurance. That is a false belief. Testing has no security team. If there are bugs there, they will be fixed in unstable (usually very fast), and then take a few weeks to propagate down to testing. So security-wise, testing is the worst of both worlds.
The only assurance testing gives you, is slightly fewer completely broken packages. But anyone that actually have tried running unstable, knows that this is very rarely a real problem. Unstable is still "stabler" than most other distros.
While i haven't done much research, a little casual testing suggests that opensource JREs run a lot more java software than mono runs.net software.
Not unlikely. But mono isn't just targetting running.NET software. It's targeting running mono software:-) And there seems to be quite a lot of goodies in the work!
My "shoot from the hip" guess would be that your ocaml program is not efficient because it's not running the same algorithm. The Haskell program turns out not so slow, because Haskell is lazy, and in this particular case it's a big win.
That doesn't mean that ocaml is slow. It means that dynamic programming in a functional programming style in an eager programming language requires a lot of care, or perhaps should even be avoided. A result that wouldn't surprise me the slightest.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
I don't mind pissing away RAM, I'm willing to spend 200MB if they can just do it faster, maybe through aggressive caching?
If you eat a lot of RAM, it will take some time to fill that RAM with interesting stuff, process it, and get even more interesting stuff out of it. And even now, gcc will happily eat 200MB for "modern C++" templatized source code.
Slashdot Mirror
Nah, real men doesn't like these newfangled nanotech thingies. Real men like it simple and robust. A suitably manly solution is to just drop the computer into liquid nitrogen.
(Ever wondered what you use in your dishwasher? Or what some of the stuff in your garage does?)
"Not very toxic at all" is quite comfortable for me. Of course, I also want to know how it reacts in case of fire, if it destroys my floor if it ever leaks out, if it's environmentally friendly, etc.. But according to the MSDS I shouldn't need to worry about any of those...
Whoa there... You shouldn't run testing on servers. Testing is a middle-ground between stable and unstable. Unstable gets all the latest and greatest fixes. Stable has a security team. Testing has none of the above.
If there is a security problem, the security team will take care of it in stable, and because unstable is the development branch, it will be fixed there as well. Testing will only get the fixes after the fix has been lying dormant for a few weeks in unstable...
If you are running production servers, please use a distribution where someone will look after security problems. Most main-stream distributions do that, but Debian testing is one of the few that don't!
Ok then. But obviously you already know what they mean because you also say:
Which is true, of course. For some reason, all languages using lots of silly parens are "lisp dialects", no matter how different they are. And for some other reason we don't call all languages with infix syntax Fortran-dialects.
And if you can read some scheme (or common lisp), you can probably read some common lisp (or scheme) too. (Just as with Pascal and C++). But be aware: the semantic gap between how things are typically done in each of those languages, is huge.
Huh, brainfuck? It's even nicer than most assemblers I know. If you wan't to talk difficult, you've got to do better than that... Did you even look at the link I provided for Malbolge...
Enjoy.
Old hat...
No. This is false. And it doesn't really matter that you or many other people believe it to be true. It's still false.
Scheme is a block-structured language modeled on Algol. Common Lisp is a natural evolution of LISP 1.5. As part of the evolution, sure, some features from Scheme have been sneaked back into Common Lisp, but they are really very different languages.
LISP is to Scheme as BASIC is to Microsoft BASIC. One is a dialect of the other.
No, it isn't. Scheme and Common Lisp are no more dialects than Pascal or C++ is. And I really mean what I say. C++ is an evolution of C, which itself is an evolution of B. Something similar can be said of Common Lisp.
Pascal is an ivory-tower language written to prove a point, that later, with various extensions, almost got useful, and were actually used for real programming. Something similar can be said of Scheme.
And they are certainly not dialects. They are far too different.
Scheme has tons in common with Common LISP.
Pascal also has tons in common with C++. I.e. they are both block-structured imperative languages.
Sure Scheme has tons in common with Common Lisp. But there are also tons of differences, and many of these differences are important! Such as scheme being block-structered, and Common Lisp not being block-structured.
If you try to look a bit further than superficial syntactic issues, you will find that the languages are quite different.
It's the same story as with Java and Javascript. People without a clue believe them to be similar. People with a clue know they aren't.
Try here
Lisp is to scheme, as ,uhmm..., C++ is to Pascal. Apart from the parenthesis-heavy syntax, they have very little in common.
It's the hardest language to write for IMHO just cause it's out of ordinary.
Well, then you haven't looked very far. The hardest language language to write for is probably Malbolge.
But there are plenty of more mainstream languages that are harder to write for than lisp. As a matter of fact, most mainstream languages are harder to write for than lisp. It just doesn't seem that way to you, because you grew up using different languages, and have not been interested enough to put at least some effort into learning it.
So while lisp seems hard to you, it's certainly not particulary hard for e.g. someone who doesn't already know how to program in some other language.
There was a story of a hacker stole one of the A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing paranthesis. That should sum up how nasty the language is.
First, what makes you think this story is true. I hereby present the following story as true, there once was a hacker that stole another A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing braces. That should sum up how nasty C is.
Secondly, bad code can be written in any language. Just like the code at the International Obfuscated C Code Contest sums up how nasty C is.
(PS: I like both C and Lisp! And a lot of other languages...)
Now, why would any user need to know that? It's not like keyboards doesn't have arrow keys on them. Alright, it's happened to me on some weird occasions running emacs on a terminal through a telnet session, or something like that, but in that case, backspace would also bring up help, making the system completely useless for new users anyway.
The useful commands an emacs user would need to learn are: C-x C-f, C-x C-s, C-x s, C-x w, C-x k, C-x b, C-x C-b, C-x k, C-x 2, C-x 0, C-x 1, and C-x C-c. On the other hand, all of these commands are available through the menu. So, in fact, for a complete beginner, there are no useful commands to memorize. Ok, there is one: whenever you get into trouble, type C-g a few times.
So if you want a completely user-friendly system, replace emacs with an editor that doesn't require you to type C-g :-)
Absolutely. Some tasks can't be parallelized. If you want a newborn baby, you still have to wait 9 months, no matter how many women you can get ;-)
But the majority of the time in compiling the kernel is taken up by compiling, not "make depend", and not linking. If you have 100 processors, this step will take almost 1% of the time it otherwise would.
(Well, maybe you can pull some fancy tricks with header files and the like in this case, but you see my point).
Not too unlikely. Maybe it even would be worthwile. But it's also likely to just be a problem with C (and C++).
On a practical level, as most of the software I have now doesn't take advantage of parallelism, I'm going to need new versions all round - probably involving significant cost - a multi-core processor won't provide instant gratification like a "faster" one would.
It would be a practical advantage for multitasking. IMHO, it might even be considered an advantage that most apps aren't multithreaded, because then you are guaranteed that they will never hog more than one CPU/core (remember, we are still talking about two cores at the consumer-level, and 4-16 in the server market). Having even a few CPU/cores going unused shouldn't be a too big problem, since they will probably idle at a reduced clock-frequency instead of consuming power and generating heat (unless Intel/AMD are completely braindead).
When we start getting hundreds or thousands of processors, apps will definitely need to start taking advantage of them, though... Otherwise we would waste a lot of potential resources. But that is still a long time away. And when it happens, it's not too unlikely that the software that would benefit from it have catched up. AFAIK, that's already happened. The kind of apps that really need lots of compute-power (servers), are usually already parallelized.
And it's about time too. I don't want my single-CPU system to slow down interactive performance to a crawl, just because I'm doing a few CPU-intensive things in the background. How many things do you do now, that actually requires a faster processor instead of more of them?
Ok, there are a few problems of theoretical interest, and even fewer of practical interest, that can't easily be parallelized. But the majority of work I do on a computer, would benefit just as well from just stuffing it with a few more CPUs. Such as compiling the linux kernel while recoding DVD's and burning them, and serve some web-pages, while interactively make music with software synths and effects.
Even if it's just one task you are interested in solving as fast as possible, in most cases it's possible to parallelize it. Otherwise scientists and large corporations wouldn't be interested in building clusters and supercomputers anymore. More processors are useful!
It's a major pain to try and parallelize existing algorithms, and for many it won't be possible at all. Not to mention the huge bulk of existing software that operates in a strictly linear fasion.
Ok, name one un-parallelizable algorithm that you are actually interested in getting faster. Theoretical problems doesn't count. Let's face it, most computer stuff is about moving bits and bytes around. It doesn't involve fancy algorithms.
Most stuff that computers are too slow at today, is slow because it involves heaps of data, not because it uses fancy algorithms. Processing heaps of data can easily be parallelized. Solving tricky problems can't, but tricky problems are usually of exponential complexity, meaning that even an exponential growth in the speed of computers, still only give us a linear gain.
How would you feel if you went to buy a top of the range Ferrari, only to be told that "well, it only does 100mph, but it does have two engines"?
Bad, but then again, I'm not the kind of guy that buys ferraris. I'm the kind of guy that looks at the price of a Ferrari, and realizes that for that price, I can get myself a brand new Hyundai every second year for the rest of my life, and still have some money to spare on a yacht, a cabin in the mountains, a health-plan for the entire family, and a night out every week.
In theory of science, a theory is a hypothesis that has been been strengthened through many experiments, and never been falsified. The concept of law doesn't exist in the theory of science. It's just an unfortunate fact of history that some well-established simple-to-state theories have been known as "laws".
In everyday language, a law is something drafted by legislators, and used in courts. A theory is either (a:) a rough guess, or (b:) something that scientists come up with to explain things that would be hard to understand without them.
Thus, yes, perhaps Moore's law should be called Moore's theory, since theory meets both everyday language standards and scientific language standards better. But that isn't restricted to Moore's law. E.g. Newton's laws should also be called Newton's theories if you follow this argument.
On the other hand, it's hard to change things that works. When someone speaks of Newton's laws or Moore's law, the listener know exactly which law(s) the speaker intended. If you keep renaming stuff, it hinders understanding. So, in response to your question, I would say NO.
Enough of the linguistic perspective. What you probably wanted to say, was that Moore's law is not a scientific theory we can put the same faith in, as e.g. Newton's laws. That could be true. If that's the case, then it would be better to rename Moore's law to something like e.g. Moore's observation.
Absolutely, that's why we all run an operating system made by Intel engineers
2nd, I'd be scared of having some serious issues with OSS drivers. For the same reasons talked about above.
Again I agree. I much prefer binary rpms of drivers hooking into a vendor-built kernel. I have never had any trouble with making them work. On the other hand, the drivers included with the stock linux kernel always gives me trouble.
But can't you just use your raid card as a SATA card, and ignore the raid functionality? Why do you absolutely need it to be non-RAID? I'm sorry, but I'm having real trouble understanding what's the difficulty here...
Sounds like you should just whip up a web-site with some pdf-files. Not a perfect solution, but certainly the cheapest...
No. That is wishful thinking.
If they created a .sex domain, it is possible that some porn site would use it. But certainly not every porn site. Because porn sites, just like everyone else, are not interested in getting blocked. They want to reach the widest audience possible.
Now, you might try to argue that porn sites should be required by law to have a .sex top-level domain. But this is patently stupid. First, you have to define what constitutes a porn site. Nudity can't be it, since there are plenty of valid reasons to show naked people (medical, educational, artistic, etc...). Now, hard-core porn might be easier to define, but that leaves you with the problem of still offending a lot of people, while similarly blocking a few sites of medical, educational, artistic, etc, ... interest.
Secondly, not every web-site contains either all porn or not porn. You may have a web-page that contains one or a few naked images of e.g. Tera Patrick (because you are a fan of her), although the majority of the content is about e.g. computer programming. Should the site have to live under the .sex TLD because of that?
It seems to me that adding a .sex TLD would be no worse and no better than todays relatively arbitrary filtering programs, and that makes adding it relatively pointless. You might still argue that adding it is a good idea, but then the same argument can be used to add almost any other TLD, such as .food, .programming, .comic, .film, .bank, .shop, .circus, or .jew.
But befunge is easy to understand. Anyone with even rudimentary understanding of it, is able to mock up an interpreter. It's slightly harder to program, though. And granted, it can become very hard to understand someone elses program.
Probably true. In Norway we have
All of these rights are fairly specific, and will when combined mean something not entirely distinct from the american concept of "fair use". But they all have different paragraphs in "åndsverksloven" (law of intellectual works).
It is not very unlikely that some of these rights will be more limited in the future, as the laws were written at a time when copy-machines or CD/DVD-burners were fairly uncommon.
We can apply emergency law to the concept of copyright violations? Sounds only natural to me. Or did I misunderstand something?
(I'm happy to be of any help later too :-)
And preferably a PCI Express board too...
* Stable
* Current (formally known as unstable)
* Development (formally known as testing)
No! The parent was right.
Originally, there were only stable and unstable. Testing was added in between stable and unstable in order to give some extra quality checks so they could release stable more often.
The effect was probably the opposite. Instead of being a testing ground for the next stable release, testing ended up being another intermediary step packages had to go through before they were declared stable. And since any bugs in testing would only be fixed in unstable, the end result was that nothing new would ever end up in stable.
Testing was and is a mistake. For it to work as intended, it should only exist for a month or so before each new stable release, and in this brief period, people should actually care to fix bugs in testing. After the new stable release, testing should go away, and everything should happen in unstable
Instead we have a situation with a testing release that seemingly forever blocks anything from ever reaching stable, because nobody fixes bugs there.
From the user perspective, it's also confusing. Many people are afraid of running unstable, and prefers testing, assuming the packages there have at least a little bit more quality assurance. That is a false belief. Testing has no security team. If there are bugs there, they will be fixed in unstable (usually very fast), and then take a few weeks to propagate down to testing. So security-wise, testing is the worst of both worlds.
The only assurance testing gives you, is slightly fewer completely broken packages. But anyone that actually have tried running unstable, knows that this is very rarely a real problem. Unstable is still "stabler" than most other distros.
Not unlikely. But mono isn't just targetting running .NET software. It's targeting running mono software :-) And there seems to be quite a lot of goodies in the work!
That doesn't mean that ocaml is slow. It means that dynamic programming in a functional programming style in an eager programming language requires a lot of care, or perhaps should even be avoided. A result that wouldn't surprise me the slightest.
If you eat a lot of RAM, it will take some time to fill that RAM with interesting stuff, process it, and get even more interesting stuff out of it. And even now, gcc will happily eat 200MB for "modern C++" templatized source code.
Aggressive caching? How about ccache?