The dog alerts just on the scent not on the quantity so the fact that the dog alerted should not therefore constitute probably cause.
This shouldn't constitute probable cause anyway. Drug-sniffing dogs have around a 30% false positive rate. Of course, once you're busted, nobody really cares whether it was a false positive or not.
I've found that the most consistent and simple test regarding the quality of a given power supply is to weigh it. If it weighs more than the average power supply, it's more likely to be built with components of above-average tolerances and thus be more robust. You'll notice that all high-quality power supplies are rather hefty compared to the bargain basement ones - this isn't by accident.
If there's anything to do with A20, then it's the KBC and not a BIOS. Maybe some cloner redefined "BIOS" to mean something besides "ROM firmware"? In any case, it's not a BIOS under the standard definition of a BIOS in the PC world, unless it contains some embedded executable code.
As if a smoker couldn't just look at the end of the filter after inhaling and see for themselves... I think the basic issue is that it doesn't disgust them like it does for most nonsmokers.
The physical nature of the machine may have been durable, but the electronics were not. Aside from the rotten power supply, the CPU, PLA, SID, and RAM chips were very common failures, mostly due to heat. If you got the later versions where there is a metal sheet overlaid on all the chips to heatsink them, those machines were much more reliable. Of course, typical Commodore quality meant that there was the occasional machine where the sheet wasn't actually tacked onto some chip with heatsink goop, leaving that chip to fry alone.
The C64 power supply was filled with plastic potting. There is no way aside from cracking it to pieces that 120V would ever reach the low voltage side, so a ground prong would have been pointless. Unfortunately, that potting also made the cheapo regulator overheat, hastening the death of an already marginal design...
You're probably thinking of the keyboard controller, the long DIP chip that resembled a 40-pin BIOS chip. Keyboard BIOS functions are built into the system BIOS and as far as I know were never implemented as an option rom.
A vulnerability is not a vulnerability till somebody discovers it
Such a statement is completely understandable. After all, that's what they still teach at the Traal School Of Computer Security, where most management types are sent. You will rarely find a PHB that doesn't think this way, since those that disagree with the curriculum are contributed to the well-known piles of bleached bones.
Which brings us back to HP, and Fiorina. I can clearly see that Fiorina and her crowd of institutional investors are "fatal cost-cutters". They will cut and cut until the company has little blood left to bleed. Controlling costs is a responsibility, but you have to spend money to make it, and the Carly Generation obviously doesn't understand that.
You wonder why they didn't learn from Jack Tramiel and how he ran first Atari, then Commodore, into the ground, by cutting the quality out of the product along with the costs, and forgetting to innovate to ensure that they didn't bleed their market share dry in the long run.
Long story short: climates changes are cyclical, we just finished a period of warming, now we're in a period of cooling.
That's certainly possible. The problem is that nobody has yet established cause and effect between CO2 and global climate, and both sides assume one or the other.
We know periods of high global temperature correlate closely with periods of high atmospheric CO2 concentration. We know that CO2 concentration has been stable since around 1000AD all the way up to when we started burning fossil fuels as a primary source of energy, at which point the levels began to increase, and ever since then the rate of change has been increasing. However, we don't know whether CO2 concentration causes global warming, or the other way around; there is no causal link implied by the data, only a correlation, and when all you have is a correlation, it is easy to get cause and effect confused.
What global warming alarmists fail to address is the very real possibility that a natural warm climate phase evaporates CO2 from seawater and spurs tectonic activity, which would raise atmospheric CO2 concentration as an effect - meaning that our contributions to CO2 concentration really have no effect at all on global climate. What global warming "debunkers" like to do, however, is ignore data and attempt to perform ad hominem attacks on climate scientists.
Granted, there are a lot of people who refer to themselves as "scientists", but are really nothing more than pundits and theoreticians/philosophers; they do not apply the scientific method and/or they are unconcerned with either having evidence to prove their position, or ignore evidence that contradicts their position. Just as there are many politicians who prefer a faith-based approach to public policy, instead of placing trust in sound science as our best tool to understand our situation.
What we should do is look at the facts. The fundamental debate here is between cause and effect of CO2 concentration and global climate. Ignore the zealots and misguided attempts at global legislation for now. We are trying to answer a question so that we can make sound judgement based on the answer - assuming the answer to support one's judgement would be a mistake.
Now, it's not to say that we shouldn't attempt to limit our use of fossil fuels. This would be a wise move as insurance, and for USians. would additionally unsnare us from the quandary of trade with the Middle East. But a panicking approach instead of one gauged for the best long-term benefit is wrong, until the evidence shows that we do indeed have an acute problem on our hands.
If you are running two totally different processes at once, then you get immediate benefits.
If the processes are dependent on memory bandwidth, you will have trouble as they will be constantly fighting over the cache. For pure computation, perhaps, but nothing that depends on locality of reference for best results.
If the scheduler is smart enough to keep threads that belong to the same process on the same CPU, this effect is minimized since threads share the same pages (and thus cache entries). Scheduling threads from one particular process across multiple CPUs is not a bad idea when the CPUs are otherwise idle, but it's a terrible idea when the CPUs are busy, if one is to expect HT to lend any advantage.
You can use apt-get for this too. Just specify a default release in your apt.conf. If you want to pull a package from unstable, then apt-get -t unstable install and it, along with its dependencies, will be pulled from unstable; any normal apt usage will pull from testing or stable (whatever you gave as your default release).
I would have to agree that installing a package as soon as it hits unstable is a bad idea. You can go to packages.qa.debian.org to see how long it's been since a package was uploaded, along with any pending issues with it.
You could say that about any corporate software development house too. The reality is that the process instills trust and a sense of reliability in the customer (the user). The customer knows what to expect from Debian, and knows that this won't change tomorrow, because the reins of the project won't be arbitrarily handed over to a new person who happens to be ill-suited for the job either in technical ability or temperament.
This is a vulnerability in a standard, not in any particular browser. If IE implemented this standard (which it does, with a plugin), it would suffer similarly.
The GPL's intent is to spread the four freedoms that RMS proposed and that many developers feel that software users should be granted. Inconveniencing people who would like the freedom to deny software users those freedoms is not something the GPL authors were particularly concerned about.
Besides that, your understanding is wrong. You can work with any software you want and you do not have to make the source available. It is only when you distribute the work that the license of the whole work must fall under the GPL and you must either provide the source for the binaries you distributed, or a written offer to that effect. If you don't like that, use the LGPL so that the license of shared libraries is irrelevant.
I think this is more evil:
void main() {
while(1) {
int size = rand();
void *p = malloc(rand());
memset(p, 1, sizeof(p));
fork();
}
}
That way you actually use memory on every iteration of the loop, instead of just allocating memory whose underlying pages will be shared with the child processes.
Do you have any idea how har it is to write perfect non-trivial software on the first try?
Did I say somewhere that it needs to be done on the first try? This is precisely the problem; that companies are releasing "first tries" as finished products and letting their customers do the QA for them. Economically, this works out better, because customers like yourself are wusses and apologize for them instead of holding them accountable for their shoddy engineering practice.
I imagine you think a stock RH 4.2 box would be fine on the Internet, unpatched and unfirewalled for eternity. Or 5.2. Or 6.2. Or 7.3. Or 8. Or 9. Or FC3 or RHEL or SuSe or any other distro you can name.
Absolutely not, and where did I claim this? Red Hat's release policy is atrocious. I didn't say it was impossible to create an insecure system with open source software. My assertion is that open source has the *capability* of creating a system in which more confidence can be placed than even the best proprietary system.
From my perspective, Debian is very close to an ideal secure system. Full disclosure is encouraged, which is followed promptly with patches; cron-apt then performs a twice-daily check for _security_updates_only_ and downloads and installs them. Security patches are applied to the release version of the package, so you run zero risk of any collateral breakage.
A window of exploitation still remains there (between when an exploit is developed based on the security disclosure, and when a patched package is installed), but because services running as root are highly discouraged (as opposed to Red Hat who still embraces the godawful sendmail), an attacker would have to come up with a multi-level attack within that window, to both remotely compromise the unprivileged service and then use that compromise as a lever to exploit a local root vulnerability in another package. This is a far cry from something like the Windows RPC worm, which has nothing more to do to get root on an unpatched machine than to send a message to it.
So, peer review by competent developers implies that the software is closer to correct, while full disclosure demands immediate fixes to security bugs that sneak in anyway, while a multi-layer security model provides damage control when social measures have failed to keep a security problem from creeping in anyway. The question is, do all of those measures offset the lost security-by-obscurity that proprietary software enjoys?
First of all, this is one area where having multiple competing implementations of software is great, because you can deploy one FTP server, for example, and then spoof its response to appear to be some other popular FTP server. But otherwise, obscurity is only a slowdown to someone who is looking for vulnerabilities, and it may further lead a vendor and its customers into a false sense of security if the software has lurking faults. But in terms of the real world, Microsoft's closed-source and limited-disclosure policies have not prevented it from having to deal with the worst vulnerabilities of the last ten years; on the side of open source, it has been a few years since the last remote-push root vulnerability (OpenSSH) that affected a significant majority of deployed machines.
So no, open source obviously isn't immune to security problems, but good luck writing the equivalent of the MS-Blaster worm for open source systems. The above mitigating factors coupled with the inherent diversity of open source systems are going to be a real headache for an attacker.
Well, it isn't possible to write 100% bug free, correct, and secure software - unless of course we're talking about Hello World.
You're wrong. Software correctness is provable. It's only the lack of demand for correct software that ensures that this doesn't get done.
Humans by their very nature are not perfect and no matter whether you want to talk about propriety software, open source software, Windows, Linux, or whatever - there will always be mistakes.
I'm saddened that you ignore the facts - that bugs in open source software as a whole are less damaging than in Windows or typical proprietary software. The numbers of published bugs are comparable, but there are far fewer remote push exploits in open source, and the vast majority of published open source bugs are trivial problems that would only lead to an exploit under specific circumstances. How many special-case bugs are lurking in proprietary software that nobody but the black-hat who discovers it will ever know about? That's a question that only the vendor can answer, and they have an interest in ignoring and downplaying the issue until it escalates. Then, people will say "oh, get off their case, all software has bugs", thus they don't catch the flak they deserve for delivering poorly-tested software to their customers, and their strategy of ignoring the problem instead of tackling it just becomes reinforced.
And finally, this whole "proprietary systems" junk is nonsense. In North America at least, all modern vehicles conform to an open specification called OBD-II
OBD-II is a protocol. The software that the PCM (as well as any peripheral computers) is completely proprietary - if there's a firmware bug, you get to pay the dealership $150 a pop to update it. And even with OBD-II, you just get a code - you still have to find the dead tree somewhere that translates that code into information you can use to fix the problem.
All I see is that it has been a fully supported platform "since the release of NetBSD 2.0", which was two months ago. That's not nearly as impressive a head start as the original post was alluding to.
How is this any different from hot rodding? It is still the responsibility of the vehicle owner to ensure that their vehicle meets safety and emissions regulations for driving on public roads. Now when we have PCM viruses, that'll get interesting...
Slashdot Mirror
I've found that the most consistent and simple test regarding the quality of a given power supply is to weigh it. If it weighs more than the average power supply, it's more likely to be built with components of above-average tolerances and thus be more robust. You'll notice that all high-quality power supplies are rather hefty compared to the bargain basement ones - this isn't by accident.
If there's anything to do with A20, then it's the KBC and not a BIOS. Maybe some cloner redefined "BIOS" to mean something besides "ROM firmware"? In any case, it's not a BIOS under the standard definition of a BIOS in the PC world, unless it contains some embedded executable code.
As if a smoker couldn't just look at the end of the filter after inhaling and see for themselves... I think the basic issue is that it doesn't disgust them like it does for most nonsmokers.
The physical nature of the machine may have been durable, but the electronics were not. Aside from the rotten power supply, the CPU, PLA, SID, and RAM chips were very common failures, mostly due to heat. If you got the later versions where there is a metal sheet overlaid on all the chips to heatsink them, those machines were much more reliable. Of course, typical Commodore quality meant that there was the occasional machine where the sheet wasn't actually tacked onto some chip with heatsink goop, leaving that chip to fry alone.
The C64 power supply was filled with plastic potting. There is no way aside from cracking it to pieces that 120V would ever reach the low voltage side, so a ground prong would have been pointless. Unfortunately, that potting also made the cheapo regulator overheat, hastening the death of an already marginal design...
You're probably thinking of the keyboard controller, the long DIP chip that resembled a 40-pin BIOS chip. Keyboard BIOS functions are built into the system BIOS and as far as I know were never implemented as an option rom.
Then it obviously wasn't a tree.
We know periods of high global temperature correlate closely with periods of high atmospheric CO2 concentration. We know that CO2 concentration has been stable since around 1000AD all the way up to when we started burning fossil fuels as a primary source of energy, at which point the levels began to increase, and ever since then the rate of change has been increasing. However, we don't know whether CO2 concentration causes global warming, or the other way around; there is no causal link implied by the data, only a correlation, and when all you have is a correlation, it is easy to get cause and effect confused.
What global warming alarmists fail to address is the very real possibility that a natural warm climate phase evaporates CO2 from seawater and spurs tectonic activity, which would raise atmospheric CO2 concentration as an effect - meaning that our contributions to CO2 concentration really have no effect at all on global climate. What global warming "debunkers" like to do, however, is ignore data and attempt to perform ad hominem attacks on climate scientists.
Granted, there are a lot of people who refer to themselves as "scientists", but are really nothing more than pundits and theoreticians/philosophers; they do not apply the scientific method and/or they are unconcerned with either having evidence to prove their position, or ignore evidence that contradicts their position. Just as there are many politicians who prefer a faith-based approach to public policy, instead of placing trust in sound science as our best tool to understand our situation.
What we should do is look at the facts. The fundamental debate here is between cause and effect of CO2 concentration and global climate. Ignore the zealots and misguided attempts at global legislation for now. We are trying to answer a question so that we can make sound judgement based on the answer - assuming the answer to support one's judgement would be a mistake.
Now, it's not to say that we shouldn't attempt to limit our use of fossil fuels. This would be a wise move as insurance, and for USians. would additionally unsnare us from the quandary of trade with the Middle East. But a panicking approach instead of one gauged for the best long-term benefit is wrong, until the evidence shows that we do indeed have an acute problem on our hands.
I already replied to this, but found another post that says the same thing in (IMO) better words.
If the scheduler is smart enough to keep threads that belong to the same process on the same CPU, this effect is minimized since threads share the same pages (and thus cache entries). Scheduling threads from one particular process across multiple CPUs is not a bad idea when the CPUs are otherwise idle, but it's a terrible idea when the CPUs are busy, if one is to expect HT to lend any advantage.
I would have to agree that installing a package as soon as it hits unstable is a bad idea. You can go to packages.qa.debian.org to see how long it's been since a package was uploaded, along with any pending issues with it.
You could say that about any corporate software development house too. The reality is that the process instills trust and a sense of reliability in the customer (the user). The customer knows what to expect from Debian, and knows that this won't change tomorrow, because the reins of the project won't be arbitrarily handed over to a new person who happens to be ill-suited for the job either in technical ability or temperament.
This is a vulnerability in a standard, not in any particular browser. If IE implemented this standard (which it does, with a plugin), it would suffer similarly.
Besides that, your understanding is wrong. You can work with any software you want and you do not have to make the source available. It is only when you distribute the work that the license of the whole work must fall under the GPL and you must either provide the source for the binaries you distributed, or a written offer to that effect. If you don't like that, use the LGPL so that the license of shared libraries is irrelevant.
I think this is more evil: void main() { while(1) { int size = rand(); void *p = malloc(rand()); memset(p, 1, sizeof(p)); fork(); } } That way you actually use memory on every iteration of the loop, instead of just allocating memory whose underlying pages will be shared with the child processes.
From my perspective, Debian is very close to an ideal secure system. Full disclosure is encouraged, which is followed promptly with patches; cron-apt then performs a twice-daily check for _security_updates_only_ and downloads and installs them. Security patches are applied to the release version of the package, so you run zero risk of any collateral breakage.
A window of exploitation still remains there (between when an exploit is developed based on the security disclosure, and when a patched package is installed), but because services running as root are highly discouraged (as opposed to Red Hat who still embraces the godawful sendmail), an attacker would have to come up with a multi-level attack within that window, to both remotely compromise the unprivileged service and then use that compromise as a lever to exploit a local root vulnerability in another package. This is a far cry from something like the Windows RPC worm, which has nothing more to do to get root on an unpatched machine than to send a message to it.
So, peer review by competent developers implies that the software is closer to correct, while full disclosure demands immediate fixes to security bugs that sneak in anyway, while a multi-layer security model provides damage control when social measures have failed to keep a security problem from creeping in anyway. The question is, do all of those measures offset the lost security-by-obscurity that proprietary software enjoys?
First of all, this is one area where having multiple competing implementations of software is great, because you can deploy one FTP server, for example, and then spoof its response to appear to be some other popular FTP server. But otherwise, obscurity is only a slowdown to someone who is looking for vulnerabilities, and it may further lead a vendor and its customers into a false sense of security if the software has lurking faults. But in terms of the real world, Microsoft's closed-source and limited-disclosure policies have not prevented it from having to deal with the worst vulnerabilities of the last ten years; on the side of open source, it has been a few years since the last remote-push root vulnerability (OpenSSH) that affected a significant majority of deployed machines.
So no, open source obviously isn't immune to security problems, but good luck writing the equivalent of the MS-Blaster worm for open source systems. The above mitigating factors coupled with the inherent diversity of open source systems are going to be a real headache for an attacker.
Complacency is the wrong strategy.
All I see is that it has been a fully supported platform "since the release of NetBSD 2.0", which was two months ago. That's not nearly as impressive a head start as the original post was alluding to.
How is this any different from hot rodding? It is still the responsibility of the vehicle owner to ensure that their vehicle meets safety and emissions regulations for driving on public roads. Now when we have PCM viruses, that'll get interesting...