Lets take cache as an example. You can have programs (compiled exactly the same way - same executable) that do really really well on one type of cache (say 4-way set associative) but really really poorly on another (say direct-map). (It's actually rather trivial to write them on purpose).
Thus, going to a more powerful machine could really hurt you if your code is optimized for the wrong cache. Now, yes, this particular example is rather trite and unlikely but it's an example.
Cache optimizations, extra instructions (MMX, SSE, etc), etc. There are things you can do to get better performance out of a higher end machine that you can't on a lower end, and so you need to test on the higher end to make sure it actually does get the performance boost it should.
Sure.
$ time dd bs=1024K count=100 if=/dev/zero of=foo.bin
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.656254 s, 160 MB/s
real 0m0.673s
user 0m0.000s
sys 0m0.440s
$ time dd bs=1024K count=100 if=/dev/urandom of=foo.bin
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 31.9296 s, 3.3 MB/s
real 0m31.989s
user 0m0.004s
sys 0m29.458s
$
Try it yourself if you don't believe me... random generation, even pseudo, non-secure random is much more computationally expensive than generating zeros.
Most building/fire/health codes have a clause about being subject to "local regulations" which basically means that the local building/fire/health inspector can say whatever (s)he wants and get away with it. They're also the interpreter of "reasonable", "safe" and other such terms that leave plenty of ambiguity. Basically, they are given a carte blanch.
Well, no. Large ISPs don't have to accept and forward routes from customers without verifying them. The solution to this is the same as preventing forged IP source addresses: stop it at the origination point. If you're an ISP with customer A and customer A starts advertising routing for an IP range they haven't previously advertised, don't accept the advertisement and forward it up the chain until you verify that they actually should advertise that route.
With Orion (either DIRECT or with the Ares), it's "the Launchpad Abort System fires and pulls the capsule away from the pad, taking the astronauts to safety."
A year for a box that will be top of the line at the purchase time, mid-range in 3-6 months and will be lacking critical features relative to what's currently on the market in 9 months. By 1 year, the box will be out of date and by 1.5-2 years the cable company will have to replace it.
The term has to be adjusted for the speed of the market.
Re:Nice review, but I don't understand something.
on
Bash Cookbook
·
· Score: 1
He continues to say he learned stuff about the "find" command which I assume the chapter focuses on.
Doubtful... there are binary incompatibilities between each release of Debian that make it rather difficult to install packages. For example, the C++ ABI bump during sarge's release cycle means you won't be able to install *ANYTHING* written in C++ from pre-sarge on a post-sarge system. Various other library ABI changes will require you to search out old versions of library packages.
Debian and Ubuntu use exactly the same packaging format (.deb). Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.
Now you could probably rebuild it for your system, but depending on what it is, it may or may not work.
When you say "how hard it is going to bed to compile and update"...that's exactly what LSB is working on. It'll be trivially easy to compile a program written against the LSB specs on any LSB compatible distro.
UNIX fractured into a large number of incompatible variants including BSD (fractured further into Open/Free/Net BSD), Solaris, IRIX, HP-UX, SCO Unix, etc., etc..
Apparently he helped the FBI in analyzing the samples in the initial investigation. TFA says the investigation shifted focus in 2006 and
Moreover, significant progress was made in analyzing genetic properties of the anthrax powder recovered from letters addressed to two senators.
I wonder if he faked his analysis and used it to frame Hatfill (the guy the Government had announced as a person of interest, sued the NYTimes and the Justice Dept. for libel and got a big settlement from the later)
Also from TFA:
Soon after the government's settlement with Hatfill was announced June 27, Ivins began showing signs of serious strain.
The older VIA chips may have had a similar issue perhaps with SSE, an issue which has been rectified in the current models but which the benchmark is unaware of.
I think it's much more likely that this should read "which the compiler is unaware of".
A VIA Nano CPU has had its CPUID changed from the original VIA to fake GenuineAMD and GenuineIntel. An improvement of, respectively, 10% and 47% of the score was seen.
It sounds to me like this could possibly be explained by some kind of conditional optimization that the compiler puts in for various chips, to take advantage of differences in their designs that can improve performance.
Sure, I agree it's the right approach and the stack approach is great. However, some of the layers of the stack are showing their age. To repeat my example from before: TCP's performance on very high bandwidth, long distance links really, really sucks. (even from coast-to-coast US but it's even more pronounced). That's because TCP takes so much time to ramp up that you never get a chance to fill the pipe. There are a lot of ways this is being addressed such as exponential ramp up, piggy-backed protocols to help set the congestion window manually, extensions to TCP, forks of TCP, etc., but the bottom line is that a lot of these protocols were developed in the 70s and 80s for a very different kind of network than we're seeing now and they just aren't cutting it.
Trusted computing isn't as bad as people make it out to be.
Yes, in windows, it's being implemented to do secure DRM, which I agree is bad.
However, Linux has had support for TPM, etc. since before windows. When done properly, trusted computing can be a great way to ensure system security. It can prevent root kits, exploits, virtual machines masquerading as our real OS, unauthorized access to files, etc. The difference is that in Windows, Microsoft is the one who decides what's trusted, in Linux, the user does.
Guess what the NSF is funding? It's not the DRM stuff, it's the stuff you read about in academic journals and the like... mostly research based stuff for operating systems that don't exist to develop the concepts and techniques to implement trusted computing so that we can do the cool stuff to protect our own computers.
To be pedantic, number factoring isn't NP-complete and an algorithm to solve an NP-complete problem won't necessarily lead to one for integer factorization.
The bigger fear is quantum computers, with a proven algorithm to factor numbers in polynomial time (Shor's Algorithm). In fact, some research quantum computers have factored very small numbers (ex: 15) already.
If you RTFA, Red Hat is planning on getting it's revenue from selling support. I'm not sure I see this happening. If you're running a cloud service, you're going to have a LOT of machines and you're going to need enough custom support and custom software that you're probably going to have in-house support. If you have in-house support, you're probably not paying for the Red Hat support, so how do the expect to make revenue?
The grant is from the NSF, not the DoD which implies it is more scientific in nature.
However, even if it was from the DoD or NSA, the government has a strong interest in improving US users' security, so as to protect US companies from foreign espionage. Look at the NSA's contribution to various crypto algorithms (agreed upon by the security community as positive) or to SELinux.
Slashdot Mirror
Lets take cache as an example. You can have programs (compiled exactly the same way - same executable) that do really really well on one type of cache (say 4-way set associative) but really really poorly on another (say direct-map). (It's actually rather trivial to write them on purpose).
Thus, going to a more powerful machine could really hurt you if your code is optimized for the wrong cache. Now, yes, this particular example is rather trite and unlikely but it's an example.
Cache optimizations, extra instructions (MMX, SSE, etc), etc. There are things you can do to get better performance out of a higher end machine that you can't on a lower end, and so you need to test on the higher end to make sure it actually does get the performance boost it should.
Governments typically give a lot of money in research grants to top universities and have lots of influence over them...
Sure.
$ time dd bs=1024K count=100 if=/dev/zero of=foo.bin
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.656254 s, 160 MB/s
real 0m0.673s
user 0m0.000s
sys 0m0.440s
$ time dd bs=1024K count=100 if=/dev/urandom of=foo.bin
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 31.9296 s, 3.3 MB/s
real 0m31.989s
user 0m0.004s
sys 0m29.458s
$
Try it yourself if you don't believe me... random generation, even pseudo, non-secure random is much more computationally expensive than generating zeros.
Most building/fire/health codes have a clause about being subject to "local regulations" which basically means that the local building/fire/health inspector can say whatever (s)he wants and get away with it. They're also the interpreter of "reasonable", "safe" and other such terms that leave plenty of ambiguity. Basically, they are given a carte blanch.
Well, no. Large ISPs don't have to accept and forward routes from customers without verifying them. The solution to this is the same as preventing forged IP source addresses: stop it at the origination point. If you're an ISP with customer A and customer A starts advertising routing for an IP range they haven't previously advertised, don't accept the advertisement and forward it up the chain until you verify that they actually should advertise that route.
3. Develop a thug caste: Not yet, I think so at least.
Drug users?
With Orion (either DIRECT or with the Ares), it's "the Launchpad Abort System fires and pulls the capsule away from the pad, taking the astronauts to safety."
A year for a box that will be top of the line at the purchase time, mid-range in 3-6 months and will be lacking critical features relative to what's currently on the market in 9 months. By 1 year, the box will be out of date and by 1.5-2 years the cable company will have to replace it.
The term has to be adjusted for the speed of the market.
He continues to say he learned stuff about the "find" command which I assume the chapter focuses on.
On a naval base, no less. (The competition is at the US Navy Space and Naval Warfare Systems Center)
Of course, but it's obvious that they're incompetent, I'm just suggesting a less malicious type of incompetence.
Doubtful... there are binary incompatibilities between each release of Debian that make it rather difficult to install packages. For example, the C++ ABI bump during sarge's release cycle means you won't be able to install *ANYTHING* written in C++ from pre-sarge on a post-sarge system. Various other library ABI changes will require you to search out old versions of library packages.
Source isn't so bad though.
You should wonder about will it run.
Debian and Ubuntu use exactly the same packaging format (.deb). Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.
Now you could probably rebuild it for your system, but depending on what it is, it may or may not work.
When you say "how hard it is going to bed to compile and update"...that's exactly what LSB is working on. It'll be trivially easy to compile a program written against the LSB specs on any LSB compatible distro.
UNIX fractured into a large number of incompatible variants including BSD (fractured further into Open/Free/Net BSD), Solaris, IRIX, HP-UX, SCO Unix, etc., etc..
See this graph for more information.
Moreover, significant progress was made in analyzing genetic properties of the anthrax powder recovered from letters addressed to two senators.
I wonder if he faked his analysis and used it to frame Hatfill (the guy the Government had announced as a person of interest, sued the NYTimes and the Justice Dept. for libel and got a big settlement from the later) Also from TFA:
Soon after the government's settlement with Hatfill was announced June 27, Ivins began showing signs of serious strain.
Maybe he knew they were closing in on him?
I'm not saying the benchmark utility (or other software) is doing the optimization, I'm saying the compiler (whether gcc, Visual Studio, ICC, etc) is.
These guys are working on it, and apparently have made a lot of progress.
The older VIA chips may have had a similar issue perhaps with SSE, an issue which has been rectified in the current models but which the benchmark is unaware of.
I think it's much more likely that this should read "which the compiler is unaware of".
A VIA Nano CPU has had its CPUID changed from the original VIA to fake GenuineAMD and GenuineIntel. An improvement of, respectively, 10% and 47% of the score was seen.
It sounds to me like this could possibly be explained by some kind of conditional optimization that the compiler puts in for various chips, to take advantage of differences in their designs that can improve performance.
Then again, probably not.
Sure, I agree it's the right approach and the stack approach is great. However, some of the layers of the stack are showing their age. To repeat my example from before: TCP's performance on very high bandwidth, long distance links really, really sucks. (even from coast-to-coast US but it's even more pronounced). That's because TCP takes so much time to ramp up that you never get a chance to fill the pipe. There are a lot of ways this is being addressed such as exponential ramp up, piggy-backed protocols to help set the congestion window manually, extensions to TCP, forks of TCP, etc., but the bottom line is that a lot of these protocols were developed in the 70s and 80s for a very different kind of network than we're seeing now and they just aren't cutting it.
Trusted computing isn't as bad as people make it out to be.
Yes, in windows, it's being implemented to do secure DRM, which I agree is bad.
However, Linux has had support for TPM, etc. since before windows. When done properly, trusted computing can be a great way to ensure system security. It can prevent root kits, exploits, virtual machines masquerading as our real OS, unauthorized access to files, etc. The difference is that in Windows, Microsoft is the one who decides what's trusted, in Linux, the user does.
Guess what the NSF is funding? It's not the DRM stuff, it's the stuff you read about in academic journals and the like... mostly research based stuff for operating systems that don't exist to develop the concepts and techniques to implement trusted computing so that we can do the cool stuff to protect our own computers.
To be pedantic, number factoring isn't NP-complete and an algorithm to solve an NP-complete problem won't necessarily lead to one for integer factorization.
The bigger fear is quantum computers, with a proven algorithm to factor numbers in polynomial time (Shor's Algorithm). In fact, some research quantum computers have factored very small numbers (ex: 15) already.
If you RTFA, Red Hat is planning on getting it's revenue from selling support. I'm not sure I see this happening. If you're running a cloud service, you're going to have a LOT of machines and you're going to need enough custom support and custom software that you're probably going to have in-house support. If you have in-house support, you're probably not paying for the Red Hat support, so how do the expect to make revenue?
The grant is from the NSF, not the DoD which implies it is more scientific in nature.
However, even if it was from the DoD or NSA, the government has a strong interest in improving US users' security, so as to protect US companies from foreign espionage. Look at the NSA's contribution to various crypto algorithms (agreed upon by the security community as positive) or to SELinux.