Ray Weiss has worked with incredible persistence against great odds to get LIGO to happen. He's also (based on my limited experience meeting him 40 years ago) a really nice, down-to-earth guy. I'm delighted that he won. He's absolutely deserves this award, and it's annoying to see a post on Slashdot carping about it instead of celebrating it.
My, I thought I was about the last person around who remembered Weinberg's book, but I see he's republished it. A group I worked with in 1976 used it to guide our approach to building teams and to "egoless programming". As i recall, most ot the examples are from the punch card era, but the reviews on Amazon say that Weinberg's updated it with comments based on experiences in the decades since.
That said, I think it's a stretch to recommend the Psychology of Computer Programming as "Computer Science". It's an interesting exploration of the social dynamics of building good programming teams, but as I recall it has little to do with computer science.
I agree: REAPER may or may not be quite what you're looking for, and it's not open source, but it's got a free distribution for experimental use and the fee for purchasing it for anything other than larger-scale use will be a small fraction of what you pay for that PC anyway. Surprisingly capable for the price.
By the late 1960s, the US panic over Russia's launch of Sputnik had resulted in a significant increase in investment in science education at all levels.
In particular, an experimental program was started at the public Bronx High School of Science in New York City, with the goal of exploring whether high school age students
could successfully program computers. (Computers often cost hundreds of thousands or millions of dollars, so this felt a bit like seeing whether students could
fly a jetlineer).
The school procured a number of small systems including
several of the legendary Olivetti Programma 101s.
The school's main machine, though, was an IBM 1620. It was a decimal (not binary) machine, and the high school's was had the minimum 20K digits (not bytes!) of memory.
Originally, input and output was only via punch cards and the built in typewriter, but by 1968 or 1969 an IBM 1311 disk drive, which was itself the size of a small washing machine, added 2 Million digits of persistent storage, and a 1443 lineprinter was also added.
Students were taught, in this order: machine language, then FORTRAN II, then assembler. That's not a typo. Since the machine was decimal, it wasn't too hard to type in raw machine code onto cards, which could be loaded directly into memory by a short self-booting loader program, which was included on the front of each card deck. There was an assember, but until the hard disk showed up the assembler required that an intermediate deck be punched and loaded each time an assembly was attempted. So, for moderate size programs, it was often easier to write machine code directly. This typically involved manually computing and setting the absolute target of each branch. Here's a picture of the cover of the textbook that students used to learn 1620 programming.
This experiment was, in my opinion, wildly successful. I'm aware of at least 4 quite well known computer scientists who started their programming careers
in the 1960s on that machine at Bronx Science.
In general, many programmers from that era learned on 1620s. Like PDP-11s and Apple-2's later, 1620s were machines
that an individual could get easy access to, and could learn to program at both a low level (machine or assember) and
higher level (FORTRAN, LISP). Famously, the 1620 did not have a general purpose adder implemented in hardware: the add instructions would not produce the usual results until software loaded a table of partial sums into a fixed location in memory. The machine's nickname was thus CADET: Can't Add, Doesn't Even Try.
Read Jack Copeland's book and I think you'll see that some quite remarkable math and perseverance was involved in exploiting the German telex operator's slip up. (Copeland's book is terrific).
I have had the great pleasure of corresponding with Captain Roberts over the past couple of years. Not only did he and his team make an extraordinary contribution to winning WWW II, he has worked tirelessly since the declassification of the Tunny work to get recognition for the many others who contributed heroically and anonymously. It's quite amazing to talk with someone who had the experience of decrypting Adolph Hitler's personal communications, hours after they were sent. Note that most of the work done by Capt. Roberts and his team was done by hand. Colossus eventually helped with some steps, but not at first, and even then many steps remained to be done manually. At 92 Capt. Roberts remains very engaged and passionate about the work done at Bletchley. If there's a concern, it's that he should have been recognized for his work then, as well as for his recent publicity efforts, and one can make the case that MBE doesn't nearly recognize the magnitude of his contribution. Congratulations, Jerry!
According to today's actual posting from Nate Silver, the same data leads him to conclude an 86.3% chance of an Obama win in the electoral college. Still high, but your "Nate Silver's Numbers Project..." headline is true if parsed carefully, but very misleading. If you want to say "I conclude from Nate Silver's numbers...", well fine.
For what it's worth, I was a student at MIT in the early 1970s. I recall in the summer of 1972 hearing a story from other students that is surprisingly similar in general outline, but not in detail. Obviously, my memory from so long ago isn't perfect, what I heard at the time was a rumor anyway, and I haven't really tried to research anything that would corroborate it. That said...
The story was not about Apollo 13, but about another Apollo mission that had established orbit around the moon. Some sort of faulty sensor reading or stuck switch was preventing the system from preparing the necessary rocket firings to break the astronauts out of lunar orbit and send them home. According to these rumors, NASA identified the author of the control code as an MIT student working at the Charles Stark Draper laboratory, which is affiliated with MIT. An emergency call went out to find him, so that he could patch the code to ignore the faulty switch or sensor.
The claim is that the call was taken by friends, who were concerned by the fact that the student in question, whether long-haired or not, was either drunk or stoned out of his gourd at the time. Nonetheless, the student was alerted. He supposedly uttered the obvious "oh !$!$!" and stumbled off to Draper Lab, where in his reduced condition he patched the code and saved the astronauts.
Very much a rumor/urban legend, but suspiciously similar to the new story about Apollo 13. These certainly were the sorts of stories that floated around MIT at the time. I expect that at least a small percentage of them are true.
I hope this gets modded up. Baran did indeed play a crucial role, and the interview with Brand should be must reading for anyone who cares about the history of these things.
Describing his role as congressman, Vint Cerf and Bob Kahn, who played key roles in the development of the Internet and TCP/IP write:
"He was the first elected official to grasp the potential of computer communications to have a broader impact than just improving the conduct of science and scholarship. Though easily forgotten, now, at the time this was an unproven and controversial concept. Our work on the Internet started in 1973 and was based on even earlier work that took place in the mid-late 1960s. But the Internet, as
we know it today, was not deployed until 1983. When the Internet was still
in the early stages of its deployment, Congressman Gore provided
intellectual leadership by helping create the vision of the potential
benefits of high speed computing and communication. As an example, he
sponsored hearings on how advanced technologies might be put to use in
areas like coordinating the response of government agencies to natural
disasters and other crises."
They go on to discuss the important contributions he made as Senator and Vice President.
There's a lot of merit in this story I think, but ultimately it muddies the waters. Certainly, it's claim that government-funded research played a less than key role in the development of internetworking seems to be just plain false.
First of all, the work Xerox did that most resembles the Internet protocols was not Ethernet, but PARC Universal Packet (PUP), which is indeed quite directly comparable to the IP in TCP/IP.
Ethernet, while a terrific piece of work, mostly served to facilitate networking within a single site.
The article also says implies that the Government-funded ARPANET wasn't really the precursor of the Internet. I think that's an over-simplification. Arpanet wasn't the very first packet switching network (see the work of Baran and Davies), and it certainly wasn't an Internet (network of networks), but it really was the direct antecedent of the Internet as we know it. Arpanet connected universities and other research establishments. It proved the viability of a packet-switching network with all the application smarts at the periphery of the network. In almost all cases, what had been Arpanet connections among the early sites evolved (sometimes by way of NSFnet) to TCP/IP Internet connections, running essentially the same applications and services. So, in all those ways, Arpanet was a crucial step on the way to our TCP/IP-based Internet, and of course, ARPANET was government funded.
So, the government-funded work on internetworking seems to have started before the Xerox work, and the Xerox research time explicitly cited Cerf and Kahn as sources of inspiration for the Xerox work on internetworking. Wouldn't it be nice of the WSJ article made all that clear before everyone started using these over simplifications to prove the futility of government-funded research?
Another reason...though somewhat unusual.
40 years ago, I printed on photosensitive cloth a family picture, and it was sewn with backing to make a cover for a throw pillow. The family still has it (and yes, you could get "photo linen" and similar alternatives to printing paper back then).
Seriously, for some pictures, people like the look when canvas is mounted. It gives just a bit more of a reminder of a traditional painting I think.
You really, really want offsite backup in addition to whatever you do at home/office. If "the cloud" works for you, fine, but for many the bandwidth issues are a big problem
One option is to have, in addition to whatever drives you run live, enough extra drives to back up your data twice. Keep one set at home, and another in a safe deposit box. Depending on your risk tolerance, you can use packaged drives, or carefully swap bare drives in eSata enclosures or the like. Backup as often as you can on the set at home. Then every few weeks/months whatever meets your needs, do a swap; put the up-to-date backups in the safe deposit box; take the other set home and use it for new fresh backups. With that as a base, you can usually use cloud-based solutions to make sure there are daily or immediate offsite backups of truly critical data that's changing often.
Trust me: disasters do happen. You can lose a lot if you haven't prepared.
I'll add another "second". It's a terrific little book. What the Elements of Style does for English, Doug does for Javascript.
Yes, like many languages (certainly C++), JavaScript has a bunch of features that are poorly designed. Crockford shows a subset that's flexible and powerful.
What you don't want to do is try to make JavaScript into C/C++. They are different languages, optimized for different things. If you're going to program in a dynamic language like JavaScript or Ruby, don't spend all your time wishing it was static. The advantages are different, but if you're going to use JavaScript, use it in a style that exploits what it's good at. Crockford provides an excellent start.
For a more comprehensive reference, I like JavaScript: The Definitive Guide from O'Reilly.
This posting quotes an unreliable news report, and claims that IETF HTTP working group head Mark Nottingham, "called for it [SPDY] to be included in the HTTP 2.0 standard". Nonsense. It's easy enough to find the actual announcement from Mark which says, in part:
I've put together a charter proposal (see attached) that has us going to WGLC shortly (something that I want to see us do regardless), and starting work on HTTP/2.0. Note that it does NOT call out a starting point; rather, we'll start by asking for proposals, considering them and selecting one based upon the traditional IETF criteria of rough consensus and running code.
Indeed, the proposed formal charter for the new work that's included in Mark's note doesn't mention SPDY at all.
I've been in meetings with Mark about this, and SPDY is no doubt at or near the top of the list in terms of interesting candidate technologies to look at, but it's incorrect to say that Mark is calling for its use in HTTP 2.0. At the very least, the Slashdot post on which this is a comment would do a much better service to the community if it linked and quoted Mark's actual announcement, rather than some hyped up misinterpretation from the press.
All the conspiracy theorists should calm down a little while, and subscribe to the IETF working group mailing list if they really want to see how this plays out.
Proper solutions for Web browsers can improve access-link behavior. These include HTTP/1.1 pipelining and Google's SPDY, both of which can achieve better performance, reduce the total number of packets and bytes transferred, and enable TCP to function better.
I've also spoken with Jim about this, and he definitely views SPDY as potentially part of the solution, not part of the problem. In fact, he was the person who first pointed out the existence of SPDY to me.
BTW: the reason SPDY does relative well with respect to bufferbloat is that it multiplexes a lot of traffic over a single TCP stream, and most lower level TCP software and hardware, including routers, tends to bound the number of packets they'll queue from a single stream. Trouble comes when the same application opens a ton of parallel streams, each of which gets to queue several packets; the result is that together they clog the buffers, add to latency, and prevent other application streams from progressing.
I think it's generally agreed that, especially with typical instruments being made primarily of wood, even seemingly identical instruments have significant variation in tone, and sometimes in playability as well. I would not, for example, expect two Musicman Stingrays to sound exactly the same, even if they were made within days of each other, had exactly the same type of finish, neck shape etc., and were strung with supposedly identical strings. It's not impossible they'd sound about the same, but it certainly would be common for them to sound or feel different somewhat different, and perhaps significantly different. (That's among the reasons that it's still nice to have brick-n-mortar music stores, with good selections of instruments.)
Yes, Lotus Notes is one for the few environments in which I've seen large communities routinely encrypt and/or digitally sign their mail.
There's a reason this is more practical in Notes, and that's because Notes is designed for use primarily in corporations, where centralized or hierarchical management of keys and certs naturally fits the operational structure for the organization. The real trick in Notes is that every user has a public/private key pair; indeed, without that you don't have an identity in Notes. When a new user is authorized into a Notes domain, a certificate is signed by the domain owner, and automatically entered into the same name and address book that's used for expanding abbreviations while names are composed, and for routing mails once their sent. In other words, whenever you're sending mail to another user in your organization using Notes, the system likely has an appropriate certificate in hand for him/her, and a private key for you. So, whether to encrypt or sign then becomes, mostly, a matter of policy.
Indeed, although Notes does have support or S/MIME, so that Notes users can communicate securely with non-Notes users on the Internet, that support is in my experience rarely used. As others have noted, it takes two to tango, and as in other mail systems, individually registering S/MIME certs for your friends is just about as painful in Notes as in other systems.
> So my advice is first figure out which group you fall into.
Pretty good advice, but also figure out what you want to learn, and there are two groups there too, I think:
People who want to take better and better pictures, but who would really be just as happy not to learn about the underlying mechanics or theory. This is a perfectly legitimate path, and whether DSLR or point and shoot, you'll want one with terrific automatic function that's good enough to handle the situations you intend to deal with. E.g. if you're mostly taking those pictures of people you know outside, or up close inside, a point and shoot may be just fine. If you'll be taking them in dim light, or larger rooms inside, then you'll need a camera with some kind of flash arrangement that's both powerful and automatic. That might move you toward a DSLR, possibly with good automated flash attachment.
People who are happy to learn about exposure, focus, and the other building blocks that give you more control over how an image looks, and that let you take pictures in more challenging situations (e.g. on a tripod in low light without flash). For someone with those goals, make sure the camera has controls that make it easy to override automatic exposure, focus, ISO, and other such settings, one that lets you look at histograms of your completed exposures, etc. (Yes, some of this won't make sense if you're a novice, but a good camera store can help).
Also, one other dimension: how much do you care about the quality of the final image. The small sensors used in cheaper point & shoot cameras get pretty mealy looking in low light, and often have such limited range that highlights get blown out on sunny days or with flash. (Check out things like the bright spots on a subject's cheeks or forehead). For snapshots and Web-photos, you may not care; for better quality, the absolute smallest sensor you'd want is a micro-4/3, or a DX size, which is better yet. Pros tend to go for full-frame, but for anyone who's not very serious and experienced, that's likely overkill. The size of the sensor is a characteristic of the camera: you can check reviews and specs to see how big the sensor is in a particular camera. Panasonic, for example, has a line of micro 4/3, whereas Nikon's smallest DSLR sensor is DX (somewhat bigger).
If you want a light camera to carry everywhere and don't care so much about the most beautiful images, then go for something smaller; smaller sensors tend to wind up in smaller cameras
There's an area in the Idaho deserts where even the roadside rest stops have radiation counters. It's an area in which much of the US's early nuclear reactor experimentation was done. I've only driven through, and it's a very stark area (my first hint that something weird was going on: how come the cell phone system has such terrific 3G coverage out here in the middle of nowhere?)
Anyway, a Web search suggests that there's a museum in honor of all this: http://www.inl.gov/ebr/d/ebr-i-brochure.pdf
No clue whether it's still open or worth the trouble, but if you're anywhere close it might be worth checking out. Bring your lead outerwear.
http://www.exploratorium.edu/
Located in San Francisco, near the Presidio, which is a bit east of the entrance to the Golden Gate bridge. I haven't been there in years, but it's a wonderful, creative science learning space, aimed somewhat at children.
Umm. I think it's univerally acknowledged to be a paywall. In fact the New York Times itself refers to it as a paywall. <irony>Um, following that link I just gave will itself count against your NYT paywall limit</irony>
What is true is that you get up to 20 articles free each month, but clicking on a link such as the one on nuclear safety counts against your 20. Where did you see the free for 7 days? My clear understanding is that it's 20 free per month (modulo some weirdness about trying to make links from social networking sites free...though the detailed rules for that aren't documented as far as I know.)
Regarding moto's point about cookies: yes, I'm aware that deleting cookies can reset your count, at least in some cases, but I presume that doing so violates the permissions provided by the NYT on use of the content. Granted, slashdot readers are more likely than others to know how to do stuff like this, and maybe or maybe not some of them consider it appropriate, but one of the bad things about the paywall is that at least for novice users or those experts who choose not to cheat, just doing something as "innocent" as clicking a link can wind up eating through your monthly quota. YMMV.
This/. posting does indicate that what's linked is a NYT article, but it fails to remind that following the link costs you one of your 20 free NYT accesses/month. It would be helpful if the posting were updated with a [paywall] marking, or some such, after the link. Otherwise, thanks for the interesting post!
Slashdot Mirror
Ray Weiss has worked with incredible persistence against great odds to get LIGO to happen. He's also (based on my limited experience meeting him 40 years ago) a really nice, down-to-earth guy. I'm delighted that he won. He's absolutely deserves this award, and it's annoying to see a post on Slashdot carping about it instead of celebrating it.
My, I thought I was about the last person around who remembered Weinberg's book, but I see he's republished it. A group I worked with in 1976 used it to guide our approach to building teams and to "egoless programming". As i recall, most ot the examples are from the punch card era, but the reviews on Amazon say that Weinberg's updated it with comments based on experiences in the decades since. That said, I think it's a stretch to recommend the Psychology of Computer Programming as "Computer Science". It's an interesting exploration of the social dynamics of building good programming teams, but as I recall it has little to do with computer science.
I agree: REAPER may or may not be quite what you're looking for, and it's not open source, but it's got a free distribution for experimental use and the fee for purchasing it for anything other than larger-scale use will be a small fraction of what you pay for that PC anyway. Surprisingly capable for the price.
By the late 1960s, the US panic over Russia's launch of Sputnik had resulted in a significant increase in investment in science education at all levels. In particular, an experimental program was started at the public Bronx High School of Science in New York City, with the goal of exploring whether high school age students could successfully program computers. (Computers often cost hundreds of thousands or millions of dollars, so this felt a bit like seeing whether students could fly a jetlineer). The school procured a number of small systems including several of the legendary Olivetti Programma 101s.
The school's main machine, though, was an IBM 1620. It was a decimal (not binary) machine, and the high school's was had the minimum 20K digits (not bytes!) of memory. Originally, input and output was only via punch cards and the built in typewriter, but by 1968 or 1969 an IBM 1311 disk drive, which was itself the size of a small washing machine, added 2 Million digits of persistent storage, and a 1443 lineprinter was also added.
Students were taught, in this order: machine language, then FORTRAN II, then assembler. That's not a typo. Since the machine was decimal, it wasn't too hard to type in raw machine code onto cards, which could be loaded directly into memory by a short self-booting loader program, which was included on the front of each card deck. There was an assember, but until the hard disk showed up the assembler required that an intermediate deck be punched and loaded each time an assembly was attempted. So, for moderate size programs, it was often easier to write machine code directly. This typically involved manually computing and setting the absolute target of each branch. Here's a picture of the cover of the textbook that students used to learn 1620 programming.
This experiment was, in my opinion, wildly successful. I'm aware of at least 4 quite well known computer scientists who started their programming careers in the 1960s on that machine at Bronx Science. In general, many programmers from that era learned on 1620s. Like PDP-11s and Apple-2's later, 1620s were machines that an individual could get easy access to, and could learn to program at both a low level (machine or assember) and higher level (FORTRAN, LISP). Famously, the 1620 did not have a general purpose adder implemented in hardware: the add instructions would not produce the usual results until software loaded a table of partial sums into a fixed location in memory. The machine's nickname was thus CADET: Can't Add, Doesn't Even Try.
Read Jack Copeland's book and I think you'll see that some quite remarkable math and perseverance was involved in exploiting the German telex operator's slip up. (Copeland's book is terrific).
I have had the great pleasure of corresponding with Captain Roberts over the past couple of years. Not only did he and his team make an extraordinary contribution to winning WWW II, he has worked tirelessly since the declassification of the Tunny work to get recognition for the many others who contributed heroically and anonymously. It's quite amazing to talk with someone who had the experience of decrypting Adolph Hitler's personal communications, hours after they were sent. Note that most of the work done by Capt. Roberts and his team was done by hand. Colossus eventually helped with some steps, but not at first, and even then many steps remained to be done manually. At 92 Capt. Roberts remains very engaged and passionate about the work done at Bletchley. If there's a concern, it's that he should have been recognized for his work then, as well as for his recent publicity efforts, and one can make the case that MBE doesn't nearly recognize the magnitude of his contribution. Congratulations, Jerry!
According to today's actual posting from Nate Silver, the same data leads him to conclude an 86.3% chance of an Obama win in the electoral college. Still high, but your "Nate Silver's Numbers Project..." headline is true if parsed carefully, but very misleading. If you want to say "I conclude from Nate Silver's numbers...", well fine.
Silver's Nov. 4 post is at: http://fivethirtyeight.blogs.nytimes.com/2012/11/05/nov-4-did-hurricane-sandy-blow-romney-off-course/ (paywall :-( )
For what it's worth, I was a student at MIT in the early 1970s. I recall in the summer of 1972 hearing a story from other students that is surprisingly similar in general outline, but not in detail. Obviously, my memory from so long ago isn't perfect, what I heard at the time was a rumor anyway, and I haven't really tried to research anything that would corroborate it. That said...
The story was not about Apollo 13, but about another Apollo mission that had established orbit around the moon. Some sort of faulty sensor reading or stuck switch was preventing the system from preparing the necessary rocket firings to break the astronauts out of lunar orbit and send them home. According to these rumors, NASA identified the author of the control code as an MIT student working at the Charles Stark Draper laboratory, which is affiliated with MIT. An emergency call went out to find him, so that he could patch the code to ignore the faulty switch or sensor.
The claim is that the call was taken by friends, who were concerned by the fact that the student in question, whether long-haired or not, was either drunk or stoned out of his gourd at the time. Nonetheless, the student was alerted. He supposedly uttered the obvious "oh !$!$!" and stumbled off to Draper Lab, where in his reduced condition he patched the code and saved the astronauts.
Very much a rumor/urban legend, but suspiciously similar to the new story about Apollo 13. These certainly were the sorts of stories that floated around MIT at the time. I expect that at least a small percentage of them are true.
I hope this gets modded up. Baran did indeed play a crucial role, and the interview with Brand should be must reading for anyone who cares about the history of these things.
http://web.eecs.umich.edu/~fessler/misc/funny/gore,net.txt
Describing his role as congressman, Vint Cerf and Bob Kahn, who played key roles in the development of the Internet and TCP/IP write:
"He was the first elected official to grasp the potential of computer communications to have a broader impact than just improving the conduct of science and scholarship. Though easily forgotten, now, at the time this was an unproven and controversial concept. Our work on the Internet started in 1973 and was based on even earlier work that took place in the mid-late 1960s. But the Internet, as we know it today, was not deployed until 1983. When the Internet was still in the early stages of its deployment, Congressman Gore provided intellectual leadership by helping create the vision of the potential benefits of high speed computing and communication. As an example, he sponsored hearings on how advanced technologies might be put to use in areas like coordinating the response of government agencies to natural disasters and other crises."
They go on to discuss the important contributions he made as Senator and Vice President.
There's a lot of merit in this story I think, but ultimately it muddies the waters. Certainly, it's claim that government-funded research played a less than key role in the development of internetworking seems to be just plain false.
First of all, the work Xerox did that most resembles the Internet protocols was not Ethernet, but PARC Universal Packet (PUP), which is indeed quite directly comparable to the IP in TCP/IP. Ethernet, while a terrific piece of work, mostly served to facilitate networking within a single site.
The article also says implies that the Government-funded ARPANET wasn't really the precursor of the Internet. I think that's an over-simplification. Arpanet wasn't the very first packet switching network (see the work of Baran and Davies), and it certainly wasn't an Internet (network of networks), but it really was the direct antecedent of the Internet as we know it. Arpanet connected universities and other research establishments. It proved the viability of a packet-switching network with all the application smarts at the periphery of the network. In almost all cases, what had been Arpanet connections among the early sites evolved (sometimes by way of NSFnet) to TCP/IP Internet connections, running essentially the same applications and services. So, in all those ways, Arpanet was a crucial step on the way to our TCP/IP-based Internet, and of course, ARPANET was government funded.
A much less sensationalist but much more balanced history of all this can be found at: http://www.nethistory.info/History%20of%20the%20Internet/origins.html . The record there strongly suggests that Bob Kahn and Vint Cerf were discussing approaches to internetworking (connecting networks) in spring of 1973. Interestingly, the official PARC Research Report on PUP actually cites the Internet work of Cerf and Kahn, specifically their 1974 A Protocol for Packet Network Intercommunication.
So, the government-funded work on internetworking seems to have started before the Xerox work, and the Xerox research time explicitly cited Cerf and Kahn as sources of inspiration for the Xerox work on internetworking. Wouldn't it be nice of the WSJ article made all that clear before everyone started using these over simplifications to prove the futility of government-funded research?
Another reason...though somewhat unusual. 40 years ago, I printed on photosensitive cloth a family picture, and it was sewn with backing to make a cover for a throw pillow. The family still has it (and yes, you could get "photo linen" and similar alternatives to printing paper back then). Seriously, for some pictures, people like the look when canvas is mounted. It gives just a bit more of a reminder of a traditional painting I think.
You really, really want offsite backup in addition to whatever you do at home/office. If "the cloud" works for you, fine, but for many the bandwidth issues are a big problem
One option is to have, in addition to whatever drives you run live, enough extra drives to back up your data twice. Keep one set at home, and another in a safe deposit box. Depending on your risk tolerance, you can use packaged drives, or carefully swap bare drives in eSata enclosures or the like. Backup as often as you can on the set at home. Then every few weeks/months whatever meets your needs, do a swap; put the up-to-date backups in the safe deposit box; take the other set home and use it for new fresh backups. With that as a base, you can usually use cloud-based solutions to make sure there are daily or immediate offsite backups of truly critical data that's changing often.
Trust me: disasters do happen. You can lose a lot if you haven't prepared.
I'll add another "second". It's a terrific little book. What the Elements of Style does for English, Doug does for Javascript. Yes, like many languages (certainly C++), JavaScript has a bunch of features that are poorly designed. Crockford shows a subset that's flexible and powerful.
What you don't want to do is try to make JavaScript into C/C++. They are different languages, optimized for different things. If you're going to program in a dynamic language like JavaScript or Ruby, don't spend all your time wishing it was static. The advantages are different, but if you're going to use JavaScript, use it in a style that exploits what it's good at. Crockford provides an excellent start.
For a more comprehensive reference, I like JavaScript: The Definitive Guide from O'Reilly.
This posting quotes an unreliable news report, and claims that IETF HTTP working group head Mark Nottingham, "called for it [SPDY] to be included in the HTTP 2.0 standard". Nonsense. It's easy enough to find the actual announcement from Mark which says, in part:
Indeed, the proposed formal charter for the new work that's included in Mark's note doesn't mention SPDY at all. I've been in meetings with Mark about this, and SPDY is no doubt at or near the top of the list in terms of interesting candidate technologies to look at, but it's incorrect to say that Mark is calling for its use in HTTP 2.0. At the very least, the Slashdot post on which this is a comment would do a much better service to the community if it linked and quoted Mark's actual announcement, rather than some hyped up misinterpretation from the press. All the conspiracy theorists should calm down a little while, and subscribe to the IETF working group mailing list if they really want to see how this plays out.
A good citation on buffer bloat is Jim Getty's ACM Queue article on Buffer Bloat, in which he says:
I've also spoken with Jim about this, and he definitely views SPDY as potentially part of the solution, not part of the problem. In fact, he was the person who first pointed out the existence of SPDY to me.
BTW: the reason SPDY does relative well with respect to bufferbloat is that it multiplexes a lot of traffic over a single TCP stream, and most lower level TCP software and hardware, including routers, tends to bound the number of packets they'll queue from a single stream. Trouble comes when the same application opens a ton of parallel streams, each of which gets to queue several packets; the result is that together they clog the buffers, add to latency, and prevent other application streams from progressing.
I think it's generally agreed that, especially with typical instruments being made primarily of wood, even seemingly identical instruments have significant variation in tone, and sometimes in playability as well. I would not, for example, expect two Musicman Stingrays to sound exactly the same, even if they were made within days of each other, had exactly the same type of finish, neck shape etc., and were strung with supposedly identical strings. It's not impossible they'd sound about the same, but it certainly would be common for them to sound or feel different somewhat different, and perhaps significantly different. (That's among the reasons that it's still nice to have brick-n-mortar music stores, with good selections of instruments.)
There's a reason this is more practical in Notes, and that's because Notes is designed for use primarily in corporations, where centralized or hierarchical management of keys and certs naturally fits the operational structure for the organization. The real trick in Notes is that every user has a public/private key pair; indeed, without that you don't have an identity in Notes. When a new user is authorized into a Notes domain, a certificate is signed by the domain owner, and automatically entered into the same name and address book that's used for expanding abbreviations while names are composed, and for routing mails once their sent. In other words, whenever you're sending mail to another user in your organization using Notes, the system likely has an appropriate certificate in hand for him/her, and a private key for you. So, whether to encrypt or sign then becomes, mostly, a matter of policy.
Indeed, although Notes does have support or S/MIME, so that Notes users can communicate securely with non-Notes users on the Internet, that support is in my experience rarely used. As others have noted, it takes two to tango, and as in other mail systems, individually registering S/MIME certs for your friends is just about as painful in Notes as in other systems.
> So my advice is first figure out which group you fall into.
Pretty good advice, but also figure out what you want to learn, and there are two groups there too, I think:
Also, one other dimension: how much do you care about the quality of the final image. The small sensors used in cheaper point & shoot cameras get pretty mealy looking in low light, and often have such limited range that highlights get blown out on sunny days or with flash. (Check out things like the bright spots on a subject's cheeks or forehead). For snapshots and Web-photos, you may not care; for better quality, the absolute smallest sensor you'd want is a micro-4/3, or a DX size, which is better yet. Pros tend to go for full-frame, but for anyone who's not very serious and experienced, that's likely overkill. The size of the sensor is a characteristic of the camera: you can check reviews and specs to see how big the sensor is in a particular camera. Panasonic, for example, has a line of micro 4/3, whereas Nikon's smallest DSLR sensor is DX (somewhat bigger).
If you want a light camera to carry everywhere and don't care so much about the most beautiful images, then go for something smaller; smaller sensors tend to wind up in smaller cameras
There's an area in the Idaho deserts where even the roadside rest stops have radiation counters. It's an area in which much of the US's early nuclear reactor experimentation was done. I've only driven through, and it's a very stark area (my first hint that something weird was going on: how come the cell phone system has such terrific 3G coverage out here in the middle of nowhere?) Anyway, a Web search suggests that there's a museum in honor of all this: http://www.inl.gov/ebr/d/ebr-i-brochure.pdf No clue whether it's still open or worth the trouble, but if you're anywhere close it might be worth checking out. Bring your lead outerwear.
http://www.exploratorium.edu/ Located in San Francisco, near the Presidio, which is a bit east of the entrance to the Golden Gate bridge. I haven't been there in years, but it's a wonderful, creative science learning space, aimed somewhat at children.
Highly recommended. As best I can tell from the Web site, it's open these days. An excellent collection of old computers and related "artifacts".
Umm. I think it's univerally acknowledged to be a paywall. In fact the New York Times itself refers to it as a paywall. <irony>Um, following that link I just gave will itself count against your NYT paywall limit</irony> What is true is that you get up to 20 articles free each month, but clicking on a link such as the one on nuclear safety counts against your 20. Where did you see the free for 7 days? My clear understanding is that it's 20 free per month (modulo some weirdness about trying to make links from social networking sites free...though the detailed rules for that aren't documented as far as I know.)
Regarding moto's point about cookies: yes, I'm aware that deleting cookies can reset your count, at least in some cases, but I presume that doing so violates the permissions provided by the NYT on use of the content. Granted, slashdot readers are more likely than others to know how to do stuff like this, and maybe or maybe not some of them consider it appropriate, but one of the bad things about the paywall is that at least for novice users or those experts who choose not to cheat, just doing something as "innocent" as clicking a link can wind up eating through your monthly quota. YMMV.
This /. posting does indicate that what's linked is a NYT article, but it fails to remind that following the link costs you one of your 20 free NYT accesses/month. It would be helpful if the posting were updated with a [paywall] marking, or some such, after the link. Otherwise, thanks for the interesting post!
Hey, we hippies love you too!