Can you scale up to 1,000 cores to meet a spike in demand and then back to 1 core when the demand drops
If you need realtime input data, you're screwed either way. Most applications don't scale well to 2 cores, let alone 1000. If I have a pretty popular website, I'd probably saturate my available network pipes long before the cpu power is a problem. Even good, fast and reliable storage is cheap, when compared to network connectivity.
any need to do significant demand-based scaling,
Let's say you are an somewhat obscure blog. You upload a video to your server that goes viral. How will Amazon solution scale so much better than the competition, if suddenly went viral (lets say 500k viewers)?
Been a client of them for >2 years (2 machines), and can only say good stuff. Good support, very attractive hardware packages, plenty of bandwidth, and for a little extra, you get "enterprise features" such as IP failover.
Define "lighter". Less resources? Because I usually get excellent performance out of PostgreSQL at a fraction of the memory needed for MySQL/InnoDB crap. I wouldn't describe as "light" the fact that, for a relatively complex schema such as Magento's, MySQL will usually eat up to 2x in memory the whole size of the database deliver a somewhat acceptable performance.
Certainly while I worked there, the company was absolutely happy to accept any WEEE goods from anyone, including those who hadn't bought anything from the shop. We had people coming in and giving us WEEE goods and then leaving without looking at anything. It seems to me that such a policy would only be in the company's interest if they were being paid by weight to do it.
Yeah, here in Portugal that is common practice too, but not in all stores, and not all items. We also have large recycle bins at the entrance of large shopping areas for small appliances, batteries and lamps. (And used kitchen oil too, but that's not relevant)
I was quite familiarized with WEEE regulations in my previous job, and the specifics of some of the EU countries (UK, Portugal, Spain, Germany, Italy and Czech Republic) - specially because I had to educate our (not-so-big) suppliers - and even some of our competitors - regarding the costs and obligations of warranty, WEEE/REEE taxes and the assorted requirements to be met when importing from Asian countries.
Retailers in the UK have, I think, had to collect WEEE goods under law for a while now
Retailers have to collect items they have sold, not items sold by others. From what I've depicted from the titlle (no I haven't read the article)m now retailers are obligated to collect an item, regardless of the origin.
I do know that retailers in the UK are paid by the weight of their electronic goods recycled, and not by their value in terms of rare earth metals and so on
I think you are mistaken. Retailers/manufacturers/importers pay by the weight and reciclability of what they sell. Additionally, you must pay an "importer fee" (it was 500 GBP, but may have changed) to then be able to pay per item sold. REEE regulation in EU is an absolute mess, because - long story short - there is no global market in electronics. As a retailer, you must be registered in every country you sell to, and - while the base law is the same - every country implements their own version, with their own fees, taxes and bureocracies. Small distributors are f**cked if they try to stay legal, and everyone else but the big importers just ignores it.
Its not in the florescent tubes or LED or whatever your LCD screen uses for illumination.
Actually, it is. Indium is used in the production of low-power led devices, and has been for decades (long before modern led-based screens). You can find a lot of information on Wikipedia, but also check http://www.lrc.rpi.edu/programs/futures/LF-LEDs/index.asp for an overview (they specifically mention white leds)
As such, it contributes to the feeling that Linux kernel development is an area in which women aren't welcome...
What feeling? Are the female kernel programmers leaving in droves because the kernel may be riddled with sexist remarks? Is it expected that a women in software development (which is mostly a male field) to be that sensitive about trivia? Do you forwn on using "tail", or putting a pipe in front of it? Do you steer away from large python packages, because it sounds dirty? Because, you know, 0xB16B00B5 isn't nowhere near BIGBOOBS as fsck is to fuck.
And believe it or not, sort of thing is the reason why there are so few female programmers.
...And yet, you have tons of females working in way more sexist environments, such as civil engineering, fashion, film industry, table serving or even the porn industry.
Our "tiny female brains" can cope with the actual work *just fine*.
Condescendent remarks only affect your credibility. If you are somewhat offended with the constant mentioned in the article, it's not because you are a woman - it's because you probably have serious social problems. Nothing wrong with that, but don't just assume "you speak for the woman".
Actually, I logged a bug with Oracle that the latest version of their database can't be troubleshot with strace or truss.
For each applicational bug that can't be easily traced/diagnosed at operating system level, you have dozens of performance issues/hiccups/misconfigurations that can. If you google "oracle strace", you'll find out that many people do use those tools for troubleshooting. If that wasn't the case, Oracle wouldn't be investing on them releasing a DTrace version for their Unbreakable Linux.
a developer to be tempted to store a UUID as a primary key in an InnoDB database
If you are using a UUID as a primary key on MySQL, is probably because you really need it (unique keys in cluster, ref to external databases, etc). And while it is slower than using a bigint, it's not that slower (you read from disk in 512 or 4096 byte blocks, and that is usually way more expensive than performing a 16-byte compare - so a sequential scan of a bigint and an UUID are probably similar).
It's also not always clear how to make full use of indexes...
That's why there is an EXPLAIN clause in most RDBMs. You can see exactly how the query will be interpreted by the database. Of course, MySQL has its "nuances" regarding indexes, but that says more about the shortcomings of it than anything else.
You're absolutely right, though, that a competent developer would take the time to learn as much of this as possible.
The problem is, many DBAs aren't really developers. It's not that difficult to find a career DBA that don't understand how the underlying system works (let alone troubleshoot a problem with tools like strace or truss or even dtrace), or the consequences of paralelism and application lifecycle (let's do this on a almost non-documented, non-versioned stored procedure, to be run simultaneously by hundeds of users, and that will break at each version upgrade). I'm not trying to generalize it (good professionals and bad professionals exist in every field), but it reflects my experience. Is it just me?
As to AOL's distributed "NOC", the rationale for it is almost ludicrous.
And it's not even clever. Some "datacenter on a container" providers already exist, that go way beyond a couple of racks, have neatier insulation and are completely mobile if you need it. And if you want small, there are half-container solutions.
So are ISPs responsible for the packets they deliver?
To an extent, yes. I fully expect that my ISP won't send packets "in my name"(by using my allocated IP address to send spurious traffic) when I'm online. That basic principle is what allow the identification of persons using IP addresses and lease timestamps. If your ISP cannot guarantee that your data hasn't been tampered with in their infrastructure, then they cannot prove they are only a bystander if an online crime occurs. That's why they go to great lengths to log everything they can that can be useful in those situations, and to wrap the service in a binding contract where you agree preemptively in taking responsability for everything that can go wrong, even if it is vaguely their fault.
Is gmail responsible for the contents of the mail they store?
Yes they are. That's why, when you sign up, you agree to a series of legally binding terms and conditions - so they minimize their legal responsability. And they will happily deliver the contents of your mail box to the authorities if requested (and probably with a detailed log of what you send and received).
Is Fedex responsible for the contents of their deliveries?
I guess you never read their fineprint either. You usually have to describe the contents of the package, and you agree not to submit a series of stuff (explosives, propellants, some types of glass, dangerous chemicals, etc) using their courier service, and they do the minimum effort to identify you (the address when they pick it up, the CCTV recording when you go to the station, etc).
Now, compare this to a hypotetical charge because of freenode stuff:
Who sent you this? I don't know.
Do you keep records of it? I don't know.
To whom did you sent it? I don't know.
You get the idea...
You're not stating facts by calling people zealots. You are being insulting and spreading FUD.
So, citing an official paper is spreading FUD? Good to know.
And binary compatibility is what matters so, yes, you have the red hat source.
Well, no. That's why they use RH and not Scientific Linux for their RAC cluster. Because for some specific applications, it isn't the same thing. But you'd probably already knew that, if you worked with both RHCE and one of the freely available RHCE-source-based distros.
And since their tools run on red hat they also run on centos and scientific Linux which are both free. Some lock in.
Their tools only run on RH-based systems (their words, not mine). Since both CentOS and Scientific Linux specifically depend from RH upstream, yeah, it's vendor lock-in. It's a bit like saying "this app can run on any MS Windows version, even if you create a customized version of it".
As far as disagreeing being a hate crime you obviously know something about that.
Yeah, I keep receiving comments from people that worry more about propaganda and brand stickers than facts and available choices. It's part of life, I guess.
If anything else would have been better to suit the scientists' at CERNs needs, they have been using it. They have a practically unlimited budget and they are extremely competent. They used the best tool available for the job. Why is this so contraversial? Because it treads on some people's "feelings" of what is better?
Maybe you should check the facts. Have a look at http://cdsweb.cern.ch/record/840543/files/lhcc-2005-024.pdf (page 77). They clearly explain why they chose Linux, and why they chose a RH-based version.
The article wasn't about how important was Oracle RAC in the discovery, it was about how important linux was. Fact is, the choice of the base operating system is almost irrelevant in the paper that details the Tier-1 infrastructure.
Why the need to bring out the strawmen? Nobody said anything different than what you are saying here and your arguments can be equally applied to anything under the sun.
It's not strawmen. When you say it is the best tool available for the job, you don't present facts. And no, just because the top clusters use it doesn't make it an ideal tool. The same way Windows isn't the perfect desktop, or Renault isn't the best auto manufacturer. However, if you do read the report, you'll find out they chose linux because they already used it internally, so for them it was the best choice.
No shit and a great algorithm coupled with the best kernel for the job is even better.
I'd say stock linux is probably miles away from "the best kernel" (from a pure technological perspective) for a numerical computing cluster (the scheduler is optimized for multi-process smp and responsive task switching, not single-process smp with almost no task switching and heavy latency requirements), but my experience with it is quite limited. A paralelizable algoritm on a given problem can reduce execution time 100x - do you really believe that choosing a different operating system (or kernel or whatever) makes a difference that big?
So, stating facts instead of debating ideologies is hate?
So an operating system that you can download for free (and, yes, you can download the source to red hat) is lock in now?
Did you even read the quote? The motive why they specifically use RH-based systems is because their tools don't run on any other linux distro. And no, you can't download the "source to red hat". You can, however, download *most of the source*, the (mostly) gpl-licensed code. That's why CentOS isn't a verbatim copy of RHES, but it does maintain binary compatibility.
Straight out of the proprietard F U D book. You've done well. Bonus points for the 'Linux zealot' phrase.
Meh. I tend to use the right tool for the job. Most of the time is BSD, sometimes is Linux, and in some rare occasions are proprietary solutions. But it seems that the idea that Linux isn't a key choice in everything is a hate crime for some people.
For a couple of years the CERN version has been based on the RedHat Linux
Distribution. RedHat changed their licensing policies in 2003 and they have been selling since
then their different Linux RH Enterprise versions on a profitable basis. After long
negotiations in 2003/2004 CERN decided to follow a four-way strategy:
collaboration with FNAL on Scientific Linux, a HEP Linux distribution based on the
re-compiled RH Enterprise source code, which RH has to provide without charge due
to the GPL obligations.
buying RH Enterprise licences for the Oracle on Linux service
having a support contract with RH
pursuing further negotiations with RH about possible HEP-wide agreements.
An investigation about alternative Linux distributions came to the conclusion that there was
no advantage in using SUSE, Debian or others. SUSE, for example, is still available free of
charge. However, the rather different implementation would require significant effort in
adapting our management tools. In addition there are question marks about the community
support.
CERN will continue with the described Linux strategy for the next couple of years. The
situation will be kept under continuous review.
So, they didn't choose generically Linux, but a RH-based version because of... wait for it... vendor lock-in. And to cut licensing costs, they decided to only license the copies that were related to their Oracle RAC cluster. If you read the report, you'll also find that not only they use a TON of internally-developed software, but also that the choice related to operating systems is almost irrelevant in the big picture. And please note, while the report has a bird-eye view of the whole structure, it only details the Tier-1 datacenter/computing grid. The data is accessible/replicated to dozens of computing grids all over the world (see http://en.wikipedia.org/wiki/Open_Science_Grid), and while most of them also run Linux (many of them are run by public entities with tight budgets such as universities and institutes), it seems to be more important what applicational software they run on it than what operating system is used. In a way, a zealot would be happy - it means that Linux seems to be ubiquous. Or irrelevant as a key choice. For me, it's all good.
It has been noted by others (in the article, for example) that Linux is the undisputed king of high-performance computing, in the public sector at least. My only assumption is that that is not random, that there are reasons for it.
If it wasn't Linux, it could be anything else. Even a heavily customized Minix version. Stuff got done before Linux prime time, and while it is a good choice now (for more than one reason), it isn't irreplaceable. And probably good algorithm design has far more consequences in performance than the choice of the operating system.
Linux development for hard realtime applications has far outstripped Solaris
Customized versions of Linux have far outstripped Solaris. And while Oracle seems to have realized the commercial potential of Sun Grid Engine, there are a whole lot of clusters (Linux, Solaris, BSD) using it to crunch numbers.
I find it a bit amusing the importance that people give to the "Linux" sticker on big clusters, specially when used in specialized applications that often translate to a heavily customized kernel and 1 userland binary. The fact that it (the kernel) is well documented, and have no licensing fees attached probably have more to do with the choice than the "technically superior" bullshit argument or the "windows/osx/whatever can't do that!" I often read here.
For me, it is easier - I roll my own infrastructure. And the notion of "better" varies wildly acording to your requirements. Shure, gmail may be a good fit for some workloads, but not for all of them - specially if you need to know why/where some specific email was filtered or discarded.
Have you tried greylisting? Another good approach is to have "dummy" easy-to-guess email accounts (such as anna@yourdomain.com) and use whatever you receive on it to train your bayesian filter or blacklist settings.
They are the same as the reasons why you shouldn't have GOTO statements, and these things were learned near the very beginnings of the study of programming as a discipline.
While I'm no fan of "goto" (or similar instructions) in high-level languages, the academic hatred for it is mostly based on dogmas, not facts. There are use cases for goto's, some algorithms will actually run faster (in some languages) and still be readable, and the notion that promotes sloppy code is, well, a dogma.
The biggest problem with "programming as a discipline", is that most times it is started from scratch - the students (and more often than not, the teachers) have no clue about how technology works, and they push structured concepts that really don't exist on a microprocessor level, and only later (if ever) they dwelve in how code is actually executed. The fact is, that for the most part, digital platforms rely mostly on "gotos" and "compares", and because those students started learning it "the high level way", they usually don't have a clue about the tradeoffs of choices like "using gotos". Instead they tend to pile up procedure calls and trash up stack and heap space, because that is "the right way" . Yes, I'm aware that this is PHP-related, and that some of the things I said don't apply, but I'd happly use a goto to prevent a function call on a demanding algorithm. Denying that possibility based on *no arguments* is dumb.
It is a stateless scripted language. Everything in the execution path can cause a denial-of-service. A typical example is the piss-poor search implementations in many many PHP sites - they fetch the limit-less dataset (regardless of size) and then they page it. Throw in a couple hundred searches like that, and you'll see the database server and the webserver crawling.
Other examples include "heavy" functions (such as regular expressions, file operations, etc), or even framework initialization - try accessing a non-existing page with a SEO-friendly url, and they will try to match it with all the router's rules.
Or, you know, just do some plain ol' HTTP requests to dynamic-generated pages from a fast pipe, and you'll have the same effect.
Re:a small and simple php script interpreter?
on
The PHP Singularity
·
· Score: 1
Well, most dependencies are module-related. You don't really need "modules" to build the basic interpreter. In fact, that is the way of doing things in FreeBSD (the PHP interpreter is standalone from all the modules, and each module is a separate port). Have a look at their ports tree and the supplied makefiles, it may give you some hints.
If the less usual operating systems you are porting to are unix-like, you may also try to use Pkgsrc (http://www.netbsd.org/docs/software/packages.html#platforms), a muti-platform ports tree.
What stuff? Sex with animals? Young girls selling their body?People eating feces? Orifices stretched to untold levels? Because you have all that equally accessible in the internet. The 80's magazines are mostly "adult girls with lots of hair showing their boobs", not the dick-filled asshole shaved barbies you'll find on many, many sites.
I was the one that was smart enough to dial up BBSes and d/l porn from there, and distribute it to friends in exchange for floppy disks
Most of the available d/l porn was scanned pictures from magazines, so nothing shocking there. Maybe in your time boobies were kept out of the tv, but nowadays they aren't. Go ahead, try to look for some "tasteful"/vintage porn on the internet without stumbling in incredible filth.
Slashdot Mirror
Can you scale up to 1,000 cores to meet a spike in demand and then back to 1 core when the demand drops
If you need realtime input data, you're screwed either way. Most applications don't scale well to 2 cores, let alone 1000. If I have a pretty popular website, I'd probably saturate my available network pipes long before the cpu power is a problem. Even good, fast and reliable storage is cheap, when compared to network connectivity.
any need to do significant demand-based scaling,
Let's say you are an somewhat obscure blog. You upload a video to your server that goes viral. How will Amazon solution scale so much better than the competition, if suddenly went viral (lets say 500k viewers)?
Been a client of them for >2 years (2 machines), and can only say good stuff. Good support, very attractive hardware packages, plenty of bandwidth, and for a little extra, you get "enterprise features" such as IP failover.
MySQL is lighter than PostgreSQL.
Define "lighter". Less resources? Because I usually get excellent performance out of PostgreSQL at a fraction of the memory needed for MySQL/InnoDB crap. I wouldn't describe as "light" the fact that, for a relatively complex schema such as Magento's, MySQL will usually eat up to 2x in memory the whole size of the database deliver a somewhat acceptable performance.
Certainly while I worked there, the company was absolutely happy to accept any WEEE goods from anyone, including those who hadn't bought anything from the shop. We had people coming in and giving us WEEE goods and then leaving without looking at anything. It seems to me that such a policy would only be in the company's interest if they were being paid by weight to do it.
Yeah, here in Portugal that is common practice too, but not in all stores, and not all items. We also have large recycle bins at the entrance of large shopping areas for small appliances, batteries and lamps. (And used kitchen oil too, but that's not relevant)
I was quite familiarized with WEEE regulations in my previous job, and the specifics of some of the EU countries (UK, Portugal, Spain, Germany, Italy and Czech Republic) - specially because I had to educate our (not-so-big) suppliers - and even some of our competitors - regarding the costs and obligations of warranty, WEEE/REEE taxes and the assorted requirements to be met when importing from Asian countries.
Retailers in the UK have, I think, had to collect WEEE goods under law for a while now
Retailers have to collect items they have sold, not items sold by others. From what I've depicted from the titlle (no I haven't read the article)m now retailers are obligated to collect an item, regardless of the origin.
I do know that retailers in the UK are paid by the weight of their electronic goods recycled, and not by their value in terms of rare earth metals and so on
I think you are mistaken. Retailers/manufacturers/importers pay by the weight and reciclability of what they sell. Additionally, you must pay an "importer fee" (it was 500 GBP, but may have changed) to then be able to pay per item sold. REEE regulation in EU is an absolute mess, because - long story short - there is no global market in electronics. As a retailer, you must be registered in every country you sell to, and - while the base law is the same - every country implements their own version, with their own fees, taxes and bureocracies. Small distributors are f**cked if they try to stay legal, and everyone else but the big importers just ignores it.
Its not in the florescent tubes or LED or whatever your LCD screen uses for illumination.
Actually, it is. Indium is used in the production of low-power led devices, and has been for decades (long before modern led-based screens). You can find a lot of information on Wikipedia, but also check http://www.lrc.rpi.edu/programs/futures/LF-LEDs/index.asp for an overview (they specifically mention white leds)
As such, it contributes to the feeling that Linux kernel development is an area in which women aren't welcome...
What feeling? Are the female kernel programmers leaving in droves because the kernel may be riddled with sexist remarks? Is it expected that a women in software development (which is mostly a male field) to be that sensitive about trivia? Do you forwn on using "tail", or putting a pipe in front of it? Do you steer away from large python packages, because it sounds dirty? Because, you know, 0xB16B00B5 isn't nowhere near BIGBOOBS as fsck is to fuck.
And believe it or not, sort of thing is the reason why there are so few female programmers.
...And yet, you have tons of females working in way more sexist environments, such as civil engineering, fashion, film industry, table serving or even the porn industry.
Our "tiny female brains" can cope with the actual work *just fine*.
Condescendent remarks only affect your credibility. If you are somewhat offended with the constant mentioned in the article, it's not because you are a woman - it's because you probably have serious social problems. Nothing wrong with that, but don't just assume "you speak for the woman".
Actually, I logged a bug with Oracle that the latest version of their database can't be troubleshot with strace or truss.
For each applicational bug that can't be easily traced/diagnosed at operating system level, you have dozens of performance issues/hiccups/misconfigurations that can. If you google "oracle strace", you'll find out that many people do use those tools for troubleshooting. If that wasn't the case, Oracle wouldn't be investing on them releasing a DTrace version for their Unbreakable Linux.
a developer to be tempted to store a UUID as a primary key in an InnoDB database
If you are using a UUID as a primary key on MySQL, is probably because you really need it (unique keys in cluster, ref to external databases, etc). And while it is slower than using a bigint, it's not that slower (you read from disk in 512 or 4096 byte blocks, and that is usually way more expensive than performing a 16-byte compare - so a sequential scan of a bigint and an UUID are probably similar).
It's also not always clear how to make full use of indexes ...
That's why there is an EXPLAIN clause in most RDBMs. You can see exactly how the query will be interpreted by the database. Of course, MySQL has its "nuances" regarding indexes, but that says more about the shortcomings of it than anything else.
You're absolutely right, though, that a competent developer would take the time to learn as much of this as possible.
The problem is, many DBAs aren't really developers. It's not that difficult to find a career DBA that don't understand how the underlying system works (let alone troubleshoot a problem with tools like strace or truss or even dtrace), or the consequences of paralelism and application lifecycle (let's do this on a almost non-documented, non-versioned stored procedure, to be run simultaneously by hundeds of users, and that will break at each version upgrade). I'm not trying to generalize it (good professionals and bad professionals exist in every field), but it reflects my experience. Is it just me?
As to AOL's distributed "NOC", the rationale for it is almost ludicrous.
And it's not even clever. Some "datacenter on a container" providers already exist, that go way beyond a couple of racks, have neatier insulation and are completely mobile if you need it. And if you want small, there are half-container solutions.
So are ISPs responsible for the packets they deliver?
To an extent, yes. I fully expect that my ISP won't send packets "in my name"(by using my allocated IP address to send spurious traffic) when I'm online. That basic principle is what allow the identification of persons using IP addresses and lease timestamps. If your ISP cannot guarantee that your data hasn't been tampered with in their infrastructure, then they cannot prove they are only a bystander if an online crime occurs. That's why they go to great lengths to log everything they can that can be useful in those situations, and to wrap the service in a binding contract where you agree preemptively in taking responsability for everything that can go wrong, even if it is vaguely their fault.
Is gmail responsible for the contents of the mail they store?
Yes they are. That's why, when you sign up, you agree to a series of legally binding terms and conditions - so they minimize their legal responsability. And they will happily deliver the contents of your mail box to the authorities if requested (and probably with a detailed log of what you send and received).
Is Fedex responsible for the contents of their deliveries?
I guess you never read their fineprint either. You usually have to describe the contents of the package, and you agree not to submit a series of stuff (explosives, propellants, some types of glass, dangerous chemicals, etc) using their courier service, and they do the minimum effort to identify you (the address when they pick it up, the CCTV recording when you go to the station, etc).
Now, compare this to a hypotetical charge because of freenode stuff:
Who sent you this? I don't know.
Do you keep records of it? I don't know.
To whom did you sent it? I don't know.
You get the idea...
You're not stating facts by calling people zealots. You are being insulting and spreading FUD.
So, citing an official paper is spreading FUD? Good to know.
And binary compatibility is what matters so, yes, you have the red hat source.
Well, no. That's why they use RH and not Scientific Linux for their RAC cluster. Because for some specific applications, it isn't the same thing. But you'd probably already knew that, if you worked with both RHCE and one of the freely available RHCE-source-based distros.
And since their tools run on red hat they also run on centos and scientific Linux which are both free. Some lock in.
Their tools only run on RH-based systems (their words, not mine). Since both CentOS and Scientific Linux specifically depend from RH upstream, yeah, it's vendor lock-in. It's a bit like saying "this app can run on any MS Windows version, even if you create a customized version of it".
As far as disagreeing being a hate crime you obviously know something about that.
Yeah, I keep receiving comments from people that worry more about propaganda and brand stickers than facts and available choices. It's part of life, I guess.
If anything else would have been better to suit the scientists' at CERNs needs, they have been using it. They have a practically unlimited budget and they are extremely competent. They used the best tool available for the job. Why is this so contraversial? Because it treads on some people's "feelings" of what is better?
Maybe you should check the facts. Have a look at http://cdsweb.cern.ch/record/840543/files/lhcc-2005-024.pdf (page 77). They clearly explain why they chose Linux, and why they chose a RH-based version.
The article wasn't about how important was Oracle RAC in the discovery, it was about how important linux was. Fact is, the choice of the base operating system is almost irrelevant in the paper that details the Tier-1 infrastructure.
Why the need to bring out the strawmen? Nobody said anything different than what you are saying here and your arguments can be equally applied to anything under the sun.
It's not strawmen. When you say it is the best tool available for the job, you don't present facts. And no, just because the top clusters use it doesn't make it an ideal tool. The same way Windows isn't the perfect desktop, or Renault isn't the best auto manufacturer. However, if you do read the report, you'll find out they chose linux because they already used it internally, so for them it was the best choice.
No shit and a great algorithm coupled with the best kernel for the job is even better.
I'd say stock linux is probably miles away from "the best kernel" (from a pure technological perspective) for a numerical computing cluster (the scheduler is optimized for multi-process smp and responsive task switching, not single-process smp with almost no task switching and heavy latency requirements), but my experience with it is quite limited. A paralelizable algoritm on a given problem can reduce execution time 100x - do you really believe that choosing a different operating system (or kernel or whatever) makes a difference that big?
Wow. You Linux haters reach more everyday.
So, stating facts instead of debating ideologies is hate?
So an operating system that you can download for free (and, yes, you can download the source to red hat) is lock in now?
Did you even read the quote? The motive why they specifically use RH-based systems is because their tools don't run on any other linux distro. And no, you can't download the "source to red hat". You can, however, download *most of the source*, the (mostly) gpl-licensed code. That's why CentOS isn't a verbatim copy of RHES, but it does maintain binary compatibility.
Straight out of the proprietard F U D book. You've done well. Bonus points for the 'Linux zealot' phrase.
Meh. I tend to use the right tool for the job. Most of the time is BSD, sometimes is Linux, and in some rare occasions are proprietary solutions. But it seems that the idea that Linux isn't a key choice in everything is a hate crime for some people.
The point is that it can be customized that way. Thanks for pointing out one of the reasons for CERN's choice.
Where did I said it couldn't?
BS.This is CERN we're talking about. They can afford whatever they want and they chose Linux.
If only there was a way to know for shure... Oh wait! There is! Citing from http://cdsweb.cern.ch/record/840543/files/lhcc-2005-024.pdf Page 78:
For a couple of years the CERN version has been based on the RedHat Linux Distribution. RedHat changed their licensing policies in 2003 and they have been selling since then their different Linux RH Enterprise versions on a profitable basis. After long negotiations in 2003/2004 CERN decided to follow a four-way strategy:
collaboration with FNAL on Scientific Linux, a HEP Linux distribution based on the re-compiled RH Enterprise source code, which RH has to provide without charge due to the GPL obligations.
buying RH Enterprise licences for the Oracle on Linux service having a support contract with RH
pursuing further negotiations with RH about possible HEP-wide agreements.
An investigation about alternative Linux distributions came to the conclusion that there was no advantage in using SUSE, Debian or others. SUSE, for example, is still available free of charge. However, the rather different implementation would require significant effort in adapting our management tools. In addition there are question marks about the community support.
CERN will continue with the described Linux strategy for the next couple of years. The situation will be kept under continuous review.
So, they didn't choose generically Linux, but a RH-based version because of... wait for it... vendor lock-in. And to cut licensing costs, they decided to only license the copies that were related to their Oracle RAC cluster. If you read the report, you'll also find that not only they use a TON of internally-developed software, but also that the choice related to operating systems is almost irrelevant in the big picture. And please note, while the report has a bird-eye view of the whole structure, it only details the Tier-1 datacenter/computing grid. The data is accessible/replicated to dozens of computing grids all over the world (see http://en.wikipedia.org/wiki/Open_Science_Grid), and while most of them also run Linux (many of them are run by public entities with tight budgets such as universities and institutes), it seems to be more important what applicational software they run on it than what operating system is used. In a way, a zealot would be happy - it means that Linux seems to be ubiquous. Or irrelevant as a key choice. For me, it's all good.
It has been noted by others (in the article, for example) that Linux is the undisputed king of high-performance computing, in the public sector at least. My only assumption is that that is not random, that there are reasons for it.
If it wasn't Linux, it could be anything else. Even a heavily customized Minix version. Stuff got done before Linux prime time, and while it is a good choice now (for more than one reason), it isn't irreplaceable. And probably good algorithm design has far more consequences in performance than the choice of the operating system.
Linux development for hard realtime applications has far outstripped Solaris
Customized versions of Linux have far outstripped Solaris. And while Oracle seems to have realized the commercial potential of Sun Grid Engine, there are a whole lot of clusters (Linux, Solaris, BSD) using it to crunch numbers.
I find it a bit amusing the importance that people give to the "Linux" sticker on big clusters, specially when used in specialized applications that often translate to a heavily customized kernel and 1 userland binary. The fact that it (the kernel) is well documented, and have no licensing fees attached probably have more to do with the choice than the "technically superior" bullshit argument or the "windows/osx/whatever can't do that!" I often read here.
For me, it is easier - I roll my own infrastructure. And the notion of "better" varies wildly acording to your requirements. Shure, gmail may be a good fit for some workloads, but not for all of them - specially if you need to know why/where some specific email was filtered or discarded.
Have you tried greylisting? Another good approach is to have "dummy" easy-to-guess email accounts (such as anna@yourdomain.com) and use whatever you receive on it to train your bayesian filter or blacklist settings.
They are the same as the reasons why you shouldn't have GOTO statements, and these things were learned near the very beginnings of the study of programming as a discipline.
While I'm no fan of "goto" (or similar instructions) in high-level languages, the academic hatred for it is mostly based on dogmas, not facts. There are use cases for goto's, some algorithms will actually run faster (in some languages) and still be readable, and the notion that promotes sloppy code is, well, a dogma.
The biggest problem with "programming as a discipline", is that most times it is started from scratch - the students (and more often than not, the teachers) have no clue about how technology works, and they push structured concepts that really don't exist on a microprocessor level, and only later (if ever) they dwelve in how code is actually executed. The fact is, that for the most part, digital platforms rely mostly on "gotos" and "compares", and because those students started learning it "the high level way", they usually don't have a clue about the tradeoffs of choices like "using gotos". Instead they tend to pile up procedure calls and trash up stack and heap space, because that is "the right way" . Yes, I'm aware that this is PHP-related, and that some of the things I said don't apply, but I'd happly use a goto to prevent a function call on a demanding algorithm. Denying that possibility based on *no arguments* is dumb.
It is a stateless scripted language. Everything in the execution path can cause a denial-of-service. A typical example is the piss-poor search implementations in many many PHP sites - they fetch the limit-less dataset (regardless of size) and then they page it. Throw in a couple hundred searches like that, and you'll see the database server and the webserver crawling.
Other examples include "heavy" functions (such as regular expressions, file operations, etc), or even framework initialization - try accessing a non-existing page with a SEO-friendly url, and they will try to match it with all the router's rules.
Or, you know, just do some plain ol' HTTP requests to dynamic-generated pages from a fast pipe, and you'll have the same effect.
Well, most dependencies are module-related. You don't really need "modules" to build the basic interpreter. In fact, that is the way of doing things in FreeBSD (the PHP interpreter is standalone from all the modules, and each module is a separate port). Have a look at their ports tree and the supplied makefiles, it may give you some hints.
If the less usual operating systems you are porting to are unix-like, you may also try to use Pkgsrc (http://www.netbsd.org/docs/software/packages.html#platforms), a muti-platform ports tree.
You still haven't written any code. Keep reading that hello world tutorial. :D
STILL figured out how to access the stuff
What stuff? Sex with animals? Young girls selling their body?People eating feces? Orifices stretched to untold levels? Because you have all that equally accessible in the internet. The 80's magazines are mostly "adult girls with lots of hair showing their boobs", not the dick-filled asshole shaved barbies you'll find on many, many sites.
I was the one that was smart enough to dial up BBSes and d/l porn from there, and distribute it to friends in exchange for floppy disks
Most of the available d/l porn was scanned pictures from magazines, so nothing shocking there. Maybe in your time boobies were kept out of the tv, but nowadays they aren't. Go ahead, try to look for some "tasteful"/vintage porn on the internet without stumbling in incredible filth.
ghuy'cha