So I guess what I'm saying is, what's the point in studying abroad if your primary concern is the quality of your coursework? Nothing in the english/spanish world has the same opportunities in CS as the US, with few exceptions.
And there was a point in time when wireless bluetooth headsets looked dorky. They still do, however they have become somewhat accepted.
If they don't look dorky, they make you look like a self important asshole. Or you might get the best of both worlds and look like a dorky, self-important asshole.
I'm not certain but it appears to be checksumming data while it is moving around the kernel after a write or read call is made.
Seems like something that should be handled in hardware with ECC, but what do I know.
Kernel bugs can cause data to get corrupted and hardware ECC won't correct that. Likewise with transfers from memory to disk. Ultimately it'll need to be a hardware/software thing but the software portion is needed as well.
Anything with "grid" in it makes me think "designed by committee" and "sucks"... and the fact that the effort described in TFA was funded by the EU doesn't make me feel any better about it.
Maybe it would make more sense to wait until something like Hadoop takes over the world, then just standardize existing practice.
Hadoop doesn't work well for quite a few workloads like those handled by seti@home or boinc. Grids like TeraGrid, OSG, and EGEE are certainly working right now and doing real significant amounts of real work.
Yes, quite a bit of these grids are designed by committee but it's something that needs to be done in order to let people drop jobs onto a random cluster and expect it to work.
E.g. suppose you send a job to a cluster, how do you where your data and program will be, what sort of execution limits are there (can your job run for 4 hours,10 hours, 24, more?), which directories are locally mounted and available for holding temporary data, where and how do you transfer your 80GB of data, etc. All of these info needs to be advertised in a easily parsed format otherwise the grid becomes useless.
granted, if you own a larger network, you can extort smaller networks (and all of their customers) for money. but that makes Sprint the asshole, not Cogent. claiming that Cogent is in the wrong just because they've been de-peered in the past without actually examining the details of the conflict to see whether Sprint's claims make any sense is rather naive. this isn't like high school where one's merits are based on their popularity. getting picked on often doesn't automatically make you wrong.
If you have a larger network then you're probably handling more traffic on behalf of a smaller network than vice versa. By your rationale, any company or person that sets up a small network (e.g. 3 computers) should be able to get free connectivity from sprint or another backbone provider.
The way the peering thing usually works is when companies A and B decide to peer, they track the traffic that they pass to each other. If the traffic is roughly even then they don't charge each other for the peering. On the other hand, if things are lopsided such as 80% of the traffic being company A handling requests for company B's users, then company B usually is required to pay for the excess bandwidth that it's using.
That is exactly what I have been saying. Apollo was the heaviest lifter we had, it worked, and it worked great. What's wrong with pulling out the blue prints, updating some components and building a newer improved version of the Apollo system? Why is this so hard to figure out? It's certainly better than wasting 1600+++ pounds on shock absorbers, damn that is just plane stupid. It's not like this is rocket..oh wait...but still!
Because the blueprints and designs don't give you everything. There's a ton of additional work such as tools, dies, machinery, etc. needed to make the parts that are no longer around and which would need to be rebuilt and debugged.
Any modern system such as rockets, cpus, chips, etc. have a lot of ancillary things that are needed to build them. And that's ignoring the little tips and experience with what techniques work which is probably only known by the original engineers and builders.
Even today, if you were to give a company like TSMC or UMC the chip layout and designs for something like a pentium chip, there would still need to be a fairly long experimentation time (e.g. 1 year) before they could manufacture the chip in quantities because the company would have to fiddle around with chip masks and the making the chip to figure out the quirks and gotchas in making the chips. The Saturn V is a lot more complicated and a lot harder to debug than a cpu.
In a sport, you can say, "If I do X I will get Y number of points." In a judged competition, you can't do that.
I'm not saying that there is anything wrong with judged competitions, I'm just saying that they aren't sports.
In gymnastics, you know that given a certain routine you will get x points for technical difficulty, likewise if you make mistake y you use z points for execution.
That matches your definition of a sport fairly well.
That's a start, but then they can just keep you at the current version and when a new buffer overflow is found and an exploit created, then they hack you. Better validation of mirrors and package managers that check multiple repositories and compare the results are probably a more complete fix.
At least for yum, the software will randomly pick and check a different mirror each time it is run so unless you have subverted a large fraction of mirrors, you've managed to delay the update for a short time period at best.
The simple fix is to change the client so that it never regresses (e.g., never installs software older than what it already has installed).
That's good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.
You can force the package manager to install an older package by using a force option to account for this instance. But this option needs to be given and the default behaviour for most (all?) package manager is to never downgrade.
This works because some package manager software will download and use package metadata even if it's older than what's cached.
This doesn't work. If you have an outdated package metadata list then, the package manager won't try to download any packages since the installed packages on the system are as new or newer. If you have an up to date package metadata list but don't have the packages, the package manager will go to another repository and try to download the package from there when it notices your repository is missing the relevant packages.
I don't understand how the lenders tanked so quickly, since they were selling the loans as securities immediately after closing the deal. Can anyone shine a light on this for me? For instance, why is Countrywide up a creek, if they weren't left holding the bag? It would seem to me that Pension funds are where the real sh*tstorm would be, but that doesn't seem to be the case.
A lot of the lenders didn't have the money needed to make the loans. They would make loans, package them and sell them and the money that they made from selling the loans would finance the next batch of loans that they were packaging.
Without a steady cash flow from selling mortgages, they can't make any new loans. So when companies stopped buying mortgage securities, their cash flow dried up and they couldn't make any more loans. Game over.
Satellites have been falling ever since we started putting them up, its no real threat.
The reson we are doing this is obvious - to demonstrate to the world (and the Chinese) that was have functional ASAT capability.
I think the reason is more because various agencies are worried that the satellite will end up falling in someplace while Russia or China and the intact pieces will give these countries examples to reverse engineer or clues as to US capabilities. I believe the satellite is supposed to be the newest generation of spy sats so it's probably full of interesting little tech.
http://www.dcache.org/
You will need a system to act as a master, but otherwise your normal nodes should work great.
Dcache won't do what he wants it to and would require quite a bit of changes in applications that use it since the dcache filesystem is not posix compliant. Dcache 2.0 with chimera should present things as a nfs4.1 share but chimera has just been completed and I think no one but the developers have it running anywhere.
I have one better for you. W(hy)TF is the restriction on checked baggage and not on carry on baggage, if they think there is a safety issue?
"Why yes sir, those batteries are very, very dangerous. So please keep them as close to yourself and the other passengers as possible instead of storing them away safely in our baggage area."
If you read the article, they say that they prefer the batteries in carry-on luggage so that the cabin crews can extinguish the fire if the batteries do short. The fire suppression systems in the luggage compartment may not be able to handle this scenario.
Yes, indeed it is. Most Americans I have come in contact with pronounce it "kwork", whereas the Brits (including my lecturer in experimental particle physics) pronounce it "kwark". And btw, I have a PhD in physics too.
Most of the ATLAS and CMS people I've spoken with have pronounced it kwark. I'm in the US so these are mostly americans as well.
screw that! A gun that disables microprocessors?! I'm worried about more than stupid cop cars. In midflight, there goes planes, spaceships, satellites, and missiles...I'm too lazy to think of any more but how many guidance and propulsion technologies in transportation devices use microprocessors? A LOT!
As the distance to the microprocessor increases the power needed increases as the square of the distance. You can reduce that requirement a bit by focusing the beam but given the 100J requirement at 15 feet, trying to disable a plane 20,000 feet above you is going to need a lot of power. Disabling satellites is going to require enough power that you essentially need a dedicate power station.
He's not talking about the local bandwidth, within the supercomputer. He's talking about the bandwidth in and out of the supercomputer, to the rest of the internet. Most traditional supercomputering applications involve loading a large dataset, but just once, and then waiting a long time, and downloading a smaller result. Much less bandwidth, in terms of ISP bandwidth to the rest of the world, than say hosting youtube.
At least with particle physics those 1-5 petabytes of data need to be sent out to sites to be processed initially as well as later when someone wants to analyze events. Most institutions don't have a few petabytes of storage handy so if a local user needs to run an analysis that involves events x,y,z, the data concerning those events get pulled and transferred.
I'm sure similar things happen with the bioinformatics people so yes the data gets shuttled around pretty frequently.
one field where I think storing servers at the poles would be amazing is super computing. Supercomputers don't require the massive ammounts of bandwidth that webservers etc do.
Supercomputing absolutely requires massive amounts of bandwidth. In a particle physics, detectors at places like LHC are generating 1-5 petabytes of data each year and this data needs to be sent out to centers and processed. Likewise, bioinformatics applications tend to generate lots of data (sequences, proteins, etc.) and this data needs to be shuttled around while it's being processed.
Not entirely correct. Installation scripts and interfaces definition files must be included. Access to CVS/CVN of the code without these would not satisfy the GPL (v2).
Wasn't aware of that, but you still need the configuration files. E.g. sendmail.cf, httpd.conf, etc. for the various configurations. A lot of these are readily available but things like Selinux policy files, pam configurations, etc. are redhat specific and wouldn't need to be distributed or may be distributed using a restrictive license.
Red Hat is welcome to hold whatever opinion they want on whether they *like* CentOS to do what they do... but in the end, it's none of their damn business how someone else decides to distribute GPL'd code (within the license terms, of course... Red Hat is also a creator of a significant body of GPL code).
Redhat doesn't have to distribute the packaging or configuration information to satisfy the gpl. For example, they could provide a cvs or svn repository with just the code or tarballs of the source. The gpl would be satisfied, but it'd be very difficult to recreate the configuration information required to get a working system. E.g. the selinux policies required to get a working system would take a fairly large project in and of itself.
Wait, given that Java is Sun's baby, why does Apple have to provide anything? Java 6's lack of inclusion in Leopard just means that Apple doesn't want to keep up with it anymore. I'm pretty sure they announced they weren't going to maintain the Java bindings any longer, so that is why they didn't include it.
Why should it be included with the base OS? Some customers may prefer not to have the bloated JVM automatically installed.
Sun doesn't provide Java because Apple told them that Apple would do it since they wanted to integrate it with the system. That and Apple wanting OS X to be the premier os for java development is why it's included in the base OS. Unfortunately, that means that people on the mac are dependent on the whims of Apple and still don't have java 6 almost a year after it was released.
Im pretty sure games stress the whole system overall a lot more than any application im aware of. math problems and ray tracing and DV editing if im not mistaken are CPU exclusive operations. Im not an expert but high end graphics cards are more powerful than cpus, even if they are specialized. i cant think of any other application that will stress the CPU, GPU, RAM, HDD and everything else to 100% other than games.
You are mistaken. Take particle physics simulations for example. The system might be downloading a 10GB dataset to do the next simulation while it's working on simulations of a detector which involves working with the current dataset. The download would max out your net connection while the simulation work would max your cpu and require something like 2-3GB of ram. The two activities are probably generating a decent i/o load as well.
Same deal with audio or video processing, if you're streaming a video or audio source or two from an array, processing it and writing it back, well that's pretty much using everything. Given a raw video stream can be about 20MB/s, you're generating about 40MB/s of read/write per stream and you might be working with a few streams if you're trying to overlay two video sources or something. That's significantly more activity than a game will produce.
Oh my, 1 PFLOPS... that's not that big anymore. 4 years from now they should be talking 20+ PFLOPS at least.
There's a huge difference between a distributed system offering 1 PFLOPS and a tightly integrated system offering a fast interconnect and a petaflop of computing power. It's kinda of like saying a semitruck isn't all the impressive because you have a fleet of cars that have the same storage capacity. That's great until you need to move a large container or block of stuff that can't be parceled out...
Slashdot Mirror
So I guess what I'm saying is, what's the point in studying abroad if your primary concern is the quality of your coursework? Nothing in the english/spanish world has the same opportunities in CS as the US, with few exceptions.
I think studying in a foreign is something that you really should do. That way you'll realize that yes, the rest of the world has good educational opportunities and institutions. Unless you're attending someplace like MIT or Stanford, quite a few foreign universities match or beat anything you're attending. Between places like Oxford, Cambridge, Max Planck Institute, Ãcoles Normales Supérieures, undergrads can certainly find places that'll teach them cs.
And there was a point in time when wireless bluetooth headsets looked dorky. They still do, however they have become somewhat accepted.
If they don't look dorky, they make you look like a self important asshole. Or you might get the best of both worlds and look like a dorky, self-important asshole.
I'm not certain but it appears to be checksumming data while it is moving around the kernel after a write or read call is made.
Seems like something that should be handled in hardware with ECC, but what do I know.
Kernel bugs can cause data to get corrupted and hardware ECC won't correct that. Likewise with transfers from memory to disk. Ultimately it'll need to be a hardware/software thing but the software portion is needed as well.
Anything with "grid" in it makes me think "designed by committee" and "sucks"... and the fact that the effort described in TFA was funded by the EU doesn't make me feel any better about it. Maybe it would make more sense to wait until something like Hadoop takes over the world, then just standardize existing practice.
Hadoop doesn't work well for quite a few workloads like those handled by seti@home or boinc. Grids like TeraGrid, OSG, and EGEE are certainly working right now and doing real significant amounts of real work.
Yes, quite a bit of these grids are designed by committee but it's something that needs to be done in order to let people drop jobs onto a random cluster and expect it to work.
E.g. suppose you send a job to a cluster, how do you where your data and program will be, what sort of execution limits are there (can your job run for 4 hours,10 hours, 24, more?), which directories are locally mounted and available for holding temporary data, where and how do you transfer your 80GB of data, etc. All of these info needs to be advertised in a easily parsed format otherwise the grid becomes useless.
granted, if you own a larger network, you can extort smaller networks (and all of their customers) for money. but that makes Sprint the asshole, not Cogent. claiming that Cogent is in the wrong just because they've been de-peered in the past without actually examining the details of the conflict to see whether Sprint's claims make any sense is rather naive. this isn't like high school where one's merits are based on their popularity. getting picked on often doesn't automatically make you wrong.
If you have a larger network then you're probably handling more traffic on behalf of a smaller network than vice versa. By your rationale, any company or person that sets up a small network (e.g. 3 computers) should be able to get free connectivity from sprint or another backbone provider.
The way the peering thing usually works is when companies A and B decide to peer, they track the traffic that they pass to each other. If the traffic is roughly even then they don't charge each other for the peering. On the other hand, if things are lopsided such as 80% of the traffic being company A handling requests for company B's users, then company B usually is required to pay for the excess bandwidth that it's using.
That is exactly what I have been saying. Apollo was the heaviest lifter we had, it worked, and it worked great. What's wrong with pulling out the blue prints, updating some components and building a newer improved version of the Apollo system? Why is this so hard to figure out? It's certainly better than wasting 1600+++ pounds on shock absorbers, damn that is just plane stupid. It's not like this is rocket..oh wait...but still!
Because the blueprints and designs don't give you everything. There's a ton of additional work such as tools, dies, machinery, etc. needed to make the parts that are no longer around and which would need to be rebuilt and debugged.
Any modern system such as rockets, cpus, chips, etc. have a lot of ancillary things that are needed to build them. And that's ignoring the little tips and experience with what techniques work which is probably only known by the original engineers and builders.
Even today, if you were to give a company like TSMC or UMC the chip layout and designs for something like a pentium chip, there would still need to be a fairly long experimentation time (e.g. 1 year) before they could manufacture the chip in quantities because the company would have to fiddle around with chip masks and the making the chip to figure out the quirks and gotchas in making the chips. The Saturn V is a lot more complicated and a lot harder to debug than a cpu.
In a sport, you can say, "If I do X I will get Y number of points." In a judged competition, you can't do that.
I'm not saying that there is anything wrong with judged competitions, I'm just saying that they aren't sports.
In gymnastics, you know that given a certain routine you will get x points for technical difficulty, likewise if you make mistake y you use z points for execution.
That matches your definition of a sport fairly well.
That's a start, but then they can just keep you at the current version and when a new buffer overflow is found and an exploit created, then they hack you. Better validation of mirrors and package managers that check multiple repositories and compare the results are probably a more complete fix.
At least for yum, the software will randomly pick and check a different mirror each time it is run so unless you have subverted a large fraction of mirrors, you've managed to delay the update for a short time period at best.
That's good and all until you download a bleeding edge version that is buggy as hell and want to go back to the old version.
You can force the package manager to install an older package by using a force option to account for this instance. But this option needs to be given and the default behaviour for most (all?) package manager is to never downgrade.
This works because some package manager software will download and use package metadata even if it's older than what's cached.
This doesn't work. If you have an outdated package metadata list then, the package manager won't try to download any packages since the installed packages on the system are as new or newer. If you have an up to date package metadata list but don't have the packages, the package manager will go to another repository and try to download the package from there when it notices your repository is missing the relevant packages.
A lot of the lenders didn't have the money needed to make the loans. They would make loans, package them and sell them and the money that they made from selling the loans would finance the next batch of loans that they were packaging.
Without a steady cash flow from selling mortgages, they can't make any new loans. So when companies stopped buying mortgage securities, their cash flow dried up and they couldn't make any more loans. Game over.
The reson we are doing this is obvious - to demonstrate to the world (and the Chinese) that was have functional ASAT capability.
I think the reason is more because various agencies are worried that the satellite will end up falling in someplace while Russia or China and the intact pieces will give these countries examples to reverse engineer or clues as to US capabilities. I believe the satellite is supposed to be the newest generation of spy sats so it's probably full of interesting little tech.
Dcache won't do what he wants it to and would require quite a bit of changes in applications that use it since the dcache filesystem is not posix compliant. Dcache 2.0 with chimera should present things as a nfs4.1 share but chimera has just been completed and I think no one but the developers have it running anywhere.
"Why yes sir, those batteries are very, very dangerous. So please keep them as close to yourself and the other passengers as possible instead of storing them away safely in our baggage area."
If you read the article, they say that they prefer the batteries in carry-on luggage so that the cabin crews can extinguish the fire if the batteries do short. The fire suppression systems in the luggage compartment may not be able to handle this scenario.
Most of the ATLAS and CMS people I've spoken with have pronounced it kwark. I'm in the US so these are mostly americans as well.
Shouldn't they be upset at Sun? Why is Apple getting the flack?
Because Apple told Sun not to work on a jdk for mac os x since apple would produce and maintain it.
As the distance to the microprocessor increases the power needed increases as the square of the distance. You can reduce that requirement a bit by focusing the beam but given the 100J requirement at 15 feet, trying to disable a plane 20,000 feet above you is going to need a lot of power. Disabling satellites is going to require enough power that you essentially need a dedicate power station.
At least with particle physics those 1-5 petabytes of data need to be sent out to sites to be processed initially as well as later when someone wants to analyze events. Most institutions don't have a few petabytes of storage handy so if a local user needs to run an analysis that involves events x,y,z, the data concerning those events get pulled and transferred.
I'm sure similar things happen with the bioinformatics people so yes the data gets shuttled around pretty frequently.
Supercomputing absolutely requires massive amounts of bandwidth. In a particle physics, detectors at places like LHC are generating 1-5 petabytes of data each year and this data needs to be sent out to centers and processed. Likewise, bioinformatics applications tend to generate lots of data (sequences, proteins, etc.) and this data needs to be shuttled around while it's being processed.
Wasn't aware of that, but you still need the configuration files. E.g. sendmail.cf, httpd.conf, etc. for the various configurations. A lot of these are readily available but things like Selinux policy files, pam configurations, etc. are redhat specific and wouldn't need to be distributed or may be distributed using a restrictive license.
The files aren't covered by gpl, so why would the subscriber or centos have the rights needed to distribute that information?
Redhat doesn't have to distribute the packaging or configuration information to satisfy the gpl. For example, they could provide a cvs or svn repository with just the code or tarballs of the source. The gpl would be satisfied, but it'd be very difficult to recreate the configuration information required to get a working system. E.g. the selinux policies required to get a working system would take a fairly large project in and of itself.
Why should it be included with the base OS? Some customers may prefer not to have the bloated JVM automatically installed.
Sun doesn't provide Java because Apple told them that Apple would do it since they wanted to integrate it with the system. That and Apple wanting OS X to be the premier os for java development is why it's included in the base OS. Unfortunately, that means that people on the mac are dependent on the whims of Apple and still don't have java 6 almost a year after it was released.
You are mistaken. Take particle physics simulations for example. The system might be downloading a 10GB dataset to do the next simulation while it's working on simulations of a detector which involves working with the current dataset. The download would max out your net connection while the simulation work would max your cpu and require something like 2-3GB of ram. The two activities are probably generating a decent i/o load as well.
Same deal with audio or video processing, if you're streaming a video or audio source or two from an array, processing it and writing it back, well that's pretty much using everything. Given a raw video stream can be about 20MB/s, you're generating about 40MB/s of read/write per stream and you might be working with a few streams if you're trying to overlay two video sources or something. That's significantly more activity than a game will produce.
There's a huge difference between a distributed system offering 1 PFLOPS and a tightly integrated system offering a fast interconnect and a petaflop of computing power. It's kinda of like saying a semitruck isn't all the impressive because you have a fleet of cars that have the same storage capacity. That's great until you need to move a large container or block of stuff that can't be parceled out...