Whether or not you buy that issue of security, it is a generally accepted practice in some circles. Further, these are often policies handed down from on high. If you argue with them, even come up with good reasons, one often gets back the old "Fiddler on the Roof" answer of "Tradition!" Other answers include "Turnkey solutions" and "reproducibility" and "default configuration of installed distribution".
Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).
And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).
2 year stable cycles are much more friendly to developers & system administrators. 6 months means you do nothing but chase your tail.
Roommate used to work at google, hence the knowledge of Goobuntu. It's not a hoax, but it is also only an internal project for corp (non-production [production defined as the code that runs Google, GMail, etc]) use only, albeit there was hope for it to replace Prod72, et al. There are little to no plans to release it for distribution outside the company.
Instruction isn't so hard when you're in the enterprise space, so telling them how to install the relevant RPM is usually acceptable, albeit sometimes you will find that you have ridiculous requirements like a) don't require a compiler b) has to be installable by non-root [cough cough, my current employer]
I'll grant the whole 'RHEL doesn't mean stable' but then again, at least it is a implementation that can be relied upon to not change from month to month, as they will keep the same version throughout most of the series (4.x or 5.x is a series).
a) Most of my work is in spaces where enterprise distributions are much more likely to be present. And despite Shuttleworth's aspirations, Ubuntu isn't particularly enterprise-worthy (Google has been learning that lesson the hard way with their Goobuntu project). b) Lack of CPAN modules is easy to overcome if the module doesn't use XS. just distribute the necessary modules yourself. If the module does use XS, but you can use a version a year or 2 old you can instruct the user how to install the relevant RPMs.
I cannot however rely on the old version of pugs to be sufficient. Plus, the bytecode compiled form doesn't mean it's usable w/o the relevant runtime engine...
Any of these solutions requires a stable implementation to rely on.
It wouldn't occur until midnight UTC, or if localtime is used on their clocks, midnight local time. Either way, it wouldn't occur before the evening of the 31st, and may not be noticed until after the new years eve party.
What people often forget however is that part of 'release early, release often' is 'release something useful'.
If something is perpetually in [true] beta, and doesn't appear to do anything useful yet (can I start coding my perl6 apps yet? sure. I can, but the specific details of the language are still in flux and MAJOR bugs are still being fixed, so I cannot write things in perl6 and rely on them to work).
I'm also still waiting for perl5 to be written for parrot. Then I can start mixing and matching my perl6 vs perl5 code and migrate an old perl5 project over.
A similar problem is that although I can write things for Perl6 (pugs or parrot) I cannot expect other people to have pugs or parrot in their distro, and thus be able to use them.
I would have the same problem writing my apps for perl5.10, as perl 5.8 is still in CentOS 4 and CentOS 5 (and let's not forget Debian stable [etch] or SuSE Linux Enterprise Server 10).
Has anyone considered the old rule (that almost everyone ignores, but the cops tend to remember) of 1 car-length per 10 miles per hour? So if you're going 65 and you have 2 car-lengths until the next car, YOU'RE TOO CLOSE.
Actually, there are repeaters in line, albeit I don't remember the distances. There's a big copper conductor in the jacket (just one, the ground is the ocean itself) sending a couple hundred volts through it.
RAID0 is striped, and has _zero_ redundancy. RAID1 is mirrored.
It also can be made to act as if striped for reads, but not for writes (you can interleave the reads across the discs, plus or minus seeks). Of course, RAID0 has more capacity than RAID1 for the same number of discs, but RAID1 isn't about capacity as much as it is for reliability.
I think you missed a point there. The idea behind punishing credit card companies is not about credit-card fraud, but rather making the various V|4GR4 ads go away.
If credit cards have to be used to pay for such products, punishing the credit-card companies for processing those payments would make the economic incentive to sell such products dry up.
Having experience with this problem, I can tell you that the problem is that MySQL's implementation of b-tree indices doesn't work well for ranges (specifically, it can only eliminate rows on one side of the inequality). The solution is to use rtree indices (GIS functions, 'SPATIAL INDEX').
I didn't come up with the technique, but I can't find the webpage where I found it. I did end up using it for a geolocation system though.
Re:Amen with the crashed systems.
on
Nmap Network Scanning
·
· Score: 5, Interesting
Happened to me in college at gvsu.edu. They claimed I had crashed several Solaris boxen, and claimed that my Linux box was 'dangerous', and even cut off my network access.
The kicker was the 150 hours of community service I had to put in to pay for the time (of 'computer professionals' who were worth a lot more money than I was) it took to bring them back online.
And to think, I was only trying to map out the campus network and what systems they used for various purposes.
All of those filesystems are designed to work on raw flash, not the Flash to IDE products that typically come as 'SSDs'. So sorry, but that's not a useful answer.
11,000USD is _cheap_ compared to NetApp. And I have it on good authority that (at least for corporate, but not necessarily for production) that Google uses NetApp for storage. They have attempted multiple times to produce a better solution, but last I knew (about 6 months ago) they still hadn't found a good solution.
On any kind of WAN link, it's a savings. It only costs you something on a 100mbit LAN link. The basic problem is that if you hit the CPU limit before you hit the bandwidth limit, compression (or encryption) will suck. But if you can hit the bandwidth limit first, then you will get a reasonable savings.
I've so far found that on a reasonably modern CPU, you need to be pushing in excess of a 10mbit ethernet, but less than a 100mbit ethernet, for it to hit the CPU limit first.
Reasonably modern CPU being defined as, approximately, a 1GHz Athlon or higher. My Thinkpad R51 (1.6GHz Pentium-M) caps out at ~2Mbyte/sec if compression or aes128-cbc is used (arcfour & no compression lets it hit 4-6Mbyte/sec [very very slow hard-drive]).
On a much more modern system, with compression disabled and arcfour encryption (and the MAC cranked down to the hmac-md5), I cap at approximately 40Mbyte/sec.
My general thought on this was that it was probably cheap for those who wanted an iPhone to pay 100USD to some homeless guy to stand in line for 4 hours to buy their iPhone for them (sure, they could run off with your money, but you could have them just call you if they're only 15 minutes from getting in). I never did figure out if anyone did that, but it was certainly possible, and a growth-industry for the homeless/illegal-aliens.
Slashdot Mirror
Whether or not you buy that issue of security, it is a generally accepted practice in some circles. Further, these are often policies handed down from on high. If you argue with them, even come up with good reasons, one often gets back the old "Fiddler on the Roof" answer of "Tradition!" Other answers include "Turnkey solutions" and "reproducibility" and "default configuration of installed distribution".
Security is one reason one cannot require a compiler (makes it easier to make exploits if you can compile from source & headers).
And yes, Ubuntu doesn't change more often than 6 months, but I don't want to have to chase bugs during the entire 6 month cycle either (or get blind-sided when the next release comes out and my app breaks).
2 year stable cycles are much more friendly to developers & system administrators. 6 months means you do nothing but chase your tail.
Roommate used to work at google, hence the knowledge of Goobuntu. It's not a hoax, but it is also only an internal project for corp (non-production [production defined as the code that runs Google, GMail, etc]) use only, albeit there was hope for it to replace Prod72, et al.
There are little to no plans to release it for distribution outside the company.
Instruction isn't so hard when you're in the enterprise space, so telling them how to install the relevant RPM is usually acceptable, albeit sometimes you will find that you have ridiculous requirements like a) don't require a compiler b) has to be installable by non-root [cough cough, my current employer]
I'll grant the whole 'RHEL doesn't mean stable' but then again, at least it is a implementation that can be relied upon to not change from month to month, as they will keep the same version throughout most of the series (4.x or 5.x is a series).
a) Most of my work is in spaces where enterprise distributions are much more likely to be present. And despite Shuttleworth's aspirations, Ubuntu isn't particularly enterprise-worthy (Google has been learning that lesson the hard way with their Goobuntu project).
b) Lack of CPAN modules is easy to overcome if the module doesn't use XS. just distribute the necessary modules yourself. If the module does use XS, but you can use a version a year or 2 old you can instruct the user how to install the relevant RPMs.
I cannot however rely on the old version of pugs to be sufficient. Plus, the bytecode compiled form doesn't mean it's usable w/o the relevant runtime engine...
Any of these solutions requires a stable implementation to rely on.
It wouldn't occur until midnight UTC, or if localtime is used on their clocks, midnight local time. Either way, it wouldn't occur before the evening of the 31st, and may not be noticed until after the new years eve party.
think timezones vs UTC.
What people often forget however is that part of 'release early, release often' is 'release something useful'.
If something is perpetually in [true] beta, and doesn't appear to do anything useful yet (can I start coding my perl6 apps yet? sure. I can, but the specific details of the language are still in flux and MAJOR bugs are still being fixed, so I cannot write things in perl6 and rely on them to work).
I'm also still waiting for perl5 to be written for parrot. Then I can start mixing and matching my perl6 vs perl5 code and migrate an old perl5 project over.
A similar problem is that although I can write things for Perl6 (pugs or parrot) I cannot expect other people to have pugs or parrot in their distro, and thus be able to use them.
I would have the same problem writing my apps for perl5.10, as perl 5.8 is still in CentOS 4 and CentOS 5 (and let's not forget Debian stable [etch] or SuSE Linux Enterprise Server 10).
Radio waves naturally cross state lines. QED.
Has anyone considered the old rule (that almost everyone ignores, but the cops tend to remember) of 1 car-length per 10 miles per hour? So if you're going 65 and you have 2 car-lengths until the next car, YOU'RE TOO CLOSE.
Actually, there are repeaters in line, albeit I don't remember the distances. There's a big copper conductor in the jacket (just one, the ground is the ocean itself) sending a couple hundred volts through it.
I fail to see why there would be no one to sue... as the company still exists.
I don't think that if P&G dropped Tide next year that I can't still sue P&G if I find out that Tide put holes in my clothes.
RAID0 is striped, and has _zero_ redundancy. RAID1 is mirrored.
It also can be made to act as if striped for reads, but not for writes (you can interleave the reads across the discs, plus or minus seeks). Of course, RAID0 has more capacity than RAID1 for the same number of discs, but RAID1 isn't about capacity as much as it is for reliability.
I think you missed a point there. The idea behind punishing credit card companies is not about credit-card fraud, but rather making the various V|4GR4 ads go away.
If credit cards have to be used to pay for such products, punishing the credit-card companies for processing those payments would make the economic incentive to sell such products dry up.
No, THIS IS AMERICA!
Having experience with this problem, I can tell you that the problem is that MySQL's implementation of b-tree indices doesn't work well for ranges (specifically, it can only eliminate rows on one side of the inequality). The solution is to use rtree indices (GIS functions, 'SPATIAL INDEX').
I didn't come up with the technique, but I can't find the webpage where I found it. I did end up using it for a geolocation system though.
Happened to me in college at gvsu.edu. They claimed I had crashed several Solaris boxen, and claimed that my Linux box was 'dangerous', and even cut off my network access.
The kicker was the 150 hours of community service I had to put in to pay for the time (of 'computer professionals' who were worth a lot more money than I was) it took to bring them back online.
And to think, I was only trying to map out the campus network and what systems they used for various purposes.
No, as it will require/depend-on _other_ libraries that are also not available (or not in the correct versions).
He didn't say "two websites" he said "two webservers".
All of those filesystems are designed to work on raw flash, not the Flash to IDE products that typically come as 'SSDs'. So sorry, but that's not a useful answer.
11,000USD is _cheap_ compared to NetApp. And I have it on good authority that (at least for corporate, but not necessarily for production) that Google uses NetApp for storage. They have attempted multiple times to produce a better solution, but last I knew (about 6 months ago) they still hadn't found a good solution.
On any kind of WAN link, it's a savings. It only costs you something on a 100mbit LAN link. The basic problem is that if you hit the CPU limit before you hit the bandwidth limit, compression (or encryption) will suck. But if you can hit the bandwidth limit first, then you will get a reasonable savings.
I've so far found that on a reasonably modern CPU, you need to be pushing in excess of a 10mbit ethernet, but less than a 100mbit ethernet, for it to hit the CPU limit first.
Reasonably modern CPU being defined as, approximately, a 1GHz Athlon or higher. My Thinkpad R51 (1.6GHz Pentium-M) caps out at ~2Mbyte/sec if compression or aes128-cbc is used (arcfour & no compression lets it hit 4-6Mbyte/sec [very very slow hard-drive]).
On a much more modern system, with compression disabled and arcfour encryption (and the MAC cranked down to the hmac-md5), I cap at approximately 40Mbyte/sec.
My general thought on this was that it was probably cheap for those who wanted an iPhone to pay 100USD to some homeless guy to stand in line for 4 hours to buy their iPhone for them (sure, they could run off with your money, but you could have them just call you if they're only 15 minutes from getting in). I never did figure out if anyone did that, but it was certainly possible, and a growth-industry for the homeless/illegal-aliens.
Loading this link in elinks produces the following:
not "I2" but "L2", as in "Layer 2". "WoL" is "Wake on Lan".