I still question if the war was really worth it at this point in time. Regardless if it was worth it or not, it is clear that the people of the United States (and indeed,the world) were lied to about the reasons and justifications for the war and/or the certainty with which we held our allegations of WMD presence.
Saddam was a nut, no doubt, but our troops and our economy may have just suffered more than it was really worth. I would suggest that North Korea would be a bigger threat to national security, if that was really our metric of priority when it comes to intervention. I really cannot fathom why we chose Iraq to go first, unless we expected war to be so cheap that oil could pay for it in a reasonable time, which would have been a foolishly risky sentiment in our fragile condition.
We can't quite apply the q-word yet, as our actions don't seem to be futile, just expensive.
hmm. I'm going to call you on that one, and ask you produce the study that states that. It may be true, but the term "disposable income" is a very flexable one, so no one can really say a whole lot about it.
Wouldn't your income go down in your later years, and your expenses for medical care go up? The only expense I could see going down is the fact that your children, if you have any, have since moved away and become independent.
As I recall, States were not allowed to levy tariffs and such against each other. Doesn't imposing taxes on a particular method of transaction fly in the face of the rules that define us as a union and have been tested in the past in courts?
This is the price we must pay for the mess the Iraqi war caused budget-wise. Otherwise there would be the possibility that the federal government could assist the states, and businesses would not have to be so conservative because of the uncertainty lurking over the horizon. Instead we must bend the rules to work around this serious lack of funds.
I am aware of the compression issue, but for a while I entertained the idea that perhaps my pipe was handling too much information. That didn't seem to be the case.
I actually live across the block to get to campus, and my DSL POP is in the next major city.
Oh well, I'm so damn close, I may as well stop pretending to do work and go to the CS labs anyways.
Still, using remote X at home is a chore for me.
Despite broadband and etc, I have noticed that SSH'ing to my CS servers to run X can be very laggy.
I would like to see some of the remote latency decreased, maybe this technology offers a way to do it? SSH supports ZLib as a compressor, but I've noticed little or no effect on latency over my 1500kbit DSL with pretty good ping to many game servers. (It's MCI Worldcom, yuck, but hey, it's cool to have an ip that is.uu.net:D)
Any idea if this is applicable for the *BSDs or Solaris?
As I had posted earlier, this is the solution my university prefers.
Since posting my comment I've poked around on the internet looking for similar "ultra thin" (as opposed to just thin) clients, but have found no well known solutions outside the Sun Rays.
I really can't think of anything that is more appropriate for mass administration. I have never suffered lag or slowness, although there are occasional problems (usually network related, I assume) to small clusters of terminals.
As much as everyone loves the OSS poster child, Linux, I think that it would clearly be more difficult to administer and maintain that a few quasi-monolithic Sun servers.
Is it possible to manage a lot of linux/*BSD/Whatever machines? sure. But I think it's clear none is easy as ultra thin clients and Solaris.
I should also note that we use Solaris 8, just for the sake of completeness. Our three lower division classes consisting of hundreds of people have their classes in rooms with something like 30-50 Rays per room, each supported by a different solaris server, so figure 3 for those 3 largeish labs (or you could consider them all parts of a larger lab), plus many more elsewhere on campus that we can log into and do work on, tied together by a common file server. (eg I can log onto cory.eecs.berkeley.edu, torus.cs.berkeley.edu, rhombus.cs.berkeley.edu, solar.cs.berkeley.edu, and so on....quite a few more even over that.)
I don't know if it means a whole lot to you, but the computer labs at UC Berkeley use Solaris and Sun Rays (little dumb terminals.)
The package has worked very well for me as a student, and I would think/hope that Sun Rays are cost effective and an easy boxed dumb terminal solution. (Since I've never had such a demand, I don't know how much they cost and such.)
Our web site also runs on Solaris.
I find it rather ironic, but I somewhat thought how appropriate it would be that we'd use a BSD of some sort. Speaking of which, you should really look at BSD as an option -- it isn't nearly as edgy as Linux, and when you're hacking away on the common file server you do NOT want the thing to crash on a few hundred rabid CS undergraduate students close to deadline.
My vote: -Solaris for a paid for good dumb-terminal option (Comes with the benefits of cost/having to maintain one server, and the obvious downsides of the server failure...which shouldn't be too hard to prevent if there is good supporting staff for that one machine) -*BSD is more solid/mature overall but may require some more screwing around with and doesn't offer a nice, out of the box, trouble free dumb terminal solution as Sun Rays do. -Linux is fine, lots of people use it personally and we have many Linux support groups, but for the big servers that have to be solid more than perform at the bleeding edge, I would put a cautious vote against this vs. the other two options above.
Lastly, thank you for fighting and not selling another CS lab to Windows. Students I think will be better prepared at large when exposed to a non-toy operating system and are forced to use it to at least some productive degree. I myself log in via SSH from an XP box and run Exceed (X Windows server), start up emacs, and between that, a GDB buffer, and the terminal, I may as well be sitting at a lab computer. (with lag, as would be expected but not bad at all)
Slashdot Mirror
I still question if the war was really worth it at this point in time. Regardless if it was worth it or not, it is clear that the people of the United States (and indeed,the world) were lied to about the reasons and justifications for the war and/or the certainty with which we held our allegations of WMD presence.
Saddam was a nut, no doubt, but our troops and our economy may have just suffered more than it was really worth. I would suggest that North Korea would be a bigger threat to national security, if that was really our metric of priority when it comes to intervention. I really cannot fathom why we chose Iraq to go first, unless we expected war to be so cheap that oil could pay for it in a reasonable time, which would have been a foolishly risky sentiment in our fragile condition.
We can't quite apply the q-word yet, as our actions don't seem to be futile, just expensive.
hmm. I'm going to call you on that one, and ask you produce the study that states that. It may be true, but the term "disposable income" is a very flexable one, so no one can really say a whole lot about it.
Wouldn't your income go down in your later years, and your expenses for medical care go up? The only expense I could see going down is the fact that your children, if you have any, have since moved away and become independent.
It defies logic, working with this information.
As I recall, States were not allowed to levy tariffs and such against each other. Doesn't imposing taxes on a particular method of transaction fly in the face of the rules that define us as a union and have been tested in the past in courts?
This is the price we must pay for the mess the Iraqi war caused budget-wise. Otherwise there would be the possibility that the federal government could assist the states, and businesses would not have to be so conservative because of the uncertainty lurking over the horizon. Instead we must bend the rules to work around this serious lack of funds.
I am aware of the compression issue, but for a while I entertained the idea that perhaps my pipe was handling too much information. That didn't seem to be the case. I actually live across the block to get to campus, and my DSL POP is in the next major city. Oh well, I'm so damn close, I may as well stop pretending to do work and go to the CS labs anyways. Still, using remote X at home is a chore for me.
Despite broadband and etc, I have noticed that SSH'ing to my CS servers to run X can be very laggy.
.uu.net :D)
I would like to see some of the remote latency decreased, maybe this technology offers a way to do it? SSH supports ZLib as a compressor, but I've noticed little or no effect on latency over my 1500kbit DSL with pretty good ping to many game servers. (It's MCI Worldcom, yuck, but hey, it's cool to have an ip that is
Any idea if this is applicable for the *BSDs or Solaris?
As I had posted earlier, this is the solution my university prefers. Since posting my comment I've poked around on the internet looking for similar "ultra thin" (as opposed to just thin) clients, but have found no well known solutions outside the Sun Rays. I really can't think of anything that is more appropriate for mass administration. I have never suffered lag or slowness, although there are occasional problems (usually network related, I assume) to small clusters of terminals. As much as everyone loves the OSS poster child, Linux, I think that it would clearly be more difficult to administer and maintain that a few quasi-monolithic Sun servers. Is it possible to manage a lot of linux/*BSD/Whatever machines? sure. But I think it's clear none is easy as ultra thin clients and Solaris.
I should also note that we use Solaris 8, just for the sake of completeness. Our three lower division classes consisting of hundreds of people have their classes in rooms with something like 30-50 Rays per room, each supported by a different solaris server, so figure 3 for those 3 largeish labs (or you could consider them all parts of a larger lab), plus many more elsewhere on campus that we can log into and do work on, tied together by a common file server. (eg I can log onto cory.eecs.berkeley.edu, torus.cs.berkeley.edu, rhombus.cs.berkeley.edu, solar.cs.berkeley.edu, and so on....quite a few more even over that.)
I don't know if it means a whole lot to you, but the computer labs at UC Berkeley use Solaris and Sun Rays (little dumb terminals.)
The package has worked very well for me as a student, and I would think/hope that Sun Rays are cost effective and an easy boxed dumb terminal solution. (Since I've never had such a demand, I don't know how much they cost and such.)
Our web site also runs on Solaris.
I find it rather ironic, but I somewhat thought how appropriate it would be that we'd use a BSD of some sort. Speaking of which, you should really look at BSD as an option -- it isn't nearly as edgy as Linux, and when you're hacking away on the common file server you do NOT want the thing to crash on a few hundred rabid CS undergraduate students close to deadline.
My vote:
-Solaris for a paid for good dumb-terminal option (Comes with the benefits of cost/having to maintain one server, and the obvious downsides of the server failure...which shouldn't be too hard to prevent if there is good supporting staff for that one machine)
-*BSD is more solid/mature overall but may require some more screwing around with and doesn't offer a nice, out of the box, trouble free dumb terminal solution as Sun Rays do.
-Linux is fine, lots of people use it personally and we have many Linux support groups, but for the big servers that have to be solid more than perform at the bleeding edge, I would put a cautious vote against this vs. the other two options above.
Lastly, thank you for fighting and not selling another CS lab to Windows. Students I think will be better prepared at large when exposed to a non-toy operating system and are forced to use it to at least some productive degree. I myself log in via SSH from an XP box and run Exceed (X Windows server), start up emacs, and between that, a GDB buffer, and the terminal, I may as well be sitting at a lab computer. (with lag, as would be expected but not bad at all)