Try again. The taxpayers of Florida own that bandwidth.
There is a large difference between paying for something and owning it. While I do not have the UF charter at my fingertips (does anyone? could you look this up, please?) universities typically recieve grants from various levels of government and governmental agencies (in addition to private funds, proceeds from endowment, tuition fees, licensing fees, etc.) which is money given to the schools, mostly to do with what they will. The Florida tax payers may, ultimately, foot much of the bill for operating UF, but the University embodied in its board of regents, trustees, or overseers (depending on the charter) is the owner of things like infrastructure, physical plant, real and intellectual property, and so forth. Therefore the University does own the bandwidth.
But then, I'm just an academician who's spent his adult life in various university settings, not a lawyer. (And I agree with the rest of the parent posting.)
Next time you go to a medical doctor's, dentist's or lawyer's office ask the professional you're seeing if he has an advanced degree (hint: you can't practice medicine or law in most countries without one).
The whole idea behind an advanced degree is to create knowledge, to further the field. In many fields, such as the computer-related ones, substantial amounts of knowledge are created in industry, but you cannot ignore the contributions made by those pursuing their Ph.D.s. The assertion that advanced degrees are for purely academic fields is absurd.
However, the assertion that associate's and bachelor's degrees are for non-professional fields is by and large correct. That, I think, says it all.
p.s. Orthographically, one writes "Ph.D.", not "PH.D".
As I've been maintaining for a while, SCO's assertions of stolen code are baseless, primarily by the observation that SCO is unwilling to point out which parts of the already released and publically available code are theirs. Now we find a couple of snippets that have been leaked and oh-the-humanity they're not possibly infringing.
But, friends, we are the ones missing the point, not them.
Think. Couple their insane assertions, ludicrous threatened lawsuits, and absurd licensing fees with the observation that SCO's stock price has risen quite substantially through this escapade and that many of the primary shareholders are now selling and maybe the real motivation starts to come clear: greed. One sees Enron in miniature form, except that the people who are really screwed here are not shareholders, but adherents to the Open Source movement. I have no idea what we can do to fight back, but we're taking a beating here. Our reputation as a movement has a bad black mark on it now.
The fundamental reason he should not attempt this at all has less to do with his absence of knowledge (he COULD probably learn and do a decent job) and much to do with the substantial liability that he, and his business, would face by these actions.
While I agree that it is entirely plausible that the original poster could educate himself, or be educated, as to the proper way of doing things, I disagree stridently with the assertion that liability is a deep issue here. The primary issue is that with the demonstrated level of competence, he runs a substantial risk of death attempting these repairs. All other concerns, primarily monetary, are secondary: Sure, there's plenty of liability, sure it would likely be illegal, but he could kill himself.
Isn't that sufficient to warrant hiring someone who knows what they're doing? Then you can start talking about liability and legality and realize that you want the person hired to be a licensed, bonded professional to mitigate these clearly secondary issues.
Now, if the original poster does take the time to educate and train himself as to proper wiring techniques (and by the tone of the original posting, we may safely assume that time is of the essence, so this line of reasoning is purely academic) so that the chance of serious injury or death is reduced to acceptable levels, we may again address the issues of liability and legality, and might again decide that hiring a professional is advantageous for the reasons cited in the parent posting. But, again, they are secondary and come to the fore only after the primary risk of personal injury has been ameliorated.
To put it in blunt terms: I don't care how good my workman's comp is, I'd rather not suffer a debilitating injury in the first place.
This sounds very familiar, and like good, sound advice. Unlike most of the opinions aired thus far, this tried to be constructive. I had a similar experience re-wiring (completely) the panel for my high school theater as a student there. Totally illegal for me to do it, yes. Unsafe? No. Did I have an electrician's license? No. Could I have gotten one? Yes, but the 4 years' apprenticeship stopped me. Did I read and follow the local code? Yes. Did I do a good job? Yes.
That said, the real thrust of the reactions here can be perhaps traced to the following social observation: the original poster knows enough to be able to look at a mess of building wiring and recognize that it's problematic, but does not know enough to recognize specific parts, or, for example, the age of various wiring types (when the OP stated "old wiring", I thought, "shit, aluminum" when he meant "cloth insulation"), thus betraying an ignorance which carries a high risk of fire and death in this case. That is the deep problem here, and is the fundamental reason (legality and liability are definitely secondary) a large task such as this should not be attempted by him. Or, at least, by him alone.
This new weapon is a breakthrough in the #1 department, and may be a better technology in every category except for the "accuracy" category, due to the fallout factor.
Not mentioned by the article is that all of the energy-storage elements they described (hafnium, niobium, etc.) are pretty serious chemical poisons, and therefore the radioactive fallout (from leftover material of incomplete explosions) is not the only long-term threat at a deployment site. Also, gamma rays are particularily penetrating making it more difficult to target a limited volume -- unlike an accurately deployed conventional explosion which we've all seen can destroy one building while leaving the next unscathed, the gamma ray exposure would go down smoothly with distance, just like a traditional nuclear device, leading to radiation sickness, leukemias, and so forth at varying radii from the explosion site, also just like a traditional nuclear device.
I've read someone posit (forget where now) that nuclear devices are mostly obsolete for modern warfare, given that we have the ability to so accurately place a conventional weapon thanks to things like GPS-guided bombs. The gist of the argument runs: Want to topple a government, and know which room the head of state happens to be sleeping in? Fly a bomb in through the window.
Also annoying as hell is that from time to time, my CD drive gets into a wedged state. Can't eject, either from command line or button, no process seems to have a hold of the drive, just completely wedged. Why do I have to power cycle the system to fix this?
Yes, it does depend on the company. I've been to installations where no sensitive documents are kept on the servers, the only copy is on a removable hard drive which the user takes home at night.
So, we've two extreme examples, your company, and the ones I've visited. I still stand by my original statement: destruction of other people's data as the original poster suggested is an actionable offense in nearly every company and institution. Installing unauthorized software? That will get you fired in some companies, but not nearly as many as intentionally and specifically interfering with someone's work will.
Where I work (part of Harvard University), Linux is definitely growing, but is a distant third behind Windows and MacOS. The IT department here is pretty strict about what they say you can and cannot do (kind of odd in an academic environment, if you ask me); as an example, one is not supposed to deploy ethernet hubs without seeking permission first. This just to give you an idea about them.
I've been here 3 years. Last year and the year previous to that, all of the IT web pages said that the only officially supported OSes were Windows and MacOS, with a stern implication that that was it (and don't you think about using anything else, grrr!). This year, they've acknowledged that Linux exists, and are giving some support for it. The IT folks are at least aware of Linux now, a change for the better.
Why is this happening? Because there are a few researchers (including me) who have installed Linux on their desktop/analysis machines, and are doing their own system administration. But, these users still need to fit into the global IT picture, for example, communicating with the email servers. As we have migrated from one email system to another recently, the IT folk have visited every single user (no, not kidding) to move their email system over. The fact that I was running Linux was not only no big deal, but they even correctly guessed which mail client I was using, given that I was running Linux. We are, slowly, winning.
And I'm sure you'd be shortly disciplined or out of a job for destroying valuable data, negotiations, documentation, whathaveyou. Sheesh, some moderators don't recognize a troll when they see one.
Although the research reported on in the article sounds like a substantial step forward, I recall reading about a similar corpus-based system to translate between French and English. This would have been in the late 1980s or very early 1990s. The key, for the research I'm vaguely remembering, was that by Canadian law, all legislation had to be published in both languages. Voila, a HUGE hand-translated corpus that, because it was law, needed to be accurate. I was, and remain, impressed by the idea. Anyone else know more?
To start a serious coding stretch, I take care of outstanding things that will be a distraction. Like, as many others have suggested, reading email, Slashdot, checking whatever web pages your mind might drift to, chatting with co-workers and boss, using the bathroom, eating lunch, etc. Then, make a cup of coffee, turn off telephone, select appropriate music, put on headphones, and start cranking.
If you can't leave your development tools in a specific state between coding sessions (ie, if you are required to or prefer to shut down compilers, editors, IDEs, and the like when not in use), then, as others have suggested, leave a syntactical error at a key location which will clue you in to where you were mentally (this is not so much warm up as a token to make the process faster next time around). Even if you don't shut your tools down, it's nice to have a quick description of what you were working on before to continue from. I often will write down a couple of key phrases on a piece of paper or yellow sticky (eg, "check interaction between reduncancy check and precomputation" or "examine compute_latency() output to be sure each event is valid") left on my keyboard.
Now, to really answer the question, I don't think anyone does any mental exercises to warm up. I also don't think they're necessary -- most of the posted answers, including mine, deal with preparing your environment for work, not yourself. The most common exception to this is ingesting caffeine -- and this is well-known to initially have a sharpening effect on cognitive ability. The most difficult part of doing hard coding is recovering the mental state, and while not exactly preparation for coding, it's the biggest step when resuming an earlier coding session, and many other posters have given good tips.
I've written a lot of code. Probably well over a million lines all told, in probably half a dozen different languages (APL, C, C++, Algol, assembler of various flavors, Matlab, Visual Basic, Lisp, who knows what else). Some of it was on contract basis, some as a salaried programmer, some of it as a graduate student, and some of it as a professional scientist.
Every time that I made the choice to cut corners and take a quick-and-dirty solution to a problem, it came back to haunt me. I've lost track of how many times that's happened. However, I still elect that approach at times, because, at times, expediency is more important than correctness. Whenever I knowingly commit such a sin, I *always* document it in the code, and suggest a more rigorous approach in the comments.
When I've taken the time to do things properly, it's given great joy to be able to, say, re-engineer fundamental aspects of an architecture without having to re-write vast tracts of it, or understand quickly and easily what a set of functions are intended to do, or be able to modify years-old code that I haven't looked at since it was initially written. As an example, I've recently been refactoring (to use a chic phrase) code written in the 1995-1999 time frame. Because I took the time to write it well, including documenting it properly, I've saved about 1/2 of the development time on my current project. How? Because I can read my old comments, understand what changes need to be made to integrate the old code into my current suite, and write the new code accordingly. BAM, productivity increases greatly.
Short-term solutions are nearly never the right answer, but if you must, document limitations and any insights into correct solutions. You'll be happy you did when it comes time to correcting the problems later.
Wow. What a bunch of dren. My experience is vastly different.
A decade ago, getting access to Unix was HARD. Sure, a few people could get a shell in a university timeshare setup. However, running 'ls' and 'pine' as non-root in a term emulator doesn't really compare to running a modern productive Unix 'desktop'.
A decade ago (1993), getting access to Unix was easy. Linux existed, and was a pretty functional desktop environment. I started working on my PhD with a Linux desktop connected to a Unix file server. Even within the university crowd, inexpensive Sun boxes (the IPX, in particular) had made desktop Unix a reality. The X Windows system had already reached R5.
Non-PC systems were usually VMS or IBM.
Not to my experience. Non-PC systems were made by Sun, DEC, and IBM and ran Unix or some version of OS/390. We're only talking 10 years ago, not 20.
If you're advocating, it's important to grok that "PC Culture" is as old and entrenced [sic] as Unix culture.
While I condone being culturally aware, it seems that this is at best a misstatement of the culture within the general populace, rather than reality. The PC culture, such as it is, started in the early 80s. The Unix culture started about a decade and a half earlier. The PC culture started as a toy machine running a crippled single-user OS. The Unix culture (traceable to Project MAC) was a full-fledged OS, multitasking, multiuser, with rich applications, etc., by the time the first PC was sold. If you're advocating, it's important to understand that people are slow to change and reluctant to give up their view of reality (as the article's author admits). If you're going to advocate, then be sure to educate as well. Let people know where the best ideas in Windows came from. Let people understand why open software is a Good Thing. Let people understand that Linux (the kernel) started out as a small one-student project, copying the core functionality of an already-existing fully-developed system. Educate them into the notion that computers historically do not need rebooting many times per day, just Windows boxes. Show them how easy it is to get information on any program on a Unix system (ie, man pages). Tell them why antivirus software exists, and why so many attacks take advantage of problems in Microsoft software. Give them truth, set them free.
I have a friend, an engineer, who works for a NASA subcontractor developing payloads which (used to) fly on the Shuttle. This particular subcontractor acts as a design house and liason between scientists and NASA, helping an experiment get successful flight time. They do work from the nuts-and-bolts of the experimental design, to making sure the mechanicals are flight certifiable, to training astronauts on how to run the experiments, to the political dancing necessary with the powers that be at NASA to get something to actually go up.
My friend characterizes scientists as being in two camps: those that want the astronauts to be nothing more than automata, blindly and precisely following instructions, and those that want the astronauts to be more like post-doctoral assistants, able to adapt the experiment on-the-fly should any problems arise. As a scientist, I initially placed myself in the first camp, but with additional thought have realized I'd be much more comfortable in the second camp. The opportunity costs of getting something in orbit, well beyond the monetary costs, are far too great to risk not having a human presence to at least monitor, if not run, an experiment. And astronauts really have an incredible can-do ability.
Yes. Definitely. Fundamentally, this is no different from walking though a metal detector, which we all have accepted as part-and-parcel of living in civilized society. But there are some serious issues to this technology because it allows detailed view with unprecedented accuracy. You'd have been able to tell if J. Edgar Hoover's bras had underwires or not. Who's wearing girdles. Who uses suspenders, and who uses belts. More seriously... Who's had mastectomies. Who has colostomy bags. Who has urethral catheters. Who is wearing knee braces. Who has sutures in their skin. Who is wearing a cardiac event monitor. These later items are considered medical information, and by federal law private, but would clearly be revealed by this search technology even if the body is computationally subtracted away.
The hullabaloo over this and similar devices is that they render the person under inspection apparently naked. This is an understandable objection. It seems, to my naive viewpoint, it would not be so difficult to computationally manipulate the image to remove the body, and leave everything else. After all, airport security (TSA in the US) is supposed to only care about things that are not the body. I've seen MRI scans which have been manipulated to, eg, peel the skull away from the brain, so I cannot imagine that it would be difficult to remove the pseudo-naked body from the data before they are displayed.
[/scientific-musing]
[privacy-rant]
I hate the idea of these and similar technologies which allow semi-secret observation of the populace without court order. Forget the tinfoil hat, you'll have to wrap your entire body in foil now!
Go ahead and write a major application, like something on the order of Office or Mozilla in pure assembly.
Okay, I have. 1,000,000-odd lines of 68HC11 code. It's a multi-tasking controller for an instrument that measures atmospheric pollutants. In fact, it's a series of instruments, and the code is customized for each different instrument design. No browser, no file system (although there is data logging which comes close), and minimal communications ability with the outside world. But, still, a metric ton of assembly code.
How do you do it? By imposing coding structure and conventions that are not unlike what you'd expect a C compiler backend to produce (eg, procedure call and stack conventions, local and global storage, etc.) except that unlike the code produced by a C compiler, I could hand optimize each and every part. This is important since code size is severly limited and the application has hard realtime constraints. You become the compiler... but, yes, portability goes out the window. However, in terms of efficiency, there is no real alternative. Maintenance isn't so hard, since the code is well-commented and conforms to strict coding standards (read: I can look at a function written years ago and immediately understand what it does). And those two things (comments and coding standards) are super important; without them, it would be impossible.
Did the code have classes (like C++)? No. Multiple data types? Yes. Arrays? Yes. Structures? Yes. Abstraction? Yes. Debuggability? Yes, with harware-assist. Portability? No way. But is it doable? Most definitely. Should more code be written this way? Probably not; instead, our compilers should be much, much better than they currently are.
So this Brit (who's REALLY good at chess) put together a machine that overall isn't all that stunning, specifically to play chess.
Let me get this straight: he didn't select a purpose-designed processor, he didn't even do a survey of available processors (forget including non-Intel architecures) to see which would give him the best integer performance for the task, he doesn't consider chipset, he doesn't consider memory architecture, he's willing to accept one hardware-caused crash per month, he seems to think that configuring a machine and having his brother put it together is "building" one, and thinks that a purpose-built machine should be able to accept the OS and data (read: disk contents) from a previous machine without hiccough. While perhaps interesting to the chess afficionados, I fail to see the relevance on Slashdot.
Why are we seeing this article instead of something on any one of the serious chess machines? Why is this article more newsworthy than, say, Anandtech or SharkyExtreme or Tom's Hardware's pick for the baddest machine you can currently build? Just because a Grand Master did it?
To be fair, I have great respect for anyone who can attain the Grand Master level -- that's something I'll never do in my lifetime. He's clearly shown tremendous talent and devotion to chess, and my hat is off to John Nunn for that. But he's a computer harware expert? A supercomputer architect? Are we at the start of a new series of Slashdot articles on computers of the Rich and Famous? What's next, diet tips from RMS? Health advice from Linus? The EFF Cookbook?
Indeed, the "force fields" in use are garden-variety magnetic and electric fields, specially shaped to do two things (1) not disturb the main beam, and (2) constrain the air-leak plasma. But no new physics, no new fields. No semi-visible shimmering curtain in the middle of the room you can't seem to pass through. Interesting, but hardly worth a Slashdot article, and certainly not with the inflated presentation as the parent post so beautifully states. "Scale [it] up," indeed.
You know, all the 6-3's were required to take it, too, and I don't know why you would assume that a computer science major would necessarily know how to solder.
I'm not sure why this comment was posted by an AC since there's really nothing he or she needs to hide, but it bears some elucidation because I was unclear in the parent post it refers to.
Both EE and CS majors (6-1 and 6-3 in the MIT parlance) are required to take 6.002, the progenitor course for 6.002x. In the core curriculum for the department, there are no differences in requirements for the two majors. Through a series of four core courses, both 6-1 and 6-3 students are required to learn how to, eg, write programs from scratch and build computers from scratch. Both should be able to know how to solder (that's the whole idea behind Abelson and Sussman's 6.002x).
But, the real basis for my observations on how few of the 6.002 undergrads knew how to solder is that these were MIT students. They should already have been taking things apart and putting them back together again for years before getting to 77 Mass Ave. My experience, and many of my peers' while an undergrad, echoed this. It was not until TA-ing the course that it became clear how few students knew how to solder. Although this realisation was disappointing, I'm proud to say that all of my students knew how to solder upon completion of 6.002.
I feel badly that the AC writing above did not have a good experience with 6.003 (Signals and Systems, the follow-on course to 6.002, which deals primarily with mathematical constructs like feedback, and the Fourier, Laplace, and Z transforms), as it covers a very powerful subject and can be a deeply satisfying course when taught well. Of all the EECS courses I took at MIT, 6.003 provided me with the most often used ideas.
Disclaimer: I have tremendous respect for Hal Abelson and Gerry Sussman, having worked with both while teaching the MIT EECS core undergraduate curriculum, including 6.002.
The article glosses over a couple of details which are important to understanding what Abelson and Sussman are proposing (as evidenced by many of the comments thus far). The course, 6.002, is already a laboratory couse with required lab assignments. However, there aren't that many (4 or 5), and while one's lab grades are important, it is possible to pass the course (*pass*, not do well) without doing well on the labs. The course is reasonably heavy on theory, and somewhat light on practical knowledge. When I was TA-ing it, I was amazed at how many students did not already know how to solder.
For many students, it was the first lab course ever, so things like oscilloscopes were poorly-understood tools. (As part of the first lab assignment, if I recall, one must prove proficiency with a 'scope.) As a result of this, many of the students don't really get a good understanding of basic parameters and values -- practical knowledge -- because there's so much to learn already, and because there are only 4 or 5 lab assignments and only so many lab TAs.
What Abelson and Sussman are trying to do (and, by the way, they are the authors of what is widely considered one of the best, if not the best, course at MIT, 6.001) is shift some of the tutorial instruction, typically centered on going over lectures and recitations in more detail with an eye towards the homework assignments and similar problems, towards understanding specific real-world problems. They are, in effect, changing the syllabus where it has been previously poorly-defined, and where the student-to-faculty ratio is the lowest, so it can do the most good.
(For those not familiar with the way such courses are structured, there are some number of hundreds of students per term taking the course, and three levels of instruction: twice- or thrice-weekly lectures by senior faculty to the entire class, supplemented by twice-weekly recitations by junior faculty or senior graduate students to sections of 15-30 students, supplemented by once-weekly tutorials by junior graduate students to sections of 4-8 students. This is a well-developed and powerful means of teaching a huge amount of difficult material in a short amount of time to highly-motivated students.)
It will be very interesting to see how 6.002x develops. Very interesting. Might just go and volunteer to help teach next term right now.
Why don't the editors use non-reg links? Like, say, Google caches? Is there some (perhaps nefarious) ownership chain between NYT and Slashdot? Copyright issues? Deep linking issues? What gives?
Slashdot Mirror
Try again. The taxpayers of Florida own that bandwidth.
There is a large difference between paying for something and owning it. While I do not have the UF charter at my fingertips (does anyone? could you look this up, please?) universities typically recieve grants from various levels of government and governmental agencies (in addition to private funds, proceeds from endowment, tuition fees, licensing fees, etc.) which is money given to the schools, mostly to do with what they will. The Florida tax payers may, ultimately, foot much of the bill for operating UF, but the University embodied in its board of regents, trustees, or overseers (depending on the charter) is the owner of things like infrastructure, physical plant, real and intellectual property, and so forth. Therefore the University does own the bandwidth.
But then, I'm just an academician who's spent his adult life in various university settings, not a lawyer. (And I agree with the rest of the parent posting.)
Advanced degrees are for purely academic fields.
Next time you go to a medical doctor's, dentist's or lawyer's office ask the professional you're seeing if he has an advanced degree (hint: you can't practice medicine or law in most countries without one).
The whole idea behind an advanced degree is to create knowledge, to further the field. In many fields, such as the computer-related ones, substantial amounts of knowledge are created in industry, but you cannot ignore the contributions made by those pursuing their Ph.D.s. The assertion that advanced degrees are for purely academic fields is absurd.
However, the assertion that associate's and bachelor's degrees are for non-professional fields is by and large correct. That, I think, says it all.
p.s. Orthographically, one writes "Ph.D.", not "PH.D".
As I've been maintaining for a while, SCO's assertions of stolen code are baseless, primarily by the observation that SCO is unwilling to point out which parts of the already released and publically available code are theirs. Now we find a couple of snippets that have been leaked and oh-the-humanity they're not possibly infringing.
But, friends, we are the ones missing the point, not them.
Think. Couple their insane assertions, ludicrous threatened lawsuits, and absurd licensing fees with the observation that SCO's stock price has risen quite substantially through this escapade and that many of the primary shareholders are now selling and maybe the real motivation starts to come clear: greed. One sees Enron in miniature form, except that the people who are really screwed here are not shareholders, but adherents to the Open Source movement. I have no idea what we can do to fight back, but we're taking a beating here. Our reputation as a movement has a bad black mark on it now.
The fundamental reason he should not attempt this at all has less to do with his absence of knowledge (he COULD probably learn and do a decent job) and much to do with the substantial liability that he, and his business, would face by these actions.
While I agree that it is entirely plausible that the original poster could educate himself, or be educated, as to the proper way of doing things, I disagree stridently with the assertion that liability is a deep issue here. The primary issue is that with the demonstrated level of competence, he runs a substantial risk of death attempting these repairs. All other concerns, primarily monetary, are secondary: Sure, there's plenty of liability, sure it would likely be illegal, but he could kill himself.
Isn't that sufficient to warrant hiring someone who knows what they're doing? Then you can start talking about liability and legality and realize that you want the person hired to be a licensed, bonded professional to mitigate these clearly secondary issues.
Now, if the original poster does take the time to educate and train himself as to proper wiring techniques (and by the tone of the original posting, we may safely assume that time is of the essence, so this line of reasoning is purely academic) so that the chance of serious injury or death is reduced to acceptable levels, we may again address the issues of liability and legality, and might again decide that hiring a professional is advantageous for the reasons cited in the parent posting. But, again, they are secondary and come to the fore only after the primary risk of personal injury has been ameliorated.
To put it in blunt terms: I don't care how good my workman's comp is, I'd rather not suffer a debilitating injury in the first place.
This sounds very familiar, and like good, sound advice. Unlike most of the opinions aired thus far, this tried to be constructive. I had a similar experience re-wiring (completely) the panel for my high school theater as a student there. Totally illegal for me to do it, yes. Unsafe? No. Did I have an electrician's license? No. Could I have gotten one? Yes, but the 4 years' apprenticeship stopped me. Did I read and follow the local code? Yes. Did I do a good job? Yes.
That said, the real thrust of the reactions here can be perhaps traced to the following social observation: the original poster knows enough to be able to look at a mess of building wiring and recognize that it's problematic, but does not know enough to recognize specific parts, or, for example, the age of various wiring types (when the OP stated "old wiring", I thought, "shit, aluminum" when he meant "cloth insulation"), thus betraying an ignorance which carries a high risk of fire and death in this case. That is the deep problem here, and is the fundamental reason (legality and liability are definitely secondary) a large task such as this should not be attempted by him. Or, at least, by him alone.
This new weapon is a breakthrough in the #1 department, and may be a better technology in every category except for the "accuracy" category, due to the fallout factor.
Not mentioned by the article is that all of the energy-storage elements they described (hafnium, niobium, etc.) are pretty serious chemical poisons, and therefore the radioactive fallout (from leftover material of incomplete explosions) is not the only long-term threat at a deployment site. Also, gamma rays are particularily penetrating making it more difficult to target a limited volume -- unlike an accurately deployed conventional explosion which we've all seen can destroy one building while leaving the next unscathed, the gamma ray exposure would go down smoothly with distance, just like a traditional nuclear device, leading to radiation sickness, leukemias, and so forth at varying radii from the explosion site, also just like a traditional nuclear device.
I've read someone posit (forget where now) that nuclear devices are mostly obsolete for modern warfare, given that we have the ability to so accurately place a conventional weapon thanks to things like GPS-guided bombs. The gist of the argument runs: Want to topple a government, and know which room the head of state happens to be sleeping in? Fly a bomb in through the window.
Hear, hear! I completely agree.
Also annoying as hell is that from time to time, my CD drive gets into a wedged state. Can't eject, either from command line or button, no process seems to have a hold of the drive, just completely wedged. Why do I have to power cycle the system to fix this?
Yes, it does depend on the company. I've been to installations where no sensitive documents are kept on the servers, the only copy is on a removable hard drive which the user takes home at night.
So, we've two extreme examples, your company, and the ones I've visited. I still stand by my original statement: destruction of other people's data as the original poster suggested is an actionable offense in nearly every company and institution. Installing unauthorized software? That will get you fired in some companies, but not nearly as many as intentionally and specifically interfering with someone's work will.
Where I work (part of Harvard University), Linux is definitely growing, but is a distant third behind Windows and MacOS. The IT department here is pretty strict about what they say you can and cannot do (kind of odd in an academic environment, if you ask me); as an example, one is not supposed to deploy ethernet hubs without seeking permission first. This just to give you an idea about them.
I've been here 3 years. Last year and the year previous to that, all of the IT web pages said that the only officially supported OSes were Windows and MacOS, with a stern implication that that was it (and don't you think about using anything else, grrr!). This year, they've acknowledged that Linux exists, and are giving some support for it. The IT folks are at least aware of Linux now, a change for the better.
Why is this happening? Because there are a few researchers (including me) who have installed Linux on their desktop/analysis machines, and are doing their own system administration. But, these users still need to fit into the global IT picture, for example, communicating with the email servers. As we have migrated from one email system to another recently, the IT folk have visited every single user (no, not kidding) to move their email system over. The fact that I was running Linux was not only no big deal, but they even correctly guessed which mail client I was using, given that I was running Linux. We are, slowly, winning.
... they'd be formatted with extreme prejudice.
And I'm sure you'd be shortly disciplined or out of a job for destroying valuable data, negotiations, documentation, whathaveyou. Sheesh, some moderators don't recognize a troll when they see one.
Although the research reported on in the article sounds like a substantial step forward, I recall reading about a similar corpus-based system to translate between French and English. This would have been in the late 1980s or very early 1990s. The key, for the research I'm vaguely remembering, was that by Canadian law, all legislation had to be published in both languages. Voila, a HUGE hand-translated corpus that, because it was law, needed to be accurate. I was, and remain, impressed by the idea. Anyone else know more?
To start a serious coding stretch, I take care of outstanding things that will be a distraction. Like, as many others have suggested, reading email, Slashdot, checking whatever web pages your mind might drift to, chatting with co-workers and boss, using the bathroom, eating lunch, etc. Then, make a cup of coffee, turn off telephone, select appropriate music, put on headphones, and start cranking.
If you can't leave your development tools in a specific state between coding sessions (ie, if you are required to or prefer to shut down compilers, editors, IDEs, and the like when not in use), then, as others have suggested, leave a syntactical error at a key location which will clue you in to where you were mentally (this is not so much warm up as a token to make the process faster next time around). Even if you don't shut your tools down, it's nice to have a quick description of what you were working on before to continue from. I often will write down a couple of key phrases on a piece of paper or yellow sticky (eg, "check interaction between reduncancy check and precomputation" or "examine compute_latency() output to be sure each event is valid") left on my keyboard.
Now, to really answer the question, I don't think anyone does any mental exercises to warm up. I also don't think they're necessary -- most of the posted answers, including mine, deal with preparing your environment for work, not yourself. The most common exception to this is ingesting caffeine -- and this is well-known to initially have a sharpening effect on cognitive ability. The most difficult part of doing hard coding is recovering the mental state, and while not exactly preparation for coding, it's the biggest step when resuming an earlier coding session, and many other posters have given good tips.
I've written a lot of code. Probably well over a million lines all told, in probably half a dozen different languages (APL, C, C++, Algol, assembler of various flavors, Matlab, Visual Basic, Lisp, who knows what else). Some of it was on contract basis, some as a salaried programmer, some of it as a graduate student, and some of it as a professional scientist.
Every time that I made the choice to cut corners and take a quick-and-dirty solution to a problem, it came back to haunt me. I've lost track of how many times that's happened. However, I still elect that approach at times, because, at times, expediency is more important than correctness. Whenever I knowingly commit such a sin, I *always* document it in the code, and suggest a more rigorous approach in the comments.
When I've taken the time to do things properly, it's given great joy to be able to, say, re-engineer fundamental aspects of an architecture without having to re-write vast tracts of it, or understand quickly and easily what a set of functions are intended to do, or be able to modify years-old code that I haven't looked at since it was initially written. As an example, I've recently been refactoring (to use a chic phrase) code written in the 1995-1999 time frame. Because I took the time to write it well, including documenting it properly, I've saved about 1/2 of the development time on my current project. How? Because I can read my old comments, understand what changes need to be made to integrate the old code into my current suite, and write the new code accordingly. BAM, productivity increases greatly.
Short-term solutions are nearly never the right answer, but if you must, document limitations and any insights into correct solutions. You'll be happy you did when it comes time to correcting the problems later.
HOLYSHIT man, thanks for the link! And here I thought no one ever read my stuff ...
Wow. What a bunch of dren. My experience is vastly different.
A decade ago, getting access to Unix was HARD. Sure, a few people could get a shell in a university timeshare setup. However, running 'ls' and 'pine' as non-root in a term emulator doesn't really compare to running a modern productive Unix 'desktop'.
A decade ago (1993), getting access to Unix was easy. Linux existed, and was a pretty functional desktop environment. I started working on my PhD with a Linux desktop connected to a Unix file server. Even within the university crowd, inexpensive Sun boxes (the IPX, in particular) had made desktop Unix a reality. The X Windows system had already reached R5.
Non-PC systems were usually VMS or IBM.
Not to my experience. Non-PC systems were made by Sun, DEC, and IBM and ran Unix or some version of OS/390. We're only talking 10 years ago, not 20.
If you're advocating, it's important to grok that "PC Culture" is as old and entrenced [sic] as Unix culture.
While I condone being culturally aware, it seems that this is at best a misstatement of the culture within the general populace, rather than reality. The PC culture, such as it is, started in the early 80s. The Unix culture started about a decade and a half earlier. The PC culture started as a toy machine running a crippled single-user OS. The Unix culture (traceable to Project MAC) was a full-fledged OS, multitasking, multiuser, with rich applications, etc., by the time the first PC was sold. If you're advocating, it's important to understand that people are slow to change and reluctant to give up their view of reality (as the article's author admits). If you're going to advocate, then be sure to educate as well. Let people know where the best ideas in Windows came from. Let people understand why open software is a Good Thing. Let people understand that Linux (the kernel) started out as a small one-student project, copying the core functionality of an already-existing fully-developed system. Educate them into the notion that computers historically do not need rebooting many times per day, just Windows boxes. Show them how easy it is to get information on any program on a Unix system (ie, man pages). Tell them why antivirus software exists, and why so many attacks take advantage of problems in Microsoft software. Give them truth, set them free.
I have a friend, an engineer, who works for a NASA subcontractor developing payloads which (used to) fly on the Shuttle. This particular subcontractor acts as a design house and liason between scientists and NASA, helping an experiment get successful flight time. They do work from the nuts-and-bolts of the experimental design, to making sure the mechanicals are flight certifiable, to training astronauts on how to run the experiments, to the political dancing necessary with the powers that be at NASA to get something to actually go up.
My friend characterizes scientists as being in two camps: those that want the astronauts to be nothing more than automata, blindly and precisely following instructions, and those that want the astronauts to be more like post-doctoral assistants, able to adapt the experiment on-the-fly should any problems arise. As a scientist, I initially placed myself in the first camp, but with additional thought have realized I'd be much more comfortable in the second camp. The opportunity costs of getting something in orbit, well beyond the monetary costs, are far too great to risk not having a human presence to at least monitor, if not run, an experiment. And astronauts really have an incredible can-do ability.
Yes. Definitely. Fundamentally, this is no different from walking though a metal detector, which we all have accepted as part-and-parcel of living in civilized society. But there are some serious issues to this technology because it allows detailed view with unprecedented accuracy. You'd have been able to tell if J. Edgar Hoover's bras had underwires or not. Who's wearing girdles. Who uses suspenders, and who uses belts. More seriously ... Who's had mastectomies. Who has colostomy bags. Who has urethral catheters. Who is wearing knee braces. Who has sutures in their skin. Who is wearing a cardiac event monitor. These later items are considered medical information, and by federal law private, but would clearly be revealed by this search technology even if the body is computationally subtracted away.
[scientific-musing]
The hullabaloo over this and similar devices is that they render the person under inspection apparently naked. This is an understandable objection. It seems, to my naive viewpoint, it would not be so difficult to computationally manipulate the image to remove the body, and leave everything else. After all, airport security (TSA in the US) is supposed to only care about things that are not the body. I've seen MRI scans which have been manipulated to, eg, peel the skull away from the brain, so I cannot imagine that it would be difficult to remove the pseudo-naked body from the data before they are displayed.
[/scientific-musing]
[privacy-rant]
I hate the idea of these and similar technologies which allow semi-secret observation of the populace without court order. Forget the tinfoil hat, you'll have to wrap your entire body in foil now!
[/privacy-rant]
Go ahead and write a major application, like something on the order of Office or Mozilla in pure assembly.
... but, yes, portability goes out the window. However, in terms of efficiency, there is no real alternative. Maintenance isn't so hard, since the code is well-commented and conforms to strict coding standards (read: I can look at a function written years ago and immediately understand what it does). And those two things (comments and coding standards) are super important; without them, it would be impossible.
Okay, I have. 1,000,000-odd lines of 68HC11 code. It's a multi-tasking controller for an instrument that measures atmospheric pollutants. In fact, it's a series of instruments, and the code is customized for each different instrument design. No browser, no file system (although there is data logging which comes close), and minimal communications ability with the outside world. But, still, a metric ton of assembly code.
How do you do it? By imposing coding structure and conventions that are not unlike what you'd expect a C compiler backend to produce (eg, procedure call and stack conventions, local and global storage, etc.) except that unlike the code produced by a C compiler, I could hand optimize each and every part. This is important since code size is severly limited and the application has hard realtime constraints. You become the compiler
Did the code have classes (like C++)? No. Multiple data types? Yes. Arrays? Yes. Structures? Yes. Abstraction? Yes. Debuggability? Yes, with harware-assist. Portability? No way. But is it doable? Most definitely. Should more code be written this way? Probably not; instead, our compilers should be much, much better than they currently are.
So this Brit (who's REALLY good at chess) put together a machine that overall isn't all that stunning, specifically to play chess.
Let me get this straight: he didn't select a purpose-designed processor, he didn't even do a survey of available processors (forget including non-Intel architecures) to see which would give him the best integer performance for the task, he doesn't consider chipset, he doesn't consider memory architecture, he's willing to accept one hardware-caused crash per month, he seems to think that configuring a machine and having his brother put it together is "building" one, and thinks that a purpose-built machine should be able to accept the OS and data (read: disk contents) from a previous machine without hiccough. While perhaps interesting to the chess afficionados, I fail to see the relevance on Slashdot.
Why are we seeing this article instead of something on any one of the serious chess machines? Why is this article more newsworthy than, say, Anandtech or SharkyExtreme or Tom's Hardware's pick for the baddest machine you can currently build? Just because a Grand Master did it?
To be fair, I have great respect for anyone who can attain the Grand Master level -- that's something I'll never do in my lifetime. He's clearly shown tremendous talent and devotion to chess, and my hat is off to John Nunn for that. But he's a computer harware expert? A supercomputer architect? Are we at the start of a new series of Slashdot articles on computers of the Rich and Famous? What's next, diet tips from RMS? Health advice from Linus? The EFF Cookbook?
Just add a webcam and centralized control from the hotel's back office and we come ever closer to George Orwell's predictions.
Don't mod this funny, this is seriously getting scary.
Indeed, the "force fields" in use are garden-variety magnetic and electric fields, specially shaped to do two things (1) not disturb the main beam, and (2) constrain the air-leak plasma. But no new physics, no new fields. No semi-visible shimmering curtain in the middle of the room you can't seem to pass through. Interesting, but hardly worth a Slashdot article, and certainly not with the inflated presentation as the parent post so beautifully states. "Scale [it] up," indeed.
You know, all the 6-3's were required to take it, too, and I don't know why you would assume that a computer science major would necessarily know how to solder.
I'm not sure why this comment was posted by an AC since there's really nothing he or she needs to hide, but it bears some elucidation because I was unclear in the parent post it refers to.
Both EE and CS majors (6-1 and 6-3 in the MIT parlance) are required to take 6.002, the progenitor course for 6.002x. In the core curriculum for the department, there are no differences in requirements for the two majors. Through a series of four core courses, both 6-1 and 6-3 students are required to learn how to, eg, write programs from scratch and build computers from scratch. Both should be able to know how to solder (that's the whole idea behind Abelson and Sussman's 6.002x).
But, the real basis for my observations on how few of the 6.002 undergrads knew how to solder is that these were MIT students. They should already have been taking things apart and putting them back together again for years before getting to 77 Mass Ave. My experience, and many of my peers' while an undergrad, echoed this. It was not until TA-ing the course that it became clear how few students knew how to solder. Although this realisation was disappointing, I'm proud to say that all of my students knew how to solder upon completion of 6.002.
I feel badly that the AC writing above did not have a good experience with 6.003 (Signals and Systems, the follow-on course to 6.002, which deals primarily with mathematical constructs like feedback, and the Fourier, Laplace, and Z transforms), as it covers a very powerful subject and can be a deeply satisfying course when taught well. Of all the EECS courses I took at MIT, 6.003 provided me with the most often used ideas.
Disclaimer: I have tremendous respect for Hal Abelson and Gerry Sussman, having worked with both while teaching the MIT EECS core undergraduate curriculum, including 6.002.
The article glosses over a couple of details which are important to understanding what Abelson and Sussman are proposing (as evidenced by many of the comments thus far). The course, 6.002, is already a laboratory couse with required lab assignments. However, there aren't that many (4 or 5), and while one's lab grades are important, it is possible to pass the course (*pass*, not do well) without doing well on the labs. The course is reasonably heavy on theory, and somewhat light on practical knowledge. When I was TA-ing it, I was amazed at how many students did not already know how to solder.
For many students, it was the first lab course ever, so things like oscilloscopes were poorly-understood tools. (As part of the first lab assignment, if I recall, one must prove proficiency with a 'scope.) As a result of this, many of the students don't really get a good understanding of basic parameters and values -- practical knowledge -- because there's so much to learn already, and because there are only 4 or 5 lab assignments and only so many lab TAs.
What Abelson and Sussman are trying to do (and, by the way, they are the authors of what is widely considered one of the best, if not the best, course at MIT, 6.001) is shift some of the tutorial instruction, typically centered on going over lectures and recitations in more detail with an eye towards the homework assignments and similar problems, towards understanding specific real-world problems. They are, in effect, changing the syllabus where it has been previously poorly-defined, and where the student-to-faculty ratio is the lowest, so it can do the most good.
(For those not familiar with the way such courses are structured, there are some number of hundreds of students per term taking the course, and three levels of instruction: twice- or thrice-weekly lectures by senior faculty to the entire class, supplemented by twice-weekly recitations by junior faculty or senior graduate students to sections of 15-30 students, supplemented by once-weekly tutorials by junior graduate students to sections of 4-8 students. This is a well-developed and powerful means of teaching a huge amount of difficult material in a short amount of time to highly-motivated students.)
It will be very interesting to see how 6.002x develops. Very interesting. Might just go and volunteer to help teach next term right now.
Why don't the editors use non-reg links? Like, say, Google caches? Is there some (perhaps nefarious) ownership chain between NYT and Slashdot? Copyright issues? Deep linking issues? What gives?