There's a difference between "high speed" and "on-demand maximum bandwidth with low latency".
No application that I know of needs both "maximum bandwidth" and "low latency", except maybe a live HDTV stream. Gaming needs reasonable bandwidth and low latency - that shouldn't be hard to provide on a university network.
I suspect most dorm telecom fees don't begin to cover it. If they did, students who just want basic high speed web and email access would be up in arms, since they'd be paying for network capacity they don't use.
I pay $70/semester (3 months) for my dorm telecom fee - and internet connectivity is the only telecom service I use. 3 meg/768k DSL is $35/month (or $105/semester). Taking into account the economies of scale for the 800 students in my dorm building alone, it seems reasonable to expect that the school should be able to provide network service at least equivalent to the DSL I mentioned - and here at my school, they normally do. It should be pretty similar at other schools.
Even if the problem is one of not charging the students enough for the network connectivity they want to use, degrading specific applications still isn't the solution. The correct solution is a QOS configuration that doesn't break applications combined with reasonable high-bandwidth charges. If one user downloads 150 gigs in one day there is no problem if the download was QOSed to bulk and the user was charged a couple bucks for the high bandwidth usage.
I might be naive to say this, but by the 70s, modern science was rapidly approaching its limits (at least on the frontiers that were being explored at the time)
Saying that "science has reached it's limit" today is just as foolish as saying it in 1907 or 1807 would have been (and people did). It can be hard for a non-scientist to understand what current research consists of, and it can be even harder for a non-scientist to guess at what of current research will directly result in visible applications, but that doesn't mean that science has stopped - just that you can't see it move.
One of the most important things to learn about computers is that you can never actually beat them. Sometimes they can beat you, but the best you can do is force a draw.
Guy had a network problem. Network admins found the source of the network problem. People who caused the network problem complained, everyone else was happy.
School had a misconfigured network and a capacity shortage. Network admins broke a commonly used application in response rather than either buying more capacity or properly configuring their network.
This is old news for those of us who use P2P protocals for file downloads. The news here is that the "most usage is probably illegal anyway" excuse for degrading specific applications is just an excuse - they'll happily come up with other excuses when that one doesn't fit for the application they want to break.
You're saying that it's even vaguely excusable for a dorm network to not have good enough connectivity to handle some students playing video games?
Seriously, we could have an interesting discussion about how appropriate it is for a dorm resident to be downloading 150 gigs/week off Usenet, but it's perfectly reasonable for them to expect to have a functional network connection that they can use. I mean... they do *live* there and pay good money to do so - usually including a telecommunications fee that more than covers the cost of a high speed network connection.
The general geek perception is that the machine is a piece of shit. Unless you happen to work for Microsoft or have devoted your life to being it's love slave.
That's the Sony / Nintendo fanboy perception, which differs from the "General Geek Perception". Now, all three of the current-generation consoles are DRM infested crap... but console fanboys seem to be willing to ignore that.
Once you accept that any console is worth buying, each of the three have their advantages and disadvantages - that end up making any of the three a perfectly defensible choice.
The 360 has decent graphics, has Halo 3, is cheaper than the PS3, and has good games. That's enough for a lot of people.
This is mostly a problem with solar cells because storing electricity is really hard. If you could buffer the energy from a solar installation, you'd only need one twice (or three times) the size in order to generate a constant power output even at night. If cloudy days are a problem, figure that in.
Interestingly, there are plant designs that do allow the energy to be buffered - and that are potentially cheaper than solar cells for large installations: see http://en.wikipedia.org/wiki/Solar_thermal_energy, especially the parabolic trough bit.
Also, the nuclear waste can now be reprocessed into usable material.
This requires breeder reactors. Which are illegal in the US. And not new tech - hell, some of the first reactors in the 50's and 60's were breeding designs. The possibility to recycle spent fuel with good reactor technology at some undetermined point in the future is not an excuse to put in crappy PWRs or BWRs that can't recycle anything. We have enough highly radioactive used-once nuclear fuel lying around that any new plant that can't burn it is unacceptable.
They must include the expenses for keeping nuclear waste in safety from leaks,..., the expenses to cure people when depleted uranium is dumped into the environment during wars and so on.
"Waste" and depleted uranium are both unused nuclear fuel. If we just used proper breeding reactors, we'd reduce the volume of that stuff that we need to deal with by at least a factor of 10 - and we'd reduce the lifetime of the remaining waste to a couple of hundred years.
The money supply is increased by ONE WAY and ONE WAY ONLY! When a bank issues a loan, the loan itself is money "created" with the debt ultimately reported to the Fed.
What is the functional difference between that and the issuance of government bonds?
Although Firefox does have some issues with memory usage (and occasionally memory leaks), that doesn't seem the be the primary cause of usability issues.
In my personal experience with Firefox, I see two problems:
The whole browser locks up if a bit of JavaScript is slow - even if it's just one tab being slow out of ten.
The whole browser locks up if a plug-in or extension locks up - even if the plug-in is in just one tab out of ten.
Both of these problems could be solved relatively easily with threads (in a number of different ways), but for some reason the Firefox developers have an irrational paranoia of anything that even vaguely resembles native concurrency. They say "the real problem is just response time, if we can respond fast enough in a single thread it's the same" - but then they never actually do it, and they definitely don't do anything that would let them recover from component crashes.
You are, effectively, saying we can't know anything about anything, until we've go through it. The same could be argued for property rights, murder, etc. If you have no other point than to argue that nobody can know anything, your argument is worthless.
That's a reasonable argument against mine. It doesn't change the fact that controversial claims without anything provided to back them are worthless.
I'm just mentioning Digg because the dynamic comment system is a great test of 2D acceleration in Firefox. When you click "expand thread", it does a little accelerating expansion animation (and animation means drawing a bunch of animation frames).
I'd actually be really interested to find out how Firefox on the PS3 handles that. It's been my personal test for 2D acceleration quality for a while now.
It runs Linux like crap because it doesn't provide access to hardware accelerated graphics. And by "hardware accelerated graphics", I don't just mean 3D games and Compiz. It doesn't even have 2D acceleration, so you'll see redraw lag just scrolling in Firefox.
Basically Linux compatibility was just a scheme to get into a different import tax bracket in the European Union (where computers have a lower tax than video game consoles or media players). Actual usability wasn't a design goal.
How else would you name these things so as to communicate A.) what type of chip is it (entry level, mainstream, or high end) and B.) the model number of the chip and C.) the basic technical information that people want (i.e. "quad core")?
Nah, we'll have quantum computers that can zoom through any encryption we come up with today.:)
Contrary to the reports from some sensationalist tech journalists, quantum computers don't magically obsolete today's encryption algorithms. Take a look at the Wikipedia article for details. To summarize, for algorithms like AES, a quantum computer may be able to attack keys as much as twice as long as the keys that a classical computer can attack - margins of error that large are built into many systems that use such algorithms in practice.
For simple selects, rails provide the find class function, which is nice, but even relatively simple stuff like selecting on a date, asking for a specific month is not possible without sql fragments.
What's wrong with entries.find(:all,:conditions => [:month => 6])?
Depending on those variables it usually winds up being either PHP or Cold Fusion. Ruby on Rails has never once been a consideration.
The only way that you could get to those results given those criteria would be that you have a bunch of PHP and Cold Fusion developers on staff who push those choices. They aren't leading contenders on Development Time, Budget, or # of Developers - and they're about equal to any of the other contenders on the other points.
From what I've seen, the only real criteria that anyone ever uses in choosing a development environment is this: What are the developers used to. A runner up is "what has the manager seen hyped in trade publications" - but that never works out well.
This is probably a reasonable result. In practice, the differences between development environments in terms of the 6 points mentioned by the parent are pretty small. You might get an order of magnitude difference in #1, #5, and #6 in Java vs. Ruby for example - but you'll never convince a Java developer of that (or they'll claim an order of magnitude performance difference that rarely matters in practice). Hell, even writing an LDAP client library from scratch in Common Lisp (for example) is probably far cheaper than trying to get a team of Lisp programmers to move to ASP.NET or whatever.
As an example, it is very easy to do a select by going through all the records in the db. And in rails, that way might look better... no sql fragments and so on.
This is just an issue of poor programming (or FUD). The idea that the Rails developers wouldn't provide the ability to select specific records out of a table is absurd, and any developer who selects the whole table and manually searches instead is incompetent.
As for ruby being slow, this is a much smaller deal than you'd expect. Most of these apps are database limited anyway - things like Rails caching will probably have a larger positive effect being able to execute less ruby instructions per microsecond.
Catalyst is neat, but it doesn't have the single big advantage that Rails or Django has: Lack of choice (aka sane defaults). If there's one way to do it, you do it that way and you're done. If there are five ways to do it, you spend a day trying to figure out which way is better - and then later find out that some other component assumes you did it one of the ways you didn't chose.
Now, when the sane defaults in Rails don't fit the bill, or when you really need some Perl libraries, or if you really need the factor-of-five speedup in the web app code that you can get from mod-perl, then Catalyst is the obvious choice. But for a new application that's database-performance limited anyway, being lazy (and using Rails) is the ultimate plan.
I won't have to spend money buying another server once I get a few thousand daily visitors.
No programming language is so inefficient that you'll notice a performance difference in a web app for thousands of daily visitors. Not PHP vs. Ruby. Not a Scheme interpreter written in Visual Basic 2.0 vs. hand tuned assembly language. Web app throughput is measured in requests per second on modern servers (usually thousands or tends of thousands, but maybe hundreds for the Scheme in VB thing), and there are 86,400 seconds in a day.
Slashdot Mirror
No application that I know of needs both "maximum bandwidth" and "low latency", except maybe a live HDTV stream. Gaming needs reasonable bandwidth and low latency - that shouldn't be hard to provide on a university network.
I pay $70/semester (3 months) for my dorm telecom fee - and internet connectivity is the only telecom service I use. 3 meg/768k DSL is $35/month (or $105/semester). Taking into account the economies of scale for the 800 students in my dorm building alone, it seems reasonable to expect that the school should be able to provide network service at least equivalent to the DSL I mentioned - and here at my school, they normally do. It should be pretty similar at other schools.
Even if the problem is one of not charging the students enough for the network connectivity they want to use, degrading specific applications still isn't the solution. The correct solution is a QOS configuration that doesn't break applications combined with reasonable high-bandwidth charges. If one user downloads 150 gigs in one day there is no problem if the download was QOSed to bulk and the user was charged a couple bucks for the high bandwidth usage.
Saying that "science has reached it's limit" today is just as foolish as saying it in 1907 or 1807 would have been (and people did). It can be hard for a non-scientist to understand what current research consists of, and it can be even harder for a non-scientist to guess at what of current research will directly result in visible applications, but that doesn't mean that science has stopped - just that you can't see it move.
One of the most important things to learn about computers is that you can never actually beat them. Sometimes they can beat you, but the best you can do is force a draw.
School had a misconfigured network and a capacity shortage. Network admins broke a commonly used application in response rather than either buying more capacity or properly configuring their network.
This is old news for those of us who use P2P protocals for file downloads. The news here is that the "most usage is probably illegal anyway" excuse for degrading specific applications is just an excuse - they'll happily come up with other excuses when that one doesn't fit for the application they want to break.
You're saying that it's even vaguely excusable for a dorm network to not have good enough connectivity to handle some students playing video games?
Seriously, we could have an interesting discussion about how appropriate it is for a dorm resident to be downloading 150 gigs/week off Usenet, but it's perfectly reasonable for them to expect to have a functional network connection that they can use. I mean... they do *live* there and pay good money to do so - usually including a telecommunications fee that more than covers the cost of a high speed network connection.
That's the Sony / Nintendo fanboy perception, which differs from the "General Geek Perception". Now, all three of the current-generation consoles are DRM infested crap... but console fanboys seem to be willing to ignore that.
Once you accept that any console is worth buying, each of the three have their advantages and disadvantages - that end up making any of the three a perfectly defensible choice.
The 360 has decent graphics, has Halo 3, is cheaper than the PS3, and has good games. That's enough for a lot of people.
That's true. Someone should get on that. But until they do, I'm not sure that building more archaic non-recycling reactors is a good idea.
This is mostly a problem with solar cells because storing electricity is really hard. If you could buffer the energy from a solar installation, you'd only need one twice (or three times) the size in order to generate a constant power output even at night. If cloudy days are a problem, figure that in.
Interestingly, there are plant designs that do allow the energy to be buffered - and that are potentially cheaper than solar cells for large installations: see http://en.wikipedia.org/wiki/Solar_thermal_energy, especially the parabolic trough bit.
This requires breeder reactors. Which are illegal in the US. And not new tech - hell, some of the first reactors in the 50's and 60's were breeding designs. The possibility to recycle spent fuel with good reactor technology at some undetermined point in the future is not an excuse to put in crappy PWRs or BWRs that can't recycle anything. We have enough highly radioactive used-once nuclear fuel lying around that any new plant that can't burn it is unacceptable.
"Waste" and depleted uranium are both unused nuclear fuel. If we just used proper breeding reactors, we'd reduce the volume of that stuff that we need to deal with by at least a factor of 10 - and we'd reduce the lifetime of the remaining waste to a couple of hundred years.
What is the functional difference between that and the issuance of government bonds?
Aside from push mail notification (which is neat), is there any advantage to this over something like the gmail mobile mail client?
Although Firefox does have some issues with memory usage (and occasionally memory leaks), that doesn't seem the be the primary cause of usability issues.
In my personal experience with Firefox, I see two problems:
Both of these problems could be solved relatively easily with threads (in a number of different ways), but for some reason the Firefox developers have an irrational paranoia of anything that even vaguely resembles native concurrency. They say "the real problem is just response time, if we can respond fast enough in a single thread it's the same" - but then they never actually do it, and they definitely don't do anything that would let them recover from component crashes.
That's a reasonable argument against mine. It doesn't change the fact that controversial claims without anything provided to back them are worthless.
I'm just mentioning Digg because the dynamic comment system is a great test of 2D acceleration in Firefox. When you click "expand thread", it does a little accelerating expansion animation (and animation means drawing a bunch of animation frames).
I'd actually be really interested to find out how Firefox on the PS3 handles that. It's been my personal test for 2D acceleration quality for a while now.
How does it do collapsing / expanding comment threads on digg.com?
It runs Linux like crap because it doesn't provide access to hardware accelerated graphics. And by "hardware accelerated graphics", I don't just mean 3D games and Compiz. It doesn't even have 2D acceleration, so you'll see redraw lag just scrolling in Firefox.
Basically Linux compatibility was just a scheme to get into a different import tax bracket in the European Union (where computers have a lower tax than video game consoles or media players). Actual usability wasn't a design goal.
How else would you name these things so as to communicate A.) what type of chip is it (entry level, mainstream, or high end) and B.) the model number of the chip and C.) the basic technical information that people want (i.e. "quad core")?
Contrary to the reports from some sensationalist tech journalists, quantum computers don't magically obsolete today's encryption algorithms. Take a look at the Wikipedia article for details. To summarize, for algorithms like AES, a quantum computer may be able to attack keys as much as twice as long as the keys that a classical computer can attack - margins of error that large are built into many systems that use such algorithms in practice.
What's wrong with entries.find(:all, :conditions => [:month => 6])?
Is that really a feature that you need, or is it just an excuse to avoid change?
The only way that you could get to those results given those criteria would be that you have a bunch of PHP and Cold Fusion developers on staff who push those choices. They aren't leading contenders on Development Time, Budget, or # of Developers - and they're about equal to any of the other contenders on the other points.
From what I've seen, the only real criteria that anyone ever uses in choosing a development environment is this: What are the developers used to. A runner up is "what has the manager seen hyped in trade publications" - but that never works out well.
This is probably a reasonable result. In practice, the differences between development environments in terms of the 6 points mentioned by the parent are pretty small. You might get an order of magnitude difference in #1, #5, and #6 in Java vs. Ruby for example - but you'll never convince a Java developer of that (or they'll claim an order of magnitude performance difference that rarely matters in practice). Hell, even writing an LDAP client library from scratch in Common Lisp (for example) is probably far cheaper than trying to get a team of Lisp programmers to move to ASP.NET or whatever.
This is just an issue of poor programming (or FUD). The idea that the Rails developers wouldn't provide the ability to select specific records out of a table is absurd, and any developer who selects the whole table and manually searches instead is incompetent.
As for ruby being slow, this is a much smaller deal than you'd expect. Most of these apps are database limited anyway - things like Rails caching will probably have a larger positive effect being able to execute less ruby instructions per microsecond.
Catalyst is neat, but it doesn't have the single big advantage that Rails or Django has: Lack of choice (aka sane defaults). If there's one way to do it, you do it that way and you're done. If there are five ways to do it, you spend a day trying to figure out which way is better - and then later find out that some other component assumes you did it one of the ways you didn't chose.
Now, when the sane defaults in Rails don't fit the bill, or when you really need some Perl libraries, or if you really need the factor-of-five speedup in the web app code that you can get from mod-perl, then Catalyst is the obvious choice. But for a new application that's database-performance limited anyway, being lazy (and using Rails) is the ultimate plan.
No programming language is so inefficient that you'll notice a performance difference in a web app for thousands of daily visitors. Not PHP vs. Ruby. Not a Scheme interpreter written in Visual Basic 2.0 vs. hand tuned assembly language. Web app throughput is measured in requests per second on modern servers (usually thousands or tends of thousands, but maybe hundreds for the Scheme in VB thing), and there are 86,400 seconds in a day.