I graduate from my PhD program this May (*epic sighs of relief*), and have a lot of friends who are going the PhD route.
Some of them have a good time, more of them have been having a bad time. PhD programs have something like 50% dropout rates, and if you finally do graduate the job market sucks.
Regardless of how well you like it, you will work your ass off. It will consume the next five years of your life, and that's before you even hit "real life".
I actually had a pretty easy time during most of the first or two of my program -- I didn't find the coursework difficult and the research load was not yet high. My then girlfriend (now wife) and I would go to restaurants as much as we could afford, do things outdoors, do things in the city; we just generally had an amazing time of it. Then, we both got slammed as I entered the heavy research phase and she started to get slammed in medical school. When we graduate I'll get a job and she'll go right into residency.
I told you all that to tell you that for a time, I worked less hard than I could have and did as much fun stuff as possible (within reason), and I don't regret it for a moment. The fond memories I have of the time still cheer me up today, and I wouldn't trade them for anything.
If I issue a 250 Queued response, it means that the email coming in is actually going to be deposited in a user's mailbox, otherwise the sender is notified by some component of the sending mail system.
Not only does this make the failure message itself more reliable, but it makes the sending user more likely to complain to his/her own IT department, as that's where the bounce message will likely be sourced from.
I'm a PhD student and this is completely true; mod parent up.
A small portion of the time, someone writes a tool with the intention of writing a tool for community use, and that can sometimes end well.
Other times, someone writes something and it ends up becoming popular, and is usually hacked upon and hacked upon when it should just be rewritten from scratch with the intention of being publicly consumed.
In any event, it is not often that academia will pay for either of the two above items; academia simply isn't about writing software.
I don't know to what extent it would apply to suburbanites having a breakdown (small # of total killings, probably no access to criminal enterprise), but with respect to the people killing each other in Detroit and elsewhere (large # of killings, often gang affiliated), I am sure you would see a black market for ammo pop up for this kind of thing. Once you make ammo hard to buy, it's going to be profitable for someone else to set up shop and sell it to the murderers -- it's not like your average meth addict is capable of cooking it him/herself.
Making homemade bullets is extremely simple -- there are lots of people into reloading and the tools required to cast bullets are few and (relatively) inexpensive.
If you are referring to making an entire cartridge (bullet,casing,primer,etc) yourself, that is harder but still quite doable -- google "expedient homemade ammo"
Charles Whitman was both an engineering student and a former marine, I would be very surprised if he (for instance) had not been exposed to reloading at the very least.
When was the last time any private individual actually used 10,000 bullets effectively to do damage?
The VAST majority of killings take place using cheap handguns, and if you're OK with home-made bullets, then you're OK will all the bullets any small-time (or even mass) killer will need.
Even the worst shootings have only actually used on the order of 100 bullets, I easily use triple that in a single trip to the range.
The reason this is a problem at all is because TCP was developed for wired networks in which packet loss was almost always a signal of congestion -- and therefore the logical response was to reduce the rate.
In these newfangled wireless networks losses can be completely random, yet TCP will still assume that congestion is responsible and reduce its rate. So, the answer is to either change TCP or do correction at a lower layer to "hide" the losses from TCP -- and, this has been a subject of research in networking for years now.
Linear coding certainly isn't new -- it has been proposed for a variety of things -- including but not limited to bittorrent, to reduce the reliance on receiving a specific block and rather on simply receiving "enough" information.
So yes, it is all well and good that we are applying this technique to TCP to reduce the impact of random, noncongestion losses, but there had better be something pretty magical in the way they do it for it to be (IMO) novel enough to be patentable/licensable/etc.
A number of people seem to be confusing the overall musopen library with the recently completed project.
Musopen has been around for some time collecting non-copyrighted performances of various classic works from whatever source was available. For example, you'll note from the musopen page that the Pictures at an Exhibition was performed by the Skidmore College Orchestra.
The Kickstarter project musopen undertook was to professionally record a few of the classics. On the Musopen site, you'll see "Musopen Symphony Orchestra" listed as the performer -- those pieces are listed here: http://musopen.org/music/by/performer/Musopen-Symphony-Orchestra
From my understanding the moonlight sonata wasn't even one of the pieces performed by the orchestra in the kickstarter campaign? It isn't listed at any of the links in the article. Musopen compiles a bunch of different music from many sources and so some if it is complete crap, but my impression was that the point of this project was to get some better recordings of a select group of pieces.
This stuff has been around for a while, and I have the following problems with it:
1. We already pretty much have CCN. They're called URLs, and companies like Akamai and others do a great job of dynamically pointing you to whatever server you should be talking to using DNS, HTTP redirects, etc. When I type www.slashdot.org, I already don't care what server it lives on. When I type https://www.slashdot.org/ I still dont care what server it is on, and I have at least some indication that the content is from someone authorized to speak on behalf of www.slashdot.org (PKI crap aside)
2. The article mentions that this tech would be used to relieve load at the core -- which I'm not sure I buy. The core is well known to be overprovisioned, and a recentish survey http://techcrunch.com/2011/05/17/netflix-largest-internet-traffic/ has shown that netflix and youtube consume 40% of downstream bytes -- both services already serviced by major CDNs pushing at least some traffic away from the core.
3. I'm unclear on the value proposition for us to redesign every router to be effectively, an HTTP proxy cache. These devices are well studied and even if we got a higher cache-hit-rate using CCN, I'm not convinced it would help anything. After all, we are doing just fine.
4. I think this approach is in the end, fundamentally wrong. Regardless of how much magic we use to find out what machine to get data from, we will always be transferring data from one computer to another (a caching router is effectively a computer). It seems to me that until we no longer need to move packets from some machine A to some other machine B, it makes sense to have host-centric primitives, and build our abstractions on top of them. That's what we've been doing, and it's been working pretty well.
However you are repeating what I also find to be a common misconception -- that latency is king. Will a SAN every beat the latency of a directly attached set of disks? No way, but it shouldn't be that far off. The rule of thumb I've heard (and observed in our environment) is that SAN latency is generally OK when under 10ms, which isn't much more than 2x the random access time on a spinning disk. Most of the time I have seen a SAN be significantly slower, it is because of a misconfiguration.
The above having been said, assuming latency is OK, it's hard to beat the spindle count on a SAN. If you need 5000 IOPS on a disk volume, are you going to directly attach dozens of disks to a single server? I doubt it. Directly-attached storage is nice, but apps have an IOPS requirement, and SANs make satisfying those requirements more straightforward, and no reduction in latency will make your random seeks faster.
I've done a bunch of consulting for the K-12 public sector and I have to say that educational software is some of the most poorly thought-out software ever (from an IT Admin's perspective).
Much of the software's installation guide goes something along the lines of "go to each computer and put in the disk", making deployment a massive headache. Those that actually come with a networking component usually require Everyone/FullControl permissions on the server share because the software was coded with the assumption it should have access to everything. Furthermore, I recently saw one where the application had a "server" component, but that component had to be manually run from a logged-on console session on a server, most kinds of automation would fail.
I always assumed that essentially off of this stuff was already outsourced due to the abysmal quality across the board. I guess I'd argue to keep as much in-house as possible so things don't get worse, but that would be pretty hard.
I know this comes off as a rant and it is, but if you write educational software, please actually think about the people that will have to deploy and run it while you're designing, whether you code it yourself or send it to India.
So somebody else correct me if I'm wrong here, but on a dramatic number of their demonstrations it looked like they didn't have much more data than the amount my which their curve was shifted -- only in a few instances did it really change shape dramatically.
Moreover, it appeared as if the amount of the shift of the curve was directly proportional to how much the object was being touched. Part of me wonders if they were really essentially calibrating these "gestures" based upon the amount of contact with the device in question. E.g., two fingers will of course result in more contact than one, but less than an entire palm. The whole "we can detect how the object is being grasped" thing seemed contrived.
Not that it wasn't cool -- there are definitely uses for this -- but it doesn't seem to me like they're getting quite as much data as they seem to be implying.
While the Executive branch's job is to enforce the laws, it gets a little muddy when it comes to the other branches. Technically, it is Congress' job to police the membership of all the branches (only Congress has the power to impeach members, and it may impeach the members of any branch).
So here's to waiting for Congress to do something about it:)
Slashdot Mirror
Not from the other side :)
I graduate from my PhD program this May (*epic sighs of relief*), and have a lot of friends who are going the PhD route.
Some of them have a good time, more of them have been having a bad time. PhD programs have something like 50% dropout rates, and if you finally do graduate the job market sucks.
Regardless of how well you like it, you will work your ass off. It will consume the next five years of your life, and that's before you even hit "real life".
I actually had a pretty easy time during most of the first or two of my program -- I didn't find the coursework difficult and the research load was not yet high. My then girlfriend (now wife) and I would go to restaurants as much as we could afford, do things outdoors, do things in the city; we just generally had an amazing time of it. Then, we both got slammed as I entered the heavy research phase and she started to get slammed in medical school. When we graduate I'll get a job and she'll go right into residency.
I told you all that to tell you that for a time, I worked less hard than I could have and did as much fun stuff as possible (within reason), and I don't regret it for a moment. The fond memories I have of the time still cheer me up today, and I wouldn't trade them for anything.
This; a thousand times this.
If I issue a 250 Queued response, it means that the email coming in is actually going to be deposited in a user's mailbox, otherwise the sender is notified by some component of the sending mail system.
Not only does this make the failure message itself more reliable, but it makes the sending user more likely to complain to his/her own IT department, as that's where the bounce message will likely be sourced from.
I'm a PhD student and this is completely true; mod parent up.
A small portion of the time, someone writes a tool with the intention of writing a tool for community use, and that can sometimes end well.
Other times, someone writes something and it ends up becoming popular, and is usually hacked upon and hacked upon when it should just be rewritten from scratch with the intention of being publicly consumed.
In any event, it is not often that academia will pay for either of the two above items; academia simply isn't about writing software.
This. I recently set up a new name server and had to disable it for similar reasons.
Linux doesn't kill people, Linux users do!
I don't know to what extent it would apply to suburbanites having a breakdown (small # of total killings, probably no access to criminal enterprise), but with respect to the people killing each other in Detroit and elsewhere (large # of killings, often gang affiliated), I am sure you would see a black market for ammo pop up for this kind of thing. Once you make ammo hard to buy, it's going to be profitable for someone else to set up shop and sell it to the murderers -- it's not like your average meth addict is capable of cooking it him/herself.
Making homemade bullets is extremely simple -- there are lots of people into reloading and the tools required to cast bullets are few and (relatively) inexpensive.
If you are referring to making an entire cartridge (bullet,casing,primer,etc) yourself, that is harder but still quite doable -- google "expedient homemade ammo"
Charles Whitman was both an engineering student and a former marine, I would be very surprised if he (for instance) had not been exposed to reloading at the very least.
When was the last time any private individual actually used 10,000 bullets effectively to do damage?
The VAST majority of killings take place using cheap handguns, and if you're OK with home-made bullets, then you're OK will all the bullets any small-time (or even mass) killer will need.
Even the worst shootings have only actually used on the order of 100 bullets, I easily use triple that in a single trip to the range.
Now you are really no match for Tyrion Lannister!
"So, would you feel comfortable being judged by the online company you keep?"
That is pretty much how people are judged in real life too (minus the word online).
The reason this is a problem at all is because TCP was developed for wired networks in which packet loss was almost always a signal of congestion -- and therefore the logical response was to reduce the rate.
In these newfangled wireless networks losses can be completely random, yet TCP will still assume that congestion is responsible and reduce its rate. So, the answer is to either change TCP or do correction at a lower layer to "hide" the losses from TCP -- and, this has been a subject of research in networking for years now.
Linear coding certainly isn't new -- it has been proposed for a variety of things -- including but not limited to bittorrent, to reduce the reliance on receiving a specific block and rather on simply receiving "enough" information.
So yes, it is all well and good that we are applying this technique to TCP to reduce the impact of random, noncongestion losses, but there had better be something pretty magical in the way they do it for it to be (IMO) novel enough to be patentable/licensable/etc.
Wow this got modded up? =/
Furthermore, why didn't they just use actual backlit displays instead of some approximation? It's not like there is a shortage of them.
A number of people seem to be confusing the overall musopen library with the recently completed project.
Musopen has been around for some time collecting non-copyrighted performances of various classic works from whatever source was available. For example, you'll note from the musopen page that the Pictures at an Exhibition was performed by the Skidmore College Orchestra.
The Kickstarter project musopen undertook was to professionally record a few of the classics. On the Musopen site, you'll see "Musopen Symphony Orchestra" listed as the performer -- those pieces are listed here: http://musopen.org/music/by/performer/Musopen-Symphony-Orchestra
From my understanding the moonlight sonata wasn't even one of the pieces performed by the orchestra in the kickstarter campaign? It isn't listed at any of the links in the article. Musopen compiles a bunch of different music from many sources and so some if it is complete crap, but my impression was that the point of this project was to get some better recordings of a select group of pieces.
This stuff has been around for a while, and I have the following problems with it:
1. We already pretty much have CCN. They're called URLs, and companies like Akamai and others do a great job of dynamically pointing you to whatever server you should be talking to using DNS, HTTP redirects, etc. When I type www.slashdot.org, I already don't care what server it lives on. When I type https://www.slashdot.org/ I still dont care what server it is on, and I have at least some indication that the content is from someone authorized to speak on behalf of www.slashdot.org (PKI crap aside)
2. The article mentions that this tech would be used to relieve load at the core -- which I'm not sure I buy. The core is well known to be overprovisioned, and a recentish survey http://techcrunch.com/2011/05/17/netflix-largest-internet-traffic/ has shown that netflix and youtube consume 40% of downstream bytes -- both services already serviced by major CDNs pushing at least some traffic away from the core.
3. I'm unclear on the value proposition for us to redesign every router to be effectively, an HTTP proxy cache. These devices are well studied and even if we got a higher cache-hit-rate using CCN, I'm not convinced it would help anything. After all, we are doing just fine.
4. I think this approach is in the end, fundamentally wrong. Regardless of how much magic we use to find out what machine to get data from, we will always be transferring data from one computer to another (a caching router is effectively a computer). It seems to me that until we no longer need to move packets from some machine A to some other machine B, it makes sense to have host-centric primitives, and build our abstractions on top of them. That's what we've been doing, and it's been working pretty well.
However you are repeating what I also find to be a common misconception -- that latency is king. Will a SAN every beat the latency of a directly attached set of disks? No way, but it shouldn't be that far off. The rule of thumb I've heard (and observed in our environment) is that SAN latency is generally OK when under 10ms, which isn't much more than 2x the random access time on a spinning disk. Most of the time I have seen a SAN be significantly slower, it is because of a misconfiguration.
The above having been said, assuming latency is OK, it's hard to beat the spindle count on a SAN. If you need 5000 IOPS on a disk volume, are you going to directly attach dozens of disks to a single server? I doubt it. Directly-attached storage is nice, but apps have an IOPS requirement, and SANs make satisfying those requirements more straightforward, and no reduction in latency will make your random seeks faster.
I've done a bunch of consulting for the K-12 public sector and I have to say that educational software is some of the most poorly thought-out software ever (from an IT Admin's perspective).
Much of the software's installation guide goes something along the lines of "go to each computer and put in the disk", making deployment a massive headache. Those that actually come with a networking component usually require Everyone/FullControl permissions on the server share because the software was coded with the assumption it should have access to everything. Furthermore, I recently saw one where the application had a "server" component, but that component had to be manually run from a logged-on console session on a server, most kinds of automation would fail.
I always assumed that essentially off of this stuff was already outsourced due to the abysmal quality across the board. I guess I'd argue to keep as much in-house as possible so things don't get worse, but that would be pretty hard.
I know this comes off as a rant and it is, but if you write educational software, please actually think about the people that will have to deploy and run it while you're designing, whether you code it yourself or send it to India.
Impressive!
So somebody else correct me if I'm wrong here, but on a dramatic number of their demonstrations it looked like they didn't have much more data than the amount my which their curve was shifted -- only in a few instances did it really change shape dramatically.
Moreover, it appeared as if the amount of the shift of the curve was directly proportional to how much the object was being touched. Part of me wonders if they were really essentially calibrating these "gestures" based upon the amount of contact with the device in question. E.g., two fingers will of course result in more contact than one, but less than an entire palm. The whole "we can detect how the object is being grasped" thing seemed contrived.
Not that it wasn't cool -- there are definitely uses for this -- but it doesn't seem to me like they're getting quite as much data as they seem to be implying.
Except that self-defense is frowned upon in general in the UK and you are likely to be prosecuted for it.
Fuck you.
That is all.
While the Executive branch's job is to enforce the laws, it gets a little muddy when it comes to the other branches. Technically, it is Congress' job to police the membership of all the branches (only Congress has the power to impeach members, and it may impeach the members of any branch).
So here's to waiting for Congress to do something about it :)
We need to invent warp drive by 2063 to meet the Vulcans, but it's 2012 and we can't even get to the moon!