Back when I was an undergrad in the math department...we had great math parties that were a lot of fun. You don't have to do much to carry a math-ish theme, and math folks tend to carry conversations well-enough that you don't have to babysit them (unlike so many CS parties I've been to).
We used to have Math-querade parties, just to make use of a good pun. Costumes were optional, but plenty of us dressed up anyway.
Sometimes we'd mak math-shaped sugar-cookies -- just make a batch of sugar-cookie dough and cut it in the shape of various operators and greek letters (then have fun decorating with icing). It's a fair amount of work, but you could even turn it into a party-community activity (have the dough ready ahead of time, then get everyone to roll out a bit of dough and start cutting out math shapes).
It was always good to have games around. Encourage people to bring their own -- they're likely to have many. If you know any math profs well, see if they'll loan you their games, or suggest some (about 1/3 of math profs I know *loved* puzzle-games). Any game with deduction is usually a sure-fire hit, including various card games or round-the-table games like "Mafia", e.g. http://en.wikipedia.org/wiki/Mafia_(game) [yes, those parens are part of the url, it seems).
Alcohol is fine, but recognize that not all geeks like drinking, and that is fine. I'd suggest accommodating moderate drinking, but skip the hard alcohol.
Unless the math students/geeks you know are assholes, any effort you make with the intention of having fun will be warmly-received.
I recently gave an invited talk at Google, and the audience was the best I have ever had (or heard of). They asked the best questions and had the best criticisms and insights. The audiences at academic conferences aren't nearly as good. Google's employees are top-notch. If you are worried about Google's power, you should be worried about why so many of the best and brightest people in the world want to work there (especially when they have a reputation for paying slightly less than competitors like Yahoo and Microsoft). I wouldn't worry much about their accumulation of hardware.
Google started as an academic project at Stanford, and ran on just a few computers (less than 10 IIRC). AFAICT, the current scale of Google to serve many hundreds of millions of users, as well as more frequent re-indexing and fine-tuning of search (to deal with blogs, porn rings, etc). A startup with fewer users could probably survive with a very small number of racks.
About advertising, I don't think advertisers or consumers are loyal to the advertising company. Any ad group that provides additional revenue for the advertiser will find a way to survive. I don't think Google can rest on their adsense laurels (not that they've ever rested on anything).
Are auto-levelling devices legal in the US? The US version of the VW Golf GLS does not have a manual headlight aiming adjustment in the cabin, but at least some European versions do.
You want to minimize the chance of destruction whether you're on a city street or in the desert. I doubt there's a prize for coolest disaster.
On the other stuff, I think I didn't communicate my point effectively. You can't just read sensors and rely on their data. Sensors return wrong data, even laser rangefinders. Picking out which data is good and which is bad requires more computation than just 10 serial port reads per second.
Until a person has been involved with these sorts of projects it is very hard to even imagine the scope of the problems. I don't have much robotics experience, my field is data mining and artificial intelligence. But even there the data is always screwed up. Nobody ever gives you a dataset that is complete, or training data that is correct. Much of the time it isn't clear what "correct" even means. The real world sucks big time.
And software sucks big time. I did do some robotics programming for a local company, to control elevators used by their robots. The problems involved were insane. We had troubles getting the elevator companies to give us access to the elevator call buttons (the buttons in the hallways) and the elevator direction and destination -- and I can tell you that getting all that info (which we didn't) was going to cost a lot more than $5000 per installation. We had to estimate the elevator's direction according to floor data, which isn't that hard -- until you run into the problem of elevators which don't have any floor info (some cargo elevators). Then there's the issue of communication. We couldn't run a wired network, and wireless did a poor job penetrating into some elevator cabins. That meant that the elevator doors might open on the wrong floor (due to humans pressing buttons), and we couldn't notify the robot. And we didn't have access to the "door open" button so we had to rely on holding down the floor button. There's also the matter of telling the robot that the cabin has arrived to pick it up -- we don't know when the doors open, and different elevators can take a vastly different amount of time to open the doors. Thankfully the robot could help a bit for that particular problem.
And I haven't even begun to tell you about the robot navigation problems getting into and out of the elvator, especially for elevators that didn't line up right with the floor. And if there's a wide gap between the elevator and the floor, the rangefinders think there's a 10-storey cliff in front of it. And once you get the robot going, it's wheels might not work well crossing a two-inch gap. But you can't change the wheels because their design is critical to the navigation software.
This was what I encountered in 3 months of consulting for a robotics company whose robots drove very slowly along the walls of uncluttered hallways. All of the problems were dealt with eventually, and many of them had autonomous solutions. But now the robots have a webcam that allows humans to drive it out of bad situations that the software still can't deal with.
Did I mention that the robot tracked the wall to help its navigation? Now think about driving across a sand-covered highway through a sand-covered plain. I'm not sure what these guys are really facing, but I'm sure it's a lot harder than we can possibly imagine.
I don't think you're going to get six good laser rangefinders for $5000. I don't remember the numbers as well as I would like, but I think the current favorite rangefinders (I think the brand is SIC?) are well over $1000 each. And you will quickly exhaust your laptop's computational power just denoising the output from crappy sensors. Heck, maybe even for the best sensors.
Autonomous vehicles have already driven across the country on highways, 98.2% of the time without human intervention. The roads it drove on are (I'm guessing) likely to be much nicer than those in the desert. Furthermore there was a human available to handle the surprises. For humor value: I believe one of the self-driving vechicles from CMU has a learner's permit from the state of Pennsylvania. See No Hands Across America for more info on this project.
The hard part of any project like this is uncertainty in the environment. The road may "disappear" completly from your sensors, or you may spot multiple roads. Maybe some mica on a rock screws up your rangefinder. Maybe your vehcicle's transmission gets a little "funny" and you can't shift properly anymore (I saw such a comment attached to this article). And we aren't even talking about genuine malfunctions like a failing rangefinder or sticky throttle.
I think autonomous systems might be the best example of the best laid plans of mice and men not succeeding when the slightest thing goes wrong. In fact, Steinbeck's story seems directly analgous to the problems of self-driving vehicles.
I think you haven't been around enough turbines, or enough people who have lost their high-frequency hearing due to turbines (before ear protection was mandatory).
"I wonder how close you could get to a working linux machine with nothing officially from GNU?"
Good luck. I doubt you'll want to use the system you end up with anyway. Even FreeBSD uses a bunch of GNU stuff. Commerical UNIX vendors ship CDs of GNU tools alongside their operating system CDs. Embedded systems have GNU stuff in them and GNU influence (toolchains) all over them.
GNU really is everywhere, and for good reason. For isntance, feel free to use non-GNU tar but keep in mind that many (all?) non-GNU tar programs have limits on filename length. Have fun relearning all of the textutils and binary utilities. The GNU versions are richer and better in nearly every case.
It's just not sensible to try to get rid of GNU stuff, unless you switch to Windows. It's the GNU in GNU/Linux that makes it pleasant to use.
FWIW, you don't need to take all of Python with you onto the device. The handhelds.org folks have done a nice job of "modularizing" their python dist.
Still, Python is something extra that you may not be able to afford. I'm personally much more interested in the cross-compiling on a dev machine, including all the portage stuff, and then easy installation into a directory of your choice. Note that this requires packages are built against the libraries in the install directory -- you don't want to link against your host machines glibc if you're using uclibc on the target device.
-Paul Komarek
When some foreign students come to the US
on
Cable TV Ruins Bhutan
·
· Score: 3, Insightful
This article reminded me of things I've seen some foreign students go through in the US. The idea that businesses are happy to screw their customers comes slowly to some. While many (but clearly not all) Americans develop a resistance to twinkies and pop tarts, some foreigners are completely defenseless.
I have grown up in a culture that, to some degree, "understands" television. I know that both the WWF and the Presidential Debates are complete bullshit. I know I shouldn't trust or believe anyone on television (and many in "real" life). I am beginning to conclude that these traits are cultural and have little to do with intelligence.
Which means that Bhutan is screwed. I'd far rather see them explore the internet, because it is easier to realize that you are responsible for what you view.
Computing things as a percentage of GDP ignores fixed costs. A bus pass is a far smaller part of a rich person's salary than a poor person's. The best you can conclude from the percentages is that the poor person is getting screwed. Same thing for movie tickets (although some people like to claim that poor people shouldn't have the right to go to the cinema).
Military spending is generally considered necessary up to at least a level of defense. It doesn't much matter what the GDP is, you still have large costs for people and equpment that you *must* pay. What makes the US military spending so gauling is how far we go beyond defence. It is hard to argue that planes costing $2,000,000,000 each (which are somewhat fragile) are really necessary for self-defense. We're an agressive nation that spends far more on offensive military capabilities than anyone else I can think of. It's far easier to argue that much of Israel's military spending is for defense, given the (continuing) history of wars there, compared to the US.
I'm wondering if the money we send Israel is counted as part of their GDP? If not, military-spending-as-a-percentage-of-GDP probably doesn't compare what we "want" it to.
Incidently, I expect that most supermarket-brand ketchup is probably Heinz rebottled. That main guy at RedHat used to talk about Heinz and branding a lot.
I feel a little silly arguing over what RMS thinks, but I'm going to do it anyway.;-)
I don't think RMS' primary concerns are features, robustness, or future features or robustness. It seems to me his primary concern is software "neighborly-ness"; that is, the ability to cooperate and share. He certainly isn't worried about convenience, or else he would have taken a job for one of those lisp companies years ago (possibly saving is hands from the lisp-wars), made a bunch of money, and lived "comfortably".
As a very minor point, I don't think he cares much about the functionality of linux (the kernel), either.
We're attempting to switch to gentoo for some headless Alpha "cycle-servers" that are currently running RH7.1. We need to stick with GNU/Linux. We're interested in source-based distros with simple package formats. We believe we can support our needs (mainly the C toolchain and network client programs) if the packaging system is simple enough.
My main gripe with gentoo is that they're a bit too bleeding edge. But we can fix it where we need to with simple changes to their packages, which we then store in a local package repository. It's been a little slow getting started due to AFS/Kerb problems, but we seem to be on our way now.
We ran into a problem where a server had insufficiently many serial ports, and wanted to buy a usb-serial bridge ($50) instead of another terminal server ($1000). However there was no usb-serial bridge (i.e. converter) support in FreeBSD at the time. I believe that KeySpan even offered to work with FreeBSD on supporting their products, but apparently nobody would act as the contact.
We've also had serious problems with FreeBSD on our fileserver, due to a long-overlooked bug when many files are deleted quickly (a quota bug was found in the process, too).
I'm not claiming here that GNU/Linux systems are better, nor will I claim they are worse. But the "It's a server, use FreeBSD!" mantra is silly, at least in our experience. FreeBSD has not been more stable, or faster, or more flexible, or easier to admin than GNU/Linux systems. It's just another version of Free unix on a PC.
Scott, one of the authors, has stated that it is reasonable to attack without access to the source code. See the post 6088358 and Scott's reply at 6088426.
I'm not a security researcher, but I'd guess that disassembling any binary would provide plenty of information to reconstruct any hashing functions used. After all, people have proven themselves pretty clever at modifying closed-source games and finding (other) security problems in closed-source software, having only the binary to work from.
The European Union has laws governing discounting. Microsoft is currently under scrutiny for offering possibly illegal discounts in the past. If the Munich discount wasn't already known, then it's almost certainly going to make things worse for MS.
On the other hand, the Deutsches Museum is awesome. I believe it's the world's largest technical museum. IIRC, it has a full-scale coal mine model in the basement.
Slashdot Mirror
Back when I was an undergrad in the math department...we had great math parties that were a lot of fun. You don't have to do much to carry a math-ish theme, and math folks tend to carry conversations well-enough that you don't have to babysit them (unlike so many CS parties I've been to).
We used to have Math-querade parties, just to make use of a good pun. Costumes were optional, but plenty of us dressed up anyway.
Sometimes we'd mak math-shaped sugar-cookies -- just make a batch of sugar-cookie dough and cut it in the shape of various operators and greek letters (then have fun decorating with icing). It's a fair amount of work, but you could even turn it into a party-community activity (have the dough ready ahead of time, then get everyone to roll out a bit of dough and start cutting out math shapes).
It was always good to have games around. Encourage people to bring their own -- they're likely to have many. If you know any math profs well, see if they'll loan you their games, or suggest some (about 1/3 of math profs I know *loved* puzzle-games). Any game with deduction is usually a sure-fire hit, including various card games or round-the-table games like "Mafia", e.g. http://en.wikipedia.org/wiki/Mafia_(game) [yes, those parens are part of the url, it seems).
Alcohol is fine, but recognize that not all geeks like drinking, and that is fine. I'd suggest accommodating moderate drinking, but skip the hard alcohol.
Unless the math students/geeks you know are assholes, any effort you make with the intention of having fun will be warmly-received.
I recently gave an invited talk at Google, and the audience was the best I have ever had (or heard of). They asked the best questions and had the best criticisms and insights. The audiences at academic conferences aren't nearly as good. Google's employees are top-notch. If you are worried about Google's power, you should be worried about why so many of the best and brightest people in the world want to work there (especially when they have a reputation for paying slightly less than competitors like Yahoo and Microsoft). I wouldn't worry much about their accumulation of hardware.
Google started as an academic project at Stanford, and ran on just a few computers (less than 10 IIRC). AFAICT, the current scale of Google to serve many hundreds of millions of users, as well as more frequent re-indexing and fine-tuning of search (to deal with blogs, porn rings, etc). A startup with fewer users could probably survive with a very small number of racks.
About advertising, I don't think advertisers or consumers are loyal to the advertising company. Any ad group that provides additional revenue for the advertiser will find a way to survive. I don't think Google can rest on their adsense laurels (not that they've ever rested on anything).
Come on, you're all new here with your >1000 uids. ;-) I'm glad there are still a few with 100,000.
-Paul Komarek
...and the moral is that we shouldn't use genetic algorithms. ;-)
-Paul Komarek
Royalties? Who is your publisher?
-Paul Komarek
Are auto-levelling devices legal in the US? The US version of the VW Golf GLS does not have a manual headlight aiming adjustment in the cabin, but at least some European versions do.
-Paul Komarek
You want to minimize the chance of destruction whether you're on a city street or in the desert. I doubt there's a prize for coolest disaster.
On the other stuff, I think I didn't communicate my point effectively. You can't just read sensors and rely on their data. Sensors return wrong data, even laser rangefinders. Picking out which data is good and which is bad requires more computation than just 10 serial port reads per second.
Until a person has been involved with these sorts of projects it is very hard to even imagine the scope of the problems. I don't have much robotics experience, my field is data mining and artificial intelligence. But even there the data is always screwed up. Nobody ever gives you a dataset that is complete, or training data that is correct. Much of the time it isn't clear what "correct" even means. The real world sucks big time.
And software sucks big time. I did do some robotics programming for a local company, to control elevators used by their robots. The problems involved were insane. We had troubles getting the elevator companies to give us access to the elevator call buttons (the buttons in the hallways) and the elevator direction and destination -- and I can tell you that getting all that info (which we didn't) was going to cost a lot more than $5000 per installation. We had to estimate the elevator's direction according to floor data, which isn't that hard -- until you run into the problem of elevators which don't have any floor info (some cargo elevators). Then there's the issue of communication. We couldn't run a wired network, and wireless did a poor job penetrating into some elevator cabins. That meant that the elevator doors might open on the wrong floor (due to humans pressing buttons), and we couldn't notify the robot. And we didn't have access to the "door open" button so we had to rely on holding down the floor button. There's also the matter of telling the robot that the cabin has arrived to pick it up -- we don't know when the doors open, and different elevators can take a vastly different amount of time to open the doors.
Thankfully the robot could help a bit for that particular problem.
And I haven't even begun to tell you about the robot navigation problems getting into and out of the elvator, especially for elevators that didn't line up right with the floor. And if there's a wide gap between the elevator and the floor, the rangefinders think there's a 10-storey cliff in front of it. And once you get the robot going, it's wheels might not work well crossing a two-inch gap. But you can't change the wheels because their design is critical to the navigation software.
This was what I encountered in 3 months of consulting for a robotics company whose robots drove very slowly along the walls of uncluttered hallways. All of the problems were dealt with eventually, and many of them had autonomous solutions. But now the robots have a webcam that allows humans to drive it out of bad situations that the software still can't deal with.
Did I mention that the robot tracked the wall to help its navigation? Now think about driving across a sand-covered highway through a sand-covered plain. I'm not sure what these guys are really facing, but I'm sure it's a lot harder than we can possibly imagine.
-Paul Komarek
I don't think you're going to get six good laser rangefinders for $5000. I don't remember the numbers as well as I would like, but I think the current favorite rangefinders (I think the brand is SIC?) are well over $1000 each. And you will quickly exhaust your laptop's computational power just denoising the output from crappy sensors. Heck, maybe even for the best sensors.
Autonomous vehicles have already driven across the country on highways, 98.2% of the time without human intervention. The roads it drove on are (I'm guessing) likely to be much nicer than those in the desert. Furthermore there was a human available to handle the surprises. For humor value: I believe one of the self-driving vechicles from CMU has a learner's permit from the state of Pennsylvania. See No Hands Across America for more info on this project.
The hard part of any project like this is uncertainty in the environment. The road may "disappear" completly from your sensors, or you may spot multiple roads. Maybe some mica on a rock screws up your rangefinder. Maybe your vehcicle's transmission gets a little "funny" and you can't shift properly anymore (I saw such a comment attached to this article). And we aren't even talking about genuine malfunctions like a failing rangefinder or sticky throttle.
I think autonomous systems might be the best example of the best laid plans of mice and men not succeeding when the slightest thing goes wrong. In fact, Steinbeck's story seems directly analgous to the problems of self-driving vehicles.
-Paul Komarek
Thanks for the info. Unlike the other replies, this is useful and enlightening. =-)
-Paul Komarek
I think you haven't been around enough turbines, or enough people who have lost their high-frequency hearing due to turbines (before ear protection was mandatory).
-Paul Komarek
Wouldn't a turbine be unbearably loud in a car? Imagine if every car sounded like a helicopter.
-Paul Komarek
Have a student present a CS homework to the class? Who are you trying to punish? ;-)
-Paul Komarek
"I wonder how close you could get to a working linux machine with nothing officially from GNU?"
Good luck. I doubt you'll want to use the system you end up with anyway. Even FreeBSD uses a bunch of GNU stuff. Commerical UNIX vendors ship CDs of GNU tools alongside their operating system CDs. Embedded systems have GNU stuff in them and GNU influence (toolchains) all over them.
GNU really is everywhere, and for good reason. For isntance, feel free to use non-GNU tar but keep in mind that many (all?) non-GNU tar programs have limits on filename length. Have fun relearning all of the textutils and binary utilities. The GNU versions are richer and better in nearly every case.
It's just not sensible to try to get rid of GNU stuff, unless you switch to Windows. It's the GNU in GNU/Linux that makes it pleasant to use.
-Paul Komarek
FWIW, you don't need to take all of Python with you onto the device. The handhelds.org folks have done a nice job of "modularizing" their python dist.
Still, Python is something extra that you may not be able to afford. I'm personally much more interested in the cross-compiling on a dev machine, including all the portage stuff, and then easy installation into a directory of your choice. Note that this requires packages are built against the libraries in the install directory -- you don't want to link against your host machines glibc if you're using uclibc on the target device.
-Paul Komarek
This article reminded me of things I've seen some foreign students go through in the US. The idea that businesses are happy to screw their customers comes slowly to some. While many (but clearly not all) Americans develop a resistance to twinkies and pop tarts, some foreigners are completely defenseless.
I have grown up in a culture that, to some degree, "understands" television. I know that both the WWF and the Presidential Debates are complete bullshit. I know I shouldn't trust or believe anyone on television (and many in "real" life). I am beginning to conclude that these traits are cultural and have little to do with intelligence.
Which means that Bhutan is screwed. I'd far rather see them explore the internet, because it is easier to realize that you are responsible for what you view.
-Paul Komarek
Computing things as a percentage of GDP ignores fixed costs. A bus pass is a far smaller part of a rich person's salary than a poor person's. The best you can conclude from the percentages is that the poor person is getting screwed. Same thing for movie tickets (although some people like to claim that poor people shouldn't have the right to go to the cinema).
Military spending is generally considered necessary up to at least a level of defense. It doesn't much matter what the GDP is, you still have large costs for people and equpment that you *must* pay. What makes the US military spending so gauling is how far we go beyond defence. It is hard to argue that planes costing $2,000,000,000 each (which are somewhat fragile) are really necessary for self-defense. We're an agressive nation that spends far more on offensive military capabilities than anyone else I can think of. It's far easier to argue that much of Israel's military spending is for defense, given the (continuing) history of wars there, compared to the US.
I'm wondering if the money we send Israel is counted as part of their GDP? If not, military-spending-as-a-percentage-of-GDP probably doesn't compare what we "want" it to.
-Paul Komarek
Incidently, I expect that most supermarket-brand ketchup is probably Heinz rebottled. That main guy at RedHat used to talk about Heinz and branding a lot.
-Paul Komarek
I feel a little silly arguing over what RMS thinks, but I'm going to do it anyway. ;-)
I don't think RMS' primary concerns are features, robustness, or future features or robustness. It seems to me his primary concern is software "neighborly-ness"; that is, the ability to cooperate and share. He certainly isn't worried about convenience, or else he would have taken a job for one of those lisp companies years ago (possibly saving is hands from the lisp-wars), made a bunch of money, and lived "comfortably".
As a very minor point, I don't think he cares much about the functionality of linux (the kernel), either.
-Paul Komarek
We're attempting to switch to gentoo for some headless Alpha "cycle-servers" that are currently running RH7.1. We need to stick with GNU/Linux. We're interested in source-based distros with simple package formats. We believe we can support our needs (mainly the C toolchain and network client programs) if the packaging system is simple enough.
My main gripe with gentoo is that they're a bit too bleeding edge. But we can fix it where we need to with simple changes to their packages, which we then store in a local package repository. It's been a little slow getting started due to AFS/Kerb problems, but we seem to be on our way now.
-Paul Komarek
We ran into a problem where a server had insufficiently many serial ports, and wanted to buy a usb-serial bridge ($50) instead of another terminal server ($1000). However there was no usb-serial bridge (i.e. converter) support in FreeBSD at the time. I believe that KeySpan even offered to work with FreeBSD on supporting their products, but apparently nobody would act as the contact.
We've also had serious problems with FreeBSD on our fileserver, due to a long-overlooked bug when many files are deleted quickly (a quota bug was found in the process, too).
I'm not claiming here that GNU/Linux systems are better, nor will I claim they are worse. But the "It's a server, use FreeBSD!" mantra is silly, at least in our experience. FreeBSD has not been more stable, or faster, or more flexible, or easier to admin than GNU/Linux systems. It's just another version of Free unix on a PC.
-Paul Komarek
Right on! This is where the real innovation happens, right here on /. =-)
-Paul Komarek
Carry? You've got it all wrong. You need a rack with wheels.
Our 42U has 4 1400VA UPSs in it (can't get high-A service) and wheels. If we put a handle on it, can we call it a portable and drag it to class?
Of course, we're not going to have more than about 15 minutes of battery life, and we'll need longer ethernet cables...
-Paul Komarek
Scott, one of the authors, has stated that it is reasonable to attack without access to the source code. See the post 6088358 and Scott's reply at 6088426.
I'm not a security researcher, but I'd guess that disassembling any binary would provide plenty of information to reconstruct any hashing functions used. After all, people have proven themselves pretty clever at modifying closed-source games and finding (other) security problems in closed-source software, having only the binary to work from.
-Paul Komarek
-Paul Komarek
The European Union has laws governing discounting. Microsoft is currently under scrutiny for offering possibly illegal discounts in the past. If the Munich discount wasn't already known, then it's almost certainly going to make things worse for MS.
-Paul Komarek
On the other hand, the Deutsches Museum is awesome. I believe it's the world's largest technical museum. IIRC, it has a full-scale coal mine model in the basement.
And admission is very, very inexpensive.
-Paul Komarek