If, without collision-protect, I emerge package A and then unmerge package B, how do I know it didn't take some of A's files with it?
That shouldn't be possible. When unmerging B it should notice that the mtime on a package A file is different, and as a result it shouldn't delete it.
In fact, when you upgrade a package it installs the new version before removing the old version. Since 99% of the files are going to overlap, nobody would have a working system if this wasn't the case. By looking at mtimes, when the old version is cleaned any files that were overwritten by the new version are left intact.
Don't get me wrong - portage features should just work, and it is important that at least those doing QA not just stick to the run-as-root flags.
Sure it is - it is just as possible to verify as it is to verify that Verisign's root cert is valid.
CA Cert's certificate is fairly well attested to in general, and can be downloaded from a variety of places. They just haven't ponied up huge wads of cash to get into most browsers' list of trusted root certs.
There is a war brewing on the mozilla bugzilla about this very topic...
The ebuild would instruct you to clear your queue, stop Postfix, and then do the update. If you didn't do this, it broke.
The problem is that if you just did an emerge -uD world, and postfix wasn't the first thing on the list, you probably didn't see the warning before you blasted through the installation process. Likewise, if it wasn't hte last item you probably never saw any warnings at the end.
Most people don't emerge one program at a time. It would be nice if the notes were collected and printed at the end...
Uh, you can just leave the earth on its axis, thank you. I think the component of the field that is perpendicular to the equator is plenty large for your purposes.
So, anybody have a few hundred thousand miles of copper cable handy? That should fit on the space shuttle with no problems.
Plus, if you just plug in a few billion petaohms of resistors, you can even stop the Earth's rotation, or at least drain its magnetic field.
You probably don't need to correct for efficiency - just make them mirrors instead of solar cells and just blast the solar sail with direct solar energy. I imagine that would do a good job of heating up the paint.
Still, it is probably easier to build a 200MW microwave transmitter on earth than a 60MW one in space. And I don't think microwaves are actually attenuated all that much.
Of course, in WW1 we had opposing forces just sitting at stalemates for months - so if a spy sneaks in a night and taps a line it gives good intel for a while.
In Desert Storm, troops moved across half the country in two days. By the time you'd tap a line both ends of it would be blown up. And while you could have tapped some lines near the border or some really long ones that passed through unobserved territory inland, it would be difficult to tap many lines simply because the lines were so far apart. In WW1 you could probably see the people you were shooting at, and a brave guy could probably crawl across no-man's land at night. In Iraq the sides were hundreds of miles apart, and you'd need a helicopter to get in, and those aren't always stealthy. (Again, if you have 100 miles of telephone cable with nobody watching the middle part, that would be easy to tap, but if you have a bunch of bunkers separated by 100 yards, you're not going to land a chopper within a mile of it.)
My guess is that most mail servers that receive several million emails all trying to guess the answer to a single CAPTCHA will probably just deep-six the sender and send an abuse complaint to their ISP automatically.
The whole reason UNIX cracking works is because you can do it without talking to the server that you're trying to crack.
Now I do the download/upload thing. It works better.
Seriously - why do we bother with these fancy integrated webbrowsers that have all kinds of bloat and security holes. All you need is wget to fetch pages, and an HTML viewer without networking capability to render them. Is it really that hard to copy a link destination URL and paste it into a shell?
In my case, downloading/uploading was worth $10 of hard-earned-money. I wish I didn't have to spend it, but I did. If most people didn't feel the same way Quicken wouldn't be flying off the shelves...
So is a BASIC interpreter. Should we conclude that an interpreted BASIC program runs with the same performance as something written in C?
Sure, Java has JIT, profiling and optimization, etc. It also has a whole new set of class libraries, etc, which have to go into RAM. Load time is significantly slower than something compiled using C. In general, run time is also a little slower, but I'll admit that this is probably application-dependant.
For that matter, you have to take every other holy text across the globe on the same faith, then, to be fair.
Obviously.
I'm not saying that religious books should not be questioned. I'm just saying that if a book is making a historical claim that on the 5th of Feb 1498 Joe Smith in London built a functioning microwave oven, the basis for criticizing the text should be documented evidence that the book was written in modern times, not an assumption that nobody could have built a microwave oven in 1498. Otherwise what is the point of writing down what happens?
The whole point of documenting events is so that people in the future will know what happened. That isn't accomplished if the people in the future just say "well, I don't think that happened, so it must be made up."
Or think of it another way - science must be falsifyable. Let's start with the hypothesis that there is no such thing as prophesy. The null of that is that there is such a thing (and presumably it has happened, although that isn't strictly necessary). How would you prove that prophesy occurred? Simple - scan historical documents for evidence of detailed predictions of future events. That is hardly possible if the dates of authorship for those documents were assigned purely on the assumption that there is no such thing as prophesy...
The earliest Mark would have been written was about 70 AD, since there is an indication in the text that he knew about the destruction of the Temple.
Are you referring to an indication that Mark knew about the destruction of the temple, or that somebody quoted in the text (such as Jesus) knew about it?
Since the whole premise of the text is that Jesus is God, it is hardly unreasonable to assign a date prior to AD70 for the authoring of the text.
Now, if there is an archeaological reason to think that it was written later, that is one thing. But if the only reason is that it is assumed that Jesus couldn't possibly know the future and consequently it had to be made up later, then that seems rather bold.
When analyzing the gospels as historical documents, the origin of the documents is clearly open to debate. However, since the main reason that they're worth studying is the impact they've had on history, it probably doesn't make sense to start with the presupposition that they're completely made up...
It's written in Java...(performance is just fine, folks).
Sure, whatever:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15405 freenet 30 15 537m 216m 42m S 2.7 43.5 0:03.68 java 15209 freenet 30 15 537m 216m 42m R 1.3 43.5 0:42.78 java 15067 freenet 30 15 537m 216m 42m S 0.3 43.5 0:26.33 java
Also, you don't have to rely on your Linux distribution to figure out how to compile the damned thing.
The whole point of a linux distro is to let it figure out how to compile/install something. I don't want a mess of self-built applications in/opt that I need to try to keep up to date...
It's written in Java, so it runs on Windows, Linux, and UNIX
Assuming that somebody has taken the time to bother writing a working JVM for your platform. Last time I checked Athlon64 users were out-of-luck unless they're running in 32-bit land (as my example above is).
Seriously, what is wrong with just writing something in C?
I admire the java concept - however the JVM and java applications in general seem to just devour memory. CPU performance is generally fine, but when I wake up my computer and it takes 30 seconds to display the xlock window, you can tell that there is a memory issue...
What is the point in reconciling your accounts if you use information the bank gives you?
Fair enough.
However, online transaction download is good-enough for most people. Since the transactions are downloaded only a few days after you made them, you'll be fairly likely to spot discrepencies (sure, not a dollar or two, but if you get a mystery charge from a store you've never visited you're gonna give the bank a call).
Also - in most checking account cases, I'm the one putting the transactions into Quicken, and then Quicken will point out if there is a discrepency when the same transaction shows up on download.
For things like credit cards, most people don't bother to reconcile anyway. So, by using transaction downloading, you at least get a record of all your transactions, and the ability to categorize them - which is essential for budgetting.
In an ideal world, you don't use an ATM card, credit card, check, cash from your wallet, or make a promise to a friend without writing into a register first. Most people don't live in that world. Transaction downloading is the next-best-thing...
Anybody who takes money for a service, and doesn't perform that service, is probably liable for at least a pro-prated fee refund.
My ISP had technical problems that put me offline for a day. They immediately sent out emails and even phone calls to all their cusomters to let them know that they can expect a credit on their next bill as a result.
Reputable companies know that stepping up to the plate when they mess up buys customer loyalty.
1) is CPU-bound rather than interconnect-bound or disk-bound or memory-bound
Actually, Moore's law will probably help out with memory access speed. Also, if you're interconnect-bound Moore's law will allow you to keep total CPU power constant while reducing the number of CPUs, and consequently the number of interconnects.
2) will take 3 years+ with current technology / budget, and
I'll definitely agree there... Moore's law isn't THAT fast...
I do and it is free. However, it is much nicer to just enter a transaction and have it uploaded to the bank, than to enter a transaction in your software, and then enter it again online.
Part of the problem is that as for-profit enterprises Quicken and MS Money can spend a lot more on bank marketing. They can get their foot in the door with their proprietary standards much more quickly. Neither is going to want to make it easy for a FOSS package to play-ball...
I've tried this and kmymoney. They are getting there, but they're not close enough for me.
The last time I tried (probably six months ago), the budgeting features were not good, online downloading and uploading of transactions looked to be incompatible with my bank, and reporting was not as versitile. The transaction registers themselves worked just fine, though.
It is also difficult to just experiement with the online features since it is your bank, and if it is working with quicken already do you want to mess with possibly getting the online service in some strange state? Financial software really only works well if all your transactions are in one place, so nobody would want to cut-over unless they had a fairly high degree of confidence that the FOSS alternatives are ready for prime-time.
I ended up buying quicken 2K4 for about $5-10 mail-order. If you buy a one-year-old version it isn't nearly as much of a ripoff.
Suppose you have some virus which infects liver cells only. It lives in dogs.
You pet the dog. Chances are that no viral particles will enter your body at all.
You pet the dog some more. Maybe one or two particles enter your body. Most likely they don't infect any liver cells due to the species barrier.
The fact is you don't get bombarded much with viruses just by touching something. Now, if you touch a doorknob which contains human flu, the few virus particles that get transferred to your body are highly infectious, and that is enough. But a foreign virus isn't effective enough to work that way, usually. Once in a while one makes its way past these barriers and then we have a new outbreak.
If you have a chimera or xenotransplant, you have a constant low-level viral load in the blood, and so human cells are constantly exposed to animal viruses. The opportunity for cross-species infection is much higher as a result.
Keep in mind that lysogenic viruses never really go away - they surge up from time to time - they just never build enough to get you sick, but the viruses are in the blood. For an example of this, look at cold sores (although those are actually successful enough to cause visible symptoms).
Well, it isn't reversible encryption - they are hashed. However, the NTLM hash function is easy to brute-force.
NTLM hashes should not be stored on any system where security is even remotely important, for this reason. The newer hash function is secure (assuming the password can't be guessed).
Right, and one of those killed off milllions of people in the 20's I believe (well, I think that one was avian - I remember reading the Science article where it was sequenced and the tissue sample used for this purpose was just shipped Fedex (talk about a package you don't want to have lost!)).
One potential issue is that this could cause the emergence of several species-barrier-crossing viruses at the same time.
Not the end of the world, necessarily, but it wouldn't hurt to be careful...
Look up cryptic prophages. A prophage is a virus lying dormant in DNA. A cryptic one is a deactivated virus (it laid dorment for so long that it mutated enough that it can no longer become active).
They've been found in just about every genome sequenced to date. Viruses frequently integrate with the host genome (at least lysogenic viruses do). Usually this is only temporary, but they can lie dormant for a long time.
In a chimera a virus can re-emerge, and then potentially infect a human cell in the same organism. It probably won't happen due to the immune system, but given such intimate contact with human cells it could happen eventually. If the virus infects a human cell, the copies that emerge will tend to have human cell proteins on their surface, and these will tend to mask the virus from the human immune system.
The first infection is hard, the rest are much easier. A chimera has the potential to reduce the barrier to the first infection. The same issue applies to xenotransplants.
I'm not saying we should get out the pitchforks, but it would only be prudent to keep it in mind and be careful...
Slashdot Mirror
If, without collision-protect, I emerge package A and then unmerge package B, how do I know it didn't take some of A's files with it?
That shouldn't be possible. When unmerging B it should notice that the mtime on a package A file is different, and as a result it shouldn't delete it.
In fact, when you upgrade a package it installs the new version before removing the old version. Since 99% of the files are going to overlap, nobody would have a working system if this wasn't the case. By looking at mtimes, when the old version is cleaned any files that were overwritten by the new version are left intact.
Don't get me wrong - portage features should just work, and it is important that at least those doing QA not just stick to the run-as-root flags.
Apparetly with mozilla it can't be done in 1.5 years unless you have a lot of cash...
Sure it is - it is just as possible to verify as it is to verify that Verisign's root cert is valid.
CA Cert's certificate is fairly well attested to in general, and can be downloaded from a variety of places. They just haven't ponied up huge wads of cash to get into most browsers' list of trusted root certs.
There is a war brewing on the mozilla bugzilla about this very topic...
The ebuild would instruct you to clear your queue, stop Postfix, and then do the update. If you didn't do this, it broke.
The problem is that if you just did an emerge -uD world, and postfix wasn't the first thing on the list, you probably didn't see the warning before you blasted through the installation process. Likewise, if it wasn't hte last item you probably never saw any warnings at the end.
Most people don't emerge one program at a time. It would be nice if the notes were collected and printed at the end...
Uh, you can just leave the earth on its axis, thank you. I think the component of the field that is perpendicular to the equator is plenty large for your purposes.
So, anybody have a few hundred thousand miles of copper cable handy? That should fit on the space shuttle with no problems.
Plus, if you just plug in a few billion petaohms of resistors, you can even stop the Earth's rotation, or at least drain its magnetic field.
You probably don't need to correct for efficiency - just make them mirrors instead of solar cells and just blast the solar sail with direct solar energy. I imagine that would do a good job of heating up the paint.
Still, it is probably easier to build a 200MW microwave transmitter on earth than a 60MW one in space. And I don't think microwaves are actually attenuated all that much.
Said probe still needs to slow down and enter orbit around Mars, unless it wants to be a Voyager and just rocket past the planet.
Of course, in WW1 we had opposing forces just sitting at stalemates for months - so if a spy sneaks in a night and taps a line it gives good intel for a while.
In Desert Storm, troops moved across half the country in two days. By the time you'd tap a line both ends of it would be blown up. And while you could have tapped some lines near the border or some really long ones that passed through unobserved territory inland, it would be difficult to tap many lines simply because the lines were so far apart. In WW1 you could probably see the people you were shooting at, and a brave guy could probably crawl across no-man's land at night. In Iraq the sides were hundreds of miles apart, and you'd need a helicopter to get in, and those aren't always stealthy. (Again, if you have 100 miles of telephone cable with nobody watching the middle part, that would be easy to tap, but if you have a bunch of bunkers separated by 100 yards, you're not going to land a chopper within a mile of it.)
My guess is that most mail servers that receive several million emails all trying to guess the answer to a single CAPTCHA will probably just deep-six the sender and send an abuse complaint to their ISP automatically.
The whole reason UNIX cracking works is because you can do it without talking to the server that you're trying to crack.
I used to do the copy-and-paste thing. It works.
Now I do the download/upload thing. It works better.
Seriously - why do we bother with these fancy integrated webbrowsers that have all kinds of bloat and security holes. All you need is wget to fetch pages, and an HTML viewer without networking capability to render them. Is it really that hard to copy a link destination URL and paste it into a shell?
In my case, downloading/uploading was worth $10 of hard-earned-money. I wish I didn't have to spend it, but I did. If most people didn't feel the same way Quicken wouldn't be flying off the shelves...
So is a BASIC interpreter. Should we conclude that an interpreted BASIC program runs with the same performance as something written in C?
Sure, Java has JIT, profiling and optimization, etc. It also has a whole new set of class libraries, etc, which have to go into RAM. Load time is significantly slower than something compiled using C. In general, run time is also a little slower, but I'll admit that this is probably application-dependant.
For that matter, you have to take every other holy text across the globe on the same faith, then, to be fair.
Obviously.
I'm not saying that religious books should not be questioned. I'm just saying that if a book is making a historical claim that on the 5th of Feb 1498 Joe Smith in London built a functioning microwave oven, the basis for criticizing the text should be documented evidence that the book was written in modern times, not an assumption that nobody could have built a microwave oven in 1498. Otherwise what is the point of writing down what happens?
The whole point of documenting events is so that people in the future will know what happened. That isn't accomplished if the people in the future just say "well, I don't think that happened, so it must be made up."
Or think of it another way - science must be falsifyable. Let's start with the hypothesis that there is no such thing as prophesy. The null of that is that there is such a thing (and presumably it has happened, although that isn't strictly necessary). How would you prove that prophesy occurred? Simple - scan historical documents for evidence of detailed predictions of future events. That is hardly possible if the dates of authorship for those documents were assigned purely on the assumption that there is no such thing as prophesy...
RAM:
512MB
OS:
linux-2.6.9
I wouldn't define either as being substandard.
I will admit that performance may vary by application.
The earliest Mark would have been written was about 70 AD, since there is an indication in the text that he knew about the destruction of the Temple.
Are you referring to an indication that Mark knew about the destruction of the temple, or that somebody quoted in the text (such as Jesus) knew about it?
Since the whole premise of the text is that Jesus is God, it is hardly unreasonable to assign a date prior to AD70 for the authoring of the text.
Now, if there is an archeaological reason to think that it was written later, that is one thing. But if the only reason is that it is assumed that Jesus couldn't possibly know the future and consequently it had to be made up later, then that seems rather bold.
When analyzing the gospels as historical documents, the origin of the documents is clearly open to debate. However, since the main reason that they're worth studying is the impact they've had on history, it probably doesn't make sense to start with the presupposition that they're completely made up...
Yes, I have both installed. Anything bigger than hello.java tends to crash. They're both quite buggy.
Don't get me wrong - java is a great concept, and if you have memory to burn it works well. However, in practice it tends to use quite a bit of RAM.
It will also be nice when the 64-bit java actually works on x86_64.
Sure, whatever: Also, you don't have to rely on your Linux distribution to figure out how to compile the damned thing.
The whole point of a linux distro is to let it figure out how to compile/install something. I don't want a mess of self-built applications in
It's written in Java, so it runs on Windows, Linux, and UNIX
Assuming that somebody has taken the time to bother writing a working JVM for your platform. Last time I checked Athlon64 users were out-of-luck unless they're running in 32-bit land (as my example above is).
Seriously, what is wrong with just writing something in C?
I admire the java concept - however the JVM and java applications in general seem to just devour memory. CPU performance is generally fine, but when I wake up my computer and it takes 30 seconds to display the xlock window, you can tell that there is a memory issue...
What is the point in reconciling your accounts if you use information the bank gives you?
Fair enough.
However, online transaction download is good-enough for most people. Since the transactions are downloaded only a few days after you made them, you'll be fairly likely to spot discrepencies (sure, not a dollar or two, but if you get a mystery charge from a store you've never visited you're gonna give the bank a call).
Also - in most checking account cases, I'm the one putting the transactions into Quicken, and then Quicken will point out if there is a discrepency when the same transaction shows up on download.
For things like credit cards, most people don't bother to reconcile anyway. So, by using transaction downloading, you at least get a record of all your transactions, and the ability to categorize them - which is essential for budgetting.
In an ideal world, you don't use an ATM card, credit card, check, cash from your wallet, or make a promise to a friend without writing into a register first. Most people don't live in that world. Transaction downloading is the next-best-thing...
Anybody who takes money for a service, and doesn't perform that service, is probably liable for at least a pro-prated fee refund.
My ISP had technical problems that put me offline for a day. They immediately sent out emails and even phone calls to all their cusomters to let them know that they can expect a credit on their next bill as a result.
Reputable companies know that stepping up to the plate when they mess up buys customer loyalty.
1) is CPU-bound rather than interconnect-bound or disk-bound or memory-bound
Actually, Moore's law will probably help out with memory access speed. Also, if you're interconnect-bound Moore's law will allow you to keep total CPU power constant while reducing the number of CPUs, and consequently the number of interconnects.
2) will take 3 years+ with current technology / budget, and
I'll definitely agree there... Moore's law isn't THAT fast...
I do and it is free. However, it is much nicer to just enter a transaction and have it uploaded to the bank, than to enter a transaction in your software, and then enter it again online.
Part of the problem is that as for-profit enterprises Quicken and MS Money can spend a lot more on bank marketing. They can get their foot in the door with their proprietary standards much more quickly. Neither is going to want to make it easy for a FOSS package to play-ball...
I've tried this and kmymoney. They are getting there, but they're not close enough for me.
The last time I tried (probably six months ago), the budgeting features were not good, online downloading and uploading of transactions looked to be incompatible with my bank, and reporting was not as versitile. The transaction registers themselves worked just fine, though.
It is also difficult to just experiement with the online features since it is your bank, and if it is working with quicken already do you want to mess with possibly getting the online service in some strange state? Financial software really only works well if all your transactions are in one place, so nobody would want to cut-over unless they had a fairly high degree of confidence that the FOSS alternatives are ready for prime-time.
I ended up buying quicken 2K4 for about $5-10 mail-order. If you buy a one-year-old version it isn't nearly as much of a ripoff.
Suppose you have some virus which infects liver cells only. It lives in dogs.
You pet the dog. Chances are that no viral particles will enter your body at all.
You pet the dog some more. Maybe one or two particles enter your body. Most likely they don't infect any liver cells due to the species barrier.
The fact is you don't get bombarded much with viruses just by touching something. Now, if you touch a doorknob which contains human flu, the few virus particles that get transferred to your body are highly infectious, and that is enough. But a foreign virus isn't effective enough to work that way, usually. Once in a while one makes its way past these barriers and then we have a new outbreak.
If you have a chimera or xenotransplant, you have a constant low-level viral load in the blood, and so human cells are constantly exposed to animal viruses. The opportunity for cross-species infection is much higher as a result.
Keep in mind that lysogenic viruses never really go away - they surge up from time to time - they just never build enough to get you sick, but the viruses are in the blood. For an example of this, look at cold sores (although those are actually successful enough to cause visible symptoms).
Well, it isn't reversible encryption - they are hashed. However, the NTLM hash function is easy to brute-force.
NTLM hashes should not be stored on any system where security is even remotely important, for this reason. The newer hash function is secure (assuming the password can't be guessed).
Right, and one of those killed off milllions of people in the 20's I believe (well, I think that one was avian - I remember reading the Science article where it was sequenced and the tissue sample used for this purpose was just shipped Fedex (talk about a package you don't want to have lost!)).
One potential issue is that this could cause the emergence of several species-barrier-crossing viruses at the same time.
Not the end of the world, necessarily, but it wouldn't hurt to be careful...
Look up cryptic prophages. A prophage is a virus lying dormant in DNA. A cryptic one is a deactivated virus (it laid dorment for so long that it mutated enough that it can no longer become active).
They've been found in just about every genome sequenced to date. Viruses frequently integrate with the host genome (at least lysogenic viruses do). Usually this is only temporary, but they can lie dormant for a long time.
In a chimera a virus can re-emerge, and then potentially infect a human cell in the same organism. It probably won't happen due to the immune system, but given such intimate contact with human cells it could happen eventually. If the virus infects a human cell, the copies that emerge will tend to have human cell proteins on their surface, and these will tend to mask the virus from the human immune system.
The first infection is hard, the rest are much easier. A chimera has the potential to reduce the barrier to the first infection. The same issue applies to xenotransplants.
I'm not saying we should get out the pitchforks, but it would only be prudent to keep it in mind and be careful...