I, too, wonder about the usefulness of the camera. There's also the issue of power, which on mobile devices is a major issue. You might be willing to spend power if spatial precision is why the device exists, but I suspect that most people have other uses for their cellphones.
That said, there are other useful sensors on the phone, namely the accelerometer, the microphone, the wi-fi antenna, and in some cases, a magnetometer. These folks used those sensors, especially the accelerometer which has a negligible effect on battery life, in combination with a hidden Markov model in order to accurately predict a person's position. Not sub-centimeter, but good enough for regular people. Of course, the model had intimate knowledge of the surrounding area and transit schedules, but it's a neat idea. I especially liked the idea of using a DFT to differentiate between walking and riding the bus.
Anyway, point is: a coat pocket may not be an obstacle. Don't forget that modern phones have a surprising amount of processing power and memory.
Seconded. I have a TI-99/4A sitting on my desk at the moment and a book of games written in TI BASIC. For someone who now works daily in Scala (and sometimes Ruby) getting into old code is fun. For one, you forget how easy modern languages make your life; often old programs (especially if they were written in assembler) have no obvious structure. It's sort of like a puzzle. And then, of course, writing your own programs... "wait... I only have 16k?!"
That's not true. I'm no Microsoft apologist (I run OpenBSD and Linux) but Microsoft has some of the smartest people out there. The problem is, those people are neatly compartmentalized, in the form of Microsoft Research. Much of their work is highly regarded in the compsci community. But Microsoft-the-software-company often fails to see the potential of their work. I suspect that Microsoft's "don't rock the boat" approach is an official business strategy.
That's because the the graph hardly shows military spending in decline. I'd say that it's level. Of course, that's proportional to GDP which means in reality, it's increased a LOT.
But the fun doesn't stop there. The graph ends in 2001. Hmm, can't think of any large military expenditures between 2001 and 2011...
Put a recent CBO graph up there, and we can talk. Of course, he's right about entitlement spending. My personal take on this is that the US has to decide between policing the world and caring for its own citizens, because it can't do both.
Strange, most place I dealt with the server was gone when the support ran out, which was typically 3 to 5 years depending on the contract.
This attitude drove me nuts when I was in IT. It was incredibly wasteful. Very often, good hardware just gets tossed. Now, if you have a compelling reason to buy new hardware-- like, you can run 2x the machines in the same power budget as the old machines-- great! But it was usually more of, "Welp, our support contract expired, time to buy new stuff!"
This policy exists for two reasons: 1) most IT admins have no idea what they're doing, and 2) big hardware companies prey on this ignorance. Sure, there are some niche cases where you really do need to buy big iron. You will know when you're one of those special people. Look, more expensive computers aren't magic. Their calculations aren't somehow more precise. The vast majority of back-offices can get along just fine with off-the-shelf stuff.
At my last company, I made the following pitch: let's sit down and figure out how much it would cost to build our own machines, and maintain our own spare parts pool, and let's see how it compares to our support contracts. Building our own machines was so much cheaper that we were able to afford better, more exciting stuff (like fibre channel switches back when those were exciting). And our downtime improved, because when something broke, we already had the part. IBM's parts department is incredibly fast-- they can get a part to you by courier in something like 6 hours. But already having the part is infinitely faster.
One counterargument I've heard is that IT staff may not be competent enough to replace the parts themselves. I argue that if your staff can't handle this, then you have the wrong staff. Get them trained. You can do that now that you don't have to waste your money on support contracts. And in-house expertise is vastly more useful than expensive hardware.
Again, there's nothing magic about computers. They all essentially do the same thing. Buy the computers that solve the problems you actually have. If you do that, you'll often find that almost anything will do. (E.g., our *extremely* busy FTP site ran on an old desktop for about 5 years; the part that needed to be reliable, storage, was on the SAN, and that's where we spent most of our hardware money. Given that this machine was I/O bound, it made no sense to have a "better" machine)
The size of the book (I have the last edition) really is an indication of the fragmentation in Javascript implementations. In the edition I have, the authors spend an inordinate amount of time enumerating compatibility issues from one web browser to another. The K&R C book deals only with the core language and standard library, and it had the advantage at the time of having been written by the language designers/compiler writers themselves on the canonical platform (UNIX). ANSI C really was just a formalization of the design that had already happened, plus a few revisions for fixes and software engineering tricks learned along the way. Javascript has no such canonical implementation, and it definitely suffers from "design-by-committee"-ism, which means that even people involved in its development don't really know what the language's "vision" is.
My advice is: pick a Javascript library (I like JQuery) and pretend that you're writing in that "language". Trying to deal with browser idiosyncrasies yourself is a very deep rabbit hole. Also-- it helps if you can adopt some code style conventions, especially if you are on a team with varying abilities, because Javascript can turn into a truly horrible mess if you aren't careful.
I think sticking with the procedural/imperative paradigm is fine for starters. It's an intuitive way to understand how a computer works, and the procedural idiom extends way "under the hood" even in modern computers. You can use the metaphor of making food from a cookbook.
VB isn't terrible, but the language is not particularly organized, so features cannot be inferred like in newer languages. If you have a Windows machine, you should probably stick to.NET languages, and there are an absolute ton of them. C# is very much like Java, and Visual Studio is probably the nicest IDE I've ever used (insanely better than Eclipse), but you can run Ruby, Python, Scala, you name it, on.NET. The only redeeming quality of VB is that it is deeply integrated into MS Access, so that if you want your son to play with databases, he can leverage his VB knowledge. Access is nice for beginners because it lets you build a database visually, with ER-diagram-like construction tools. That said, programming in Access is of the "event-driven" style, and making the leap from strictly procedural to event-driven is difficult for some programmers.
But you may find that many of these languages are still over the head of a 4th-grader. For reference, I started with BASIC and eventually moved to C. But I also played with a number of toy languages along the way including Logo and the embedded language in the RoboWar game. RoboWar particularly stuck with me. The programming model was simple, and the game was a lot of fun, particularly since both my father and brother played along. It sparked an interested in trig while I was still learning algebra in school, since you could control your robots to a greater degree using trigonometric functions. Another option for beginners is "making webpages". This isn't strictly programming, since HTML is just markup, but it will introduce your son to some computer basics, and it provides a nice segue into programming-- not to mention, future programming jobs are likely to be in the web programming sphere. It is also fun. I can't stress the "fun" part enough. The entire reason I played with computers when I was a kid was because it was an enjoyable thing to do. That sense of fun will pervade his opinion of computers which will be necessary if he ever decides to do programming as a career, significant portions of which are "fun" only to masochists.
I agree re: programming being a general-purpose skill. A little knowledge of how a program is executed on a computer along with some basic CS concepts would help anybody who has to do computer work nowadays.
I advocate against teaching C++ in an intro course. I also had the Dietel & Dietel book for my intro C++ course. Incidentally, the guy who taught that course was an ex-DEC compiler-writer who was laid off by one of the Dietels after HP's acquisition of DEC.
I had a major advantage compared to my classmates: I had been exposed to C nearly 15 years before, and I was already a professional programmer. I thus viewed C++'s object-oriented features as nice software engineering tools which made practices like encapsulation explicit, while my classmates struggled with basics like loops and pointers. Before you can see C++'s strengths (and weaknesses), you need to nail the basics. Dietel & Dietel spend a lot of time covering the idea of objects and design tools like UML when, I think, for an intro course, time would be better spent understanding abstraction and recursion.
C is a nice intro language because it is simple, hides next to nothing about the machine, and makes it clear why people are interested in more modern languages. Ruby is another possibility, although it's almost too easy to use. That said, I often mock up algorithms in Ruby because Ruby code is very easy to read and think about.
Pilot systems necessarily cost a lot of money because their cost typically includes R&D. From a purely engineering standpoint, solar has some advantages over nuclear plants:
Simple design.
Failures are not catastrophic.
Does not require skilled labor to operate
Fuel is 'local' (i.e., it does not need to be harvested elsewhere, refined, and transported)
Of course, the energy density is much lower than nuclear, and as you point out, solar plants may be less reliable. However, given that sunlight is 'free' and 'clean' and uranium is not, these seem like worthwhile engineering challenges to investigate. Nuclear energy is exciting and clearly in our future, but you're a fool if you ignore its drawbacks. We have something like 1400W/m^2 from the sun during daylight hours. It would be very poor planning indeed to ignore that potential.
You can reload pf rules while pf is running. Seriously, reboot a firewall? Why?
pfctl -f/etc/pf.conf
You've been able to do this in OpenBSD (and FreeBSD) for ages now.
That's the problem, right there. I have to agree with the OP. If you don't know what you're looking for, you'll never find it.
I've been using computers for nearly 30 years. I've used all kinds of horrible UIs, and a few good ones. Unity made me want to scream. Let's just say that Windows 2.1 (which, yes, I had on my Packard Bell 286) is more usable than this POS.
I have to second this. There are very few things that are in GNOME that I like that weren't in Apple's System 7 UI. Both the MacOS X UI and Unity (what the fuck is up with the scrollbars???) seem like a step backward. I switched back to Classic because I'd rather get work done than dig around in menus for system prefs (gahhhh!!!! wtf!!!!), but I'll probably just switch to Fluxbox and be done with it. I hate this in-between crap-- either be a useable UI or be a hacker UI.
The sad part is that I think the rest of 11.04 is rather nice. Media plugins came preinstalled as well as my graphics card. But the new UI is a disaster.
Yeast is a fungus, not a bacterium. You can't assume that a technique that works for one kingdom will work for another. Furthermore, what the study essentially says is that sugar enhances the susceptibility of bacterium to antibiotic drugs. Now, it might be the case that the same thing holds for fungi and anti-fungal medication as well, but as far as I am aware, that would also be big news.
telnet, FTP, and Archie, then it isn't the real thing.
I was fortunate enough to have a father who worked at BBN at this time, and so I was immersed in network technology as a teenager. I remember him excitedly showing me a copy of NCSA Mosaic (an early web browser) and I was like Text documents? What's the point?" Funny.
I don't buy it. First of all, "common sense" is this mythical entity. Science has repeatedly shown that folkloric rules-of-thumb are wrong, especially when it comes to medicine. So what's so "sensical" about it, when it's often wrong? Because if your idea is right, i.e., supported by the evidence, you're talking about scientific fact. Anyone who argues from the evidence is, by definition, smart, or at least, smart enough not to be called "stupid". Now, science is sometimes "wrong", but science has a built-in mechanism to correct that; thus scientific fact is under constant revision.
Everyone "used to die young". Look, humans reach reproductive capability in their teens. There's plenty of time to be stupid before you die if you can reproduce after only 13 or 14 years of existence, and in pre-industrial revolution human history, people often did. Your complaints about "lowering the average" and "failing to give their children values" are old claims-- probably as old as the ideas of "average" and "values".
Education is strongly correlated with a better quality of life (and if you don't strongly suspect that there is some causal relationship there-- well, you're being obtuse). Everybody born in the United States is now entitled to (and, in fact, required to have) that education, by law. Almost everyone in this country can read and do basic arithmetic. Life is way better now than quite frankly any time in human history. I fail to see how humans are now more stupid or in any way worse off.
Now, if you argue that our best aren't as good as they used to be-- you may have a point. But I'd still take many smart people over a few geniuses any day.
Evidence suggests that no matter what the posted speed, people will drive exactly as fast as they feel safe driving.
That's interesting, and anecdotally, seems to make sense. But I suspect speeding tickets have more than "no effect", since I personally changed my driving habits after receiving one (and after having to pay the premium for such behavior on my insurance for years). Care to share links to studies?
Your comment is not flameworthy, but it indicates that you do not realize how much work a PhD entails. In STEM, it takes around 7 years to earn a PhD after earning your undergraduate degree-- I know, because I'm currently a PhD student.
Finding a job outside your field requires substantially less effort than this. In fact, I had a good job, for seven years, after graduating. By the time I decided to leave the private industry and re-enter academia, I had a very promising path into upper management (in IT). But as much as I enjoyed my job, and liked the people I worked with, there was no challenge. I was not doing anything cutting-edge. That's why I went back.
Four years as an undergraduate is nothing, especially when you're young. Loss aversion is irrational, but enrolling in a PhD program because you're afraid to waste your four years as an undergrad is loss-averse in the extreme. If you don't love your graduate studies, you won't make it very long. I suspect that many PhDs go into academia because that's where the action is, for the most part.
Sadly, most technology worker equate bandwidth with bitrates, even though they aren't the same at all. It depends on the encoding scheme. This was finally made clear to me when I learned about Huffman coding, and later, about Shannon's idea of "information". Tanenbaum has a gentle introduction in his Networks book.
Bitrates are rates, and so, in some sense they have to do with velocity. I'm OK with calling that 'speed'.
The funny thing is that many (not all) of the companies you mention are simply rebranded versions of OSS tools. Checkpoint, for instance, is FreeBSD (at least, the box we had was). BlueCoat? Same deal! We discovered that we could do all of the functions of those machines, and more, with a couple generic OpenBSD boxes, pf, and pfsync, and they're a HECK of a lot cheaper.
I contend that you'd be better off using the money saved to develop in-house expertise. Firstly, an organization's network is domain-specific knowledge in the extreme. Secondly, smarter engineers tend to result in better network designs, e.g., the kind that do not have the kind of urgency that they need to be fixed in the middle of the night. Your own people should be better at solving those kinds of problems, or else they're not earning their paychecks. Outsourcing gruntwork, fine. Outsourcing thinking? Bad idea.
After multihoming one of our offices, it was quite a revelation to me when one of our lines went some some months later. Nobody even noticed, except me. That gave me the freedom to fix the problem without having to worry about whether I should tell management to send people home. Also, being able to SSH in from home to fix a routing issue? How f'ing cool is that?
The thing that surprises me the most is how often IT workers think that they need Cisco gear. There is very little that Cisco devices can do that cheaper third-party-- and sometimes even commodity hardware!-- cannot do. That is, unless you're running a proprietary Cisco routing protocol, or need to feel the mystique of running 'enterprise' gear.
We dumped our Cisco gear years ago after attending a presentation on OpenBGP (in which the presenter talked about routing his Internet2 connection with a P4) and we haven't looked back since. And the equivalent Cisco machines for our border routers cost an order of magnitude more.
People have been doing that on Mechanical Turk for awhile now. It makes sense. If you think of a human as a very slow, error-prone CPU, the solution is obvious:
Get more people
Have them check each other's work
The second part relies on the independence of the people-- i.e., they are not colluding to distort your "computation". But crowdsourcing sites like MTurk and Slashdot effectively mitigate this by 1) having a large user base from which they 2) sample randomly. MTurk allows you to do crowdsourced checking of crowdsourced content by exposing the worker_id, so that you can exclude a worker who participated in one step from participating in another. Slashdot's moderation system requires that people can't post and moderate at the same time.
This paper coins the term "inter-annotator agreement" for this idea for NLP-type tasks. There are other papers, too, but I have to get back to work.
A great deal of computer science has to do with the computational properties of solving a particular kind or class of a problem. So maybe it should be called "computational science", but the reference to the computer is essential here. I strongly disagree with Dijkstra about his statement that "computers are to computer science as telescopes are to astronomy." Computability appears to be a fundamental property of the universe; it clearly affects how computers themselves work, but it also has powerful implications for quantum physics. Saying that it isn't worthy of study as a separate artifact is silly.
Nobody called themselves abacus scientists because nobody ever studied how abacuses themselves affected what we were able to solve. It wasn't clear (to anyone except, perhaps, Turing and Gödel) that computational machinery was more powerful than just tallying things up until real computers started being built.
Except server apps, which typically start up once. If you don't have to start over and over, you can amortize that cost over the runtime of the entire program-- that makes the cost negligable. Further, you can do neat things like apply optimization based on runtime statistics-- i.e., spend the cycles optimizing JIT code where it counts. JikesRVM does this, for example.
Slashdot Mirror
I, too, wonder about the usefulness of the camera. There's also the issue of power, which on mobile devices is a major issue. You might be willing to spend power if spatial precision is why the device exists, but I suspect that most people have other uses for their cellphones.
That said, there are other useful sensors on the phone, namely the accelerometer, the microphone, the wi-fi antenna, and in some cases, a magnetometer. These folks used those sensors, especially the accelerometer which has a negligible effect on battery life, in combination with a hidden Markov model in order to accurately predict a person's position. Not sub-centimeter, but good enough for regular people. Of course, the model had intimate knowledge of the surrounding area and transit schedules, but it's a neat idea. I especially liked the idea of using a DFT to differentiate between walking and riding the bus.
Anyway, point is: a coat pocket may not be an obstacle. Don't forget that modern phones have a surprising amount of processing power and memory.
Seconded. I have a TI-99/4A sitting on my desk at the moment and a book of games written in TI BASIC. For someone who now works daily in Scala (and sometimes Ruby) getting into old code is fun. For one, you forget how easy modern languages make your life; often old programs (especially if they were written in assembler) have no obvious structure. It's sort of like a puzzle. And then, of course, writing your own programs... "wait... I only have 16k?!"
That's not true. I'm no Microsoft apologist (I run OpenBSD and Linux) but Microsoft has some of the smartest people out there. The problem is, those people are neatly compartmentalized, in the form of Microsoft Research. Much of their work is highly regarded in the compsci community. But Microsoft-the-software-company often fails to see the potential of their work. I suspect that Microsoft's "don't rock the boat" approach is an official business strategy.
That's because the the graph hardly shows military spending in decline. I'd say that it's level. Of course, that's proportional to GDP which means in reality, it's increased a LOT.
But the fun doesn't stop there. The graph ends in 2001. Hmm, can't think of any large military expenditures between 2001 and 2011...
Put a recent CBO graph up there, and we can talk. Of course, he's right about entitlement spending. My personal take on this is that the US has to decide between policing the world and caring for its own citizens, because it can't do both.
STACK OVERFLOW ERROR.
Strange, most place I dealt with the server was gone when the support ran out, which was typically 3 to 5 years depending on the contract.
This attitude drove me nuts when I was in IT. It was incredibly wasteful. Very often, good hardware just gets tossed. Now, if you have a compelling reason to buy new hardware-- like, you can run 2x the machines in the same power budget as the old machines-- great! But it was usually more of, "Welp, our support contract expired, time to buy new stuff!"
This policy exists for two reasons: 1) most IT admins have no idea what they're doing, and 2) big hardware companies prey on this ignorance. Sure, there are some niche cases where you really do need to buy big iron. You will know when you're one of those special people. Look, more expensive computers aren't magic. Their calculations aren't somehow more precise. The vast majority of back-offices can get along just fine with off-the-shelf stuff.
At my last company, I made the following pitch: let's sit down and figure out how much it would cost to build our own machines, and maintain our own spare parts pool, and let's see how it compares to our support contracts. Building our own machines was so much cheaper that we were able to afford better, more exciting stuff (like fibre channel switches back when those were exciting). And our downtime improved, because when something broke, we already had the part. IBM's parts department is incredibly fast-- they can get a part to you by courier in something like 6 hours. But already having the part is infinitely faster.
One counterargument I've heard is that IT staff may not be competent enough to replace the parts themselves. I argue that if your staff can't handle this, then you have the wrong staff. Get them trained. You can do that now that you don't have to waste your money on support contracts. And in-house expertise is vastly more useful than expensive hardware.
Again, there's nothing magic about computers. They all essentially do the same thing. Buy the computers that solve the problems you actually have. If you do that, you'll often find that almost anything will do. (E.g., our *extremely* busy FTP site ran on an old desktop for about 5 years; the part that needed to be reliable, storage, was on the SAN, and that's where we spent most of our hardware money. Given that this machine was I/O bound, it made no sense to have a "better" machine)
The size of the book (I have the last edition) really is an indication of the fragmentation in Javascript implementations. In the edition I have, the authors spend an inordinate amount of time enumerating compatibility issues from one web browser to another. The K&R C book deals only with the core language and standard library, and it had the advantage at the time of having been written by the language designers/compiler writers themselves on the canonical platform (UNIX). ANSI C really was just a formalization of the design that had already happened, plus a few revisions for fixes and software engineering tricks learned along the way. Javascript has no such canonical implementation, and it definitely suffers from "design-by-committee"-ism, which means that even people involved in its development don't really know what the language's "vision" is.
My advice is: pick a Javascript library (I like JQuery) and pretend that you're writing in that "language". Trying to deal with browser idiosyncrasies yourself is a very deep rabbit hole. Also-- it helps if you can adopt some code style conventions, especially if you are on a team with varying abilities, because Javascript can turn into a truly horrible mess if you aren't careful.
I think sticking with the procedural/imperative paradigm is fine for starters. It's an intuitive way to understand how a computer works, and the procedural idiom extends way "under the hood" even in modern computers. You can use the metaphor of making food from a cookbook.
.NET languages, and there are an absolute ton of them. C# is very much like Java, and Visual Studio is probably the nicest IDE I've ever used (insanely better than Eclipse), but you can run Ruby, Python, Scala, you name it, on .NET. The only redeeming quality of VB is that it is deeply integrated into MS Access, so that if you want your son to play with databases, he can leverage his VB knowledge. Access is nice for beginners because it lets you build a database visually, with ER-diagram-like construction tools. That said, programming in Access is of the "event-driven" style, and making the leap from strictly procedural to event-driven is difficult for some programmers.
VB isn't terrible, but the language is not particularly organized, so features cannot be inferred like in newer languages. If you have a Windows machine, you should probably stick to
But you may find that many of these languages are still over the head of a 4th-grader. For reference, I started with BASIC and eventually moved to C. But I also played with a number of toy languages along the way including Logo and the embedded language in the RoboWar game. RoboWar particularly stuck with me. The programming model was simple, and the game was a lot of fun, particularly since both my father and brother played along. It sparked an interested in trig while I was still learning algebra in school, since you could control your robots to a greater degree using trigonometric functions. Another option for beginners is "making webpages". This isn't strictly programming, since HTML is just markup, but it will introduce your son to some computer basics, and it provides a nice segue into programming-- not to mention, future programming jobs are likely to be in the web programming sphere. It is also fun. I can't stress the "fun" part enough. The entire reason I played with computers when I was a kid was because it was an enjoyable thing to do. That sense of fun will pervade his opinion of computers which will be necessary if he ever decides to do programming as a career, significant portions of which are "fun" only to masochists.
I agree re: programming being a general-purpose skill. A little knowledge of how a program is executed on a computer along with some basic CS concepts would help anybody who has to do computer work nowadays.
I advocate against teaching C++ in an intro course. I also had the Dietel & Dietel book for my intro C++ course. Incidentally, the guy who taught that course was an ex-DEC compiler-writer who was laid off by one of the Dietels after HP's acquisition of DEC.
I had a major advantage compared to my classmates: I had been exposed to C nearly 15 years before, and I was already a professional programmer. I thus viewed C++'s object-oriented features as nice software engineering tools which made practices like encapsulation explicit, while my classmates struggled with basics like loops and pointers. Before you can see C++'s strengths (and weaknesses), you need to nail the basics. Dietel & Dietel spend a lot of time covering the idea of objects and design tools like UML when, I think, for an intro course, time would be better spent understanding abstraction and recursion.
C is a nice intro language because it is simple, hides next to nothing about the machine, and makes it clear why people are interested in more modern languages. Ruby is another possibility, although it's almost too easy to use. That said, I often mock up algorithms in Ruby because Ruby code is very easy to read and think about.
Of course, the energy density is much lower than nuclear, and as you point out, solar plants may be less reliable. However, given that sunlight is 'free' and 'clean' and uranium is not, these seem like worthwhile engineering challenges to investigate. Nuclear energy is exciting and clearly in our future, but you're a fool if you ignore its drawbacks. We have something like 1400W/m^2 from the sun during daylight hours. It would be very poor planning indeed to ignore that potential.
You can reload pf rules while pf is running. Seriously, reboot a firewall? Why? pfctl -f /etc/pf.conf
You've been able to do this in OpenBSD (and FreeBSD) for ages now.
Right click
That's the problem, right there. I have to agree with the OP. If you don't know what you're looking for, you'll never find it.
I've been using computers for nearly 30 years. I've used all kinds of horrible UIs, and a few good ones. Unity made me want to scream. Let's just say that Windows 2.1 (which, yes, I had on my Packard Bell 286) is more usable than this POS.
I have to second this. There are very few things that are in GNOME that I like that weren't in Apple's System 7 UI. Both the MacOS X UI and Unity (what the fuck is up with the scrollbars???) seem like a step backward. I switched back to Classic because I'd rather get work done than dig around in menus for system prefs (gahhhh!!!! wtf!!!!), but I'll probably just switch to Fluxbox and be done with it. I hate this in-between crap-- either be a useable UI or be a hacker UI.
The sad part is that I think the rest of 11.04 is rather nice. Media plugins came preinstalled as well as my graphics card. But the new UI is a disaster.
Yeast is a fungus, not a bacterium. You can't assume that a technique that works for one kingdom will work for another. Furthermore, what the study essentially says is that sugar enhances the susceptibility of bacterium to antibiotic drugs. Now, it might be the case that the same thing holds for fungi and anti-fungal medication as well, but as far as I am aware, that would also be big news.
telnet, FTP, and Archie, then it isn't the real thing.
I was fortunate enough to have a father who worked at BBN at this time, and so I was immersed in network technology as a teenager. I remember him excitedly showing me a copy of NCSA Mosaic (an early web browser) and I was like Text documents? What's the point?" Funny.
I don't buy it. First of all, "common sense" is this mythical entity. Science has repeatedly shown that folkloric rules-of-thumb are wrong, especially when it comes to medicine. So what's so "sensical" about it, when it's often wrong? Because if your idea is right, i.e., supported by the evidence, you're talking about scientific fact. Anyone who argues from the evidence is, by definition, smart, or at least, smart enough not to be called "stupid". Now, science is sometimes "wrong", but science has a built-in mechanism to correct that; thus scientific fact is under constant revision.
Everyone "used to die young". Look, humans reach reproductive capability in their teens. There's plenty of time to be stupid before you die if you can reproduce after only 13 or 14 years of existence, and in pre-industrial revolution human history, people often did. Your complaints about "lowering the average" and "failing to give their children values" are old claims-- probably as old as the ideas of "average" and "values".
Education is strongly correlated with a better quality of life (and if you don't strongly suspect that there is some causal relationship there-- well, you're being obtuse). Everybody born in the United States is now entitled to (and, in fact, required to have) that education, by law. Almost everyone in this country can read and do basic arithmetic. Life is way better now than quite frankly any time in human history. I fail to see how humans are now more stupid or in any way worse off.
Now, if you argue that our best aren't as good as they used to be-- you may have a point. But I'd still take many smart people over a few geniuses any day.
Evidence suggests that no matter what the posted speed, people will drive exactly as fast as they feel safe driving.
That's interesting, and anecdotally, seems to make sense. But I suspect speeding tickets have more than "no effect", since I personally changed my driving habits after receiving one (and after having to pay the premium for such behavior on my insurance for years). Care to share links to studies?
Your comment is not flameworthy, but it indicates that you do not realize how much work a PhD entails. In STEM, it takes around 7 years to earn a PhD after earning your undergraduate degree-- I know, because I'm currently a PhD student.
Finding a job outside your field requires substantially less effort than this. In fact, I had a good job, for seven years, after graduating. By the time I decided to leave the private industry and re-enter academia, I had a very promising path into upper management (in IT). But as much as I enjoyed my job, and liked the people I worked with, there was no challenge. I was not doing anything cutting-edge. That's why I went back.
Four years as an undergraduate is nothing, especially when you're young. Loss aversion is irrational, but enrolling in a PhD program because you're afraid to waste your four years as an undergrad is loss-averse in the extreme. If you don't love your graduate studies, you won't make it very long. I suspect that many PhDs go into academia because that's where the action is, for the most part.
Sadly, most technology worker equate bandwidth with bitrates, even though they aren't the same at all. It depends on the encoding scheme. This was finally made clear to me when I learned about Huffman coding, and later, about Shannon's idea of "information". Tanenbaum has a gentle introduction in his Networks book.
Bitrates are rates, and so, in some sense they have to do with velocity. I'm OK with calling that 'speed'.
The funny thing is that many (not all) of the companies you mention are simply rebranded versions of OSS tools. Checkpoint, for instance, is FreeBSD (at least, the box we had was). BlueCoat? Same deal! We discovered that we could do all of the functions of those machines, and more, with a couple generic OpenBSD boxes, pf, and pfsync, and they're a HECK of a lot cheaper.
I contend that you'd be better off using the money saved to develop in-house expertise. Firstly, an organization's network is domain-specific knowledge in the extreme. Secondly, smarter engineers tend to result in better network designs, e.g., the kind that do not have the kind of urgency that they need to be fixed in the middle of the night. Your own people should be better at solving those kinds of problems, or else they're not earning their paychecks. Outsourcing gruntwork, fine. Outsourcing thinking? Bad idea.
After multihoming one of our offices, it was quite a revelation to me when one of our lines went some some months later. Nobody even noticed, except me. That gave me the freedom to fix the problem without having to worry about whether I should tell management to send people home. Also, being able to SSH in from home to fix a routing issue? How f'ing cool is that?
The thing that surprises me the most is how often IT workers think that they need Cisco gear. There is very little that Cisco devices can do that cheaper third-party-- and sometimes even commodity hardware!-- cannot do. That is, unless you're running a proprietary Cisco routing protocol, or need to feel the mystique of running 'enterprise' gear.
We dumped our Cisco gear years ago after attending a presentation on OpenBGP (in which the presenter talked about routing his Internet2 connection with a P4) and we haven't looked back since. And the equivalent Cisco machines for our border routers cost an order of magnitude more.
The second part relies on the independence of the people-- i.e., they are not colluding to distort your "computation". But crowdsourcing sites like MTurk and Slashdot effectively mitigate this by 1) having a large user base from which they 2) sample randomly. MTurk allows you to do crowdsourced checking of crowdsourced content by exposing the worker_id, so that you can exclude a worker who participated in one step from participating in another. Slashdot's moderation system requires that people can't post and moderate at the same time.
This paper coins the term "inter-annotator agreement" for this idea for NLP-type tasks. There are other papers, too, but I have to get back to work.
A great deal of computer science has to do with the computational properties of solving a particular kind or class of a problem. So maybe it should be called "computational science", but the reference to the computer is essential here. I strongly disagree with Dijkstra about his statement that "computers are to computer science as telescopes are to astronomy." Computability appears to be a fundamental property of the universe; it clearly affects how computers themselves work, but it also has powerful implications for quantum physics. Saying that it isn't worthy of study as a separate artifact is silly.
Nobody called themselves abacus scientists because nobody ever studied how abacuses themselves affected what we were able to solve. It wasn't clear (to anyone except, perhaps, Turing and Gödel) that computational machinery was more powerful than just tallying things up until real computers started being built.
Except server apps, which typically start up once. If you don't have to start over and over, you can amortize that cost over the runtime of the entire program-- that makes the cost negligable. Further, you can do neat things like apply optimization based on runtime statistics-- i.e., spend the cycles optimizing JIT code where it counts. JikesRVM does this, for example.