What happens when enough old people are gazillionaires that they basically set policy (answer: I doubt it will be to the benefit of the young)
You mean that old people don't basically set policy already (at least in the U.S.)? Up until recently any politician who even breathed a word implying that Social Security or Medicare benefits would be reduced, or even held constant, could count on getting kicked to the curb.
The Baby Boomers and their parents have saddled their children and grandchildren with a crushing debt while enjoying the benefits of shifting a bunch of spending from the future to the present. In my opinion it's time for them to start repaying the piper.
Perhaps I was lucky, but I did read the top three books I'd recommend as I was starting my first job:
1. Advanced Programming in the UNIX Environment, W. Richard Stevens. This was influential in teaching me what clean functional programming interfaces look like, and hopefully the code I've developed since then has lived up to that ideal.
2. Network Programming in the UNIX Environment, W. Richard Stevens. Much the same as the first title, but in some ways illustrating programming interfaces that tackle more complex/flexible situations.
3. Writing Solid Code. Steve Maguire. Fifteen years later I still daily use a few of the ideas presented in the title. However it also served to show me the ugliness of some programming conventions (e.g. Hungarian Notation and StudlyCaps()) and led me to avoid those practices in my own code when I have a choice (i.e. when not having to conform to the style of existing code).
BIOS does actually very little these days. The OS re-initializes most devices anyway on boot
Well, actually being a BIOS developer, I can state with absolute confidence that you're wrong about BIOS doing very little these days.
The BIOS these days takes care of an incredible amount of work, such as detecting, training, testing, and configuring RAM, initializing the CPU state on many cores, configuring the interconnect between processors (QPI on some recent Intel processors, HT on AMD), setting up system memory maps, probing and setting up the entire IO fabric, building tables (e.g. ACPI) that fully describe every nitty-gritty aspect of the system to the OS, make your USB keyboard and mouse functional for ancient OSes, work around problems in hardware, have small drivers for accessing myriad devices for reading blocks from boot devices, in the case of EFI/UEFI manage options for boot ordering as well as bazillions of basic system settings, actually implementing each and every one of those bazillion settings, handle all sorts of hardware abstractions in the form of BIOS/EFI calls, manage and configure IO BARs, provide code to handle all sorts of potential correctable (and sadly sometimes uncorrectable) hardware errors, in some cases provide disaster fallback paths if you manage to corrupt the main BIOS image, in the case of EFI provide a runtime environment for pre-OS applications, etc. -- and do all of this with absolutely nothing underneath it other than hardware. If you think this is "very little", I'd encourage you to find a job developing BIOS code, and I think you'd be overwhelmed by the sheer bulk of the codebase in a modern BIOS. Just the source code trees these days push a fair bit over the 100MB level. Seriously.
Having also worked on OSes and kernel-level device drivers, it is true that the OS re-initializes a fair bit of the hardware, but not nearly the level of hardware the BIOS initializes (have fun trying to re-train RAM or reconfigure the CPU interconnect, for example). If anything the trend has been toward the BIOS taking on greater and greater responsibility for device initialization and provision of runtime services to make the OS less aware of "quirks" in the hardware. That's not to say there isn't a ton of work the OS still has to do, but your statement vastly over-trivializes the role of the BIOS in modern machines.
Heresy! There's no way I'm parking my Hypercar, ever -- I won't even permit it to slow down. Next thing we know you'll be encouraging consumption of non-cheeseburger foods.
It is complete nonsense to try to tie the 35W bridge collapse to the current administration, and your rhetoric attempting to do so comes up short
Let's see -- there is known to have been a design deficiency in the original bridge that could lead to catastrophic failure if a single component fails, i.e. the "fracture critical" design.
The fracture critical component which failed which led to the collapse had been inspected on previous occasions, but the failure was not detected in those inspections. It is not that the inspection was not done, but that the failure in progress was not noticed by the engineering firm which performed the inspection. As best I've ever heard this firm was not a slipshod outfit, though obviously their inspection methodology missed this particular point.
Explain to me again how this is a failure of the Minnesota executive branch? Explain to me again how this is attributable to holding the line on tax issues?
For perhaps the first time in my life I've seen an elected official stick to what they promised when running for office. The governor did _exactly_ what he promised he would do when he originally ran, admittedly shifting certain expenses onto those who make direct use of certain state services. Not only this, but after doing so he was re-elected during a time when the gloss was off the Republican apple, in a traditionally very Democratic-party friendly state. So the voters re-confirmed that yes, they liked how he was handling taxation issues, and that he should stay the course.
So, pick your poison: an elected official who keeps their word (or at least the spirit of it), or one who promises one thing and then does another once elected. I may or may not agree with a politician, but if they keep their word at least I know with certainty what to expect of them.
And one final thought -- I recently looked into relative taxation and spending rates between the various states. The information I could readily find indicated that Minnesota was about 6th highest in taxation, and about 12th highest in spending, per capita for each stat. Draw what conclusions you will, but this indicates to me that the state has both a spending problem, and an even more significant taxation problem, relative to other states. I find it difficult to fault the current governor for opposing overall tax increases when I see relative rankings such as this.
Hey, I have a LeCroy 9450A that has some, umm, "issues" when powering up. It often takes several power cycles before it will successfully boot.
I can't figure out a way to contact you directly through/., but if you'd be interested in earning a few bucks repairing my scope, I'd like to talk to you.
Because last time I checked "byte" isn't a friggin' SI unit of measurement. Meters, Litres, Grams, Kelvin, Joules, Watts, Pascals, yes. Bytes, eggs, toes, dollars, no.
I'm all in favor of the SI system, and wish we here in the U.S. would cut over. But keep your SI prefix hands off of my non-SI units.
It's simple really -- the same way you build up relationships with people outside the office -- around food and drink.
Things that have worked very successfully at my workplace (not all in place at the same time over the years):
- Friday Beer Bash. 3PM on Fridays (or most Fridays) have a self-sponsored beer bash. A few volunteers buy beer, some non-alcoholic beverages, and some chips/cookies etc. Everyone is invited to come, sit, and visit. Everyone is expected to chip in a couple bucks toward the food.
- Donuts. A set of people gets together at the same time in the morning once a week (Friday at 8AM when we did it) for donuts in the conference room. This isn't a "come grab a donut and go back to your office/cube" thing, but sit around the conference room and talk about anything and everything (work related or not). The participants are on a rotation to bring donuts, milk, and juice, paying out of their own pocket whenever their rotation comes around.
- Grilling. Pitch in together to buy a grill (or get one donated by someone, or the company). During months where the weather is nice enough, grill lunch outside, everyone bringing their own items to grill that day. Probably do this once a week. Organize payment for propane/charcoal however makes sense (chip in a buck once a week/etc).
- Cooking contests. An annual brownie contest, chili and cornbread contest, etc. A panel of employee judges gets to judge the contest, or everyone in attendance votes for their favorites. Have some sort of small prizes for the top three (e.g. small gift cards), funded however makes sense (company, entrance fee, proceeds from employees chipping in at the door to cover extras like beverages).
- Often the "self-sponsored" events above (beer bash, grilling, donuts if you choose to do it that way) end up generating more cash than actual costs. Whenever the amount builds up to a sufficient level, have a "free" pizza/whatever lunch paid out of the proceeds.
- Not quite a food thing, more of a beer thing, but start up a bowling league, company softball team, or something like that that gets people from different departments to join up around a common interest.
There's at least one notable substance that shares this property: Water. That's why it forms ice on the top surface rather than along the bottom/sides of the container (be that container a bucket, a river, or a lake). This very fact is instrumental to life on our little globe.
You answered your own question -- it's a "relatively simple tool". The tool has relatively little value-add or innovation compared to their other work. They'd rather spend their employees' time on developing software more core to their business.
The fact that this particular utility isn't particularly core to their business or seen as critically valueable or innovative is evidenced by the quick turnaround in releasing the source code. It's so far from their core business that it's just not worth their developers' and lawyers' time to rewrite/relicense/etc. the code to avoid the GPL entanglement, so the least expensive route to their objectives was to release the code.
If only I could mod the parent +1 Insightful and post... but I'll choose posting.
Most of the commenters do not realize that Joel is, at the heart of things, railing against over-complicated design more than praising lazy programming practices. Unfortunately that's not how he titled the article, and the reaction is thus predictable. I sincerely doubt he'd advocate sloppiness of code or design.
Unfortunately there are very non-junior designers who never make transition #3 (or maybe they regressed). As a result of their seniority and presumed competence, they are placed in a position to over-engineer solutions, miss market opportunities, and starve less elegant but competing solutions of the manpower and attention which bring the 50% solution up to a 95% solution. And unfortunately when their supervisor is too busy with other business concerns and a bit out of date with their technical knowledge, the necessary checks on over-engineering don't get applied. Couple that with politics/turf/etc typical of many businesses, and the non-over-engineered solution loses out. The entire organization suffers as a result, missing deadlines, solutions that aren't, and eventually it impacts the bottom line.
Personally I haven't made transition #4, however I'm starting to glimpse what it means. I'm not yet convinced that I care enough to make that transition, but I think that's a normal part of the process of growing.
Forget a mouse, forget wireless unless you're using a laptop.
The best dang "mouse" I've ever found is a Microsoft Trackball Explorer. Five buttons plus scrollwheel. I've used xmodmap to remap the buttons to help alleviate some nascent carpal tunnel symptoms. I own two of them, using one at work, and one at home. It does tend to get a bit gummed up on the trackball bearings, but about once a week I just swab around them with whatever pointy object is handy (paper clip, pen, thumbtack), and all is well. It'd probably help if I didn't eat junk food while working on the computer, and thus get all that goo on the trackball itself.
Unfortunately they stopped making it a few years ago. And when I say "unfortunately", know full well that I refuse to give Microsoft a dime for anything other than Trackball Explorers and keyboards, so you know the Trackball Explorer has to be awesome to overcome my loathing of Redmond.
When I was fairly new to my company code reviews were reasonably helpful, as I was certainly not an expert in the areas I was fixing bugs, and there was a lot of undocumented knowledge of how various components interacted with eachother. As time went on and I became more proficient in these areas, code reviews began to be less useful.
I then moved on to taking primary responsibility for an important system library whose original developer left years earlier, and the current maintainer had been layed off. A year into that effort I was effectively the only person in the company who understood how the library worked, and as such was the sole expert on it. Code reviews for checkins were still mandatory, but about the only thing any other reviewer would ever find were minor stylistic issues -- the real bugs went undetected because the expertise required to detect them just wasn't reasonable to expect of anyone else.
Today I find myself working on deep close-to-the-metal code. Due to economic conditions it's just not feasible to have any overlap between engineers in the areas they're deeply familiar with (yes, that's a management issue -- city bus syndrome is a very real risk). For all but the smallest changes, others cannot fully understand the implications of my changes when they review my code, and I cannot understand the implications of the changes when I review their code. We still keep at it, but the effort rarely catches real problems.
Alongside those issues, I have been with this company for more than ten years, yet in my particular group I'm the youngest person with the least experience. With such a mature and historied team, significant mistakes are exceedingly rare, and even minor mistakes are uncommon. The most common thing we catch is someone forgetting to update the current copyright date in a file's comment block.
For the stated reasons, I currently view code reviews as generally just an extra hoop to jump through in the checkin process. If I should ever change jobs, I'm sure I'd once again appreciate having more experienced developers double-checking my efforts.
I know that some of the water comes up from the ground on Progress vehicles, so you are correct on that front. However I've watched the NASA TV channel quite a bit over the past year, and during the recent missions where the urine processing system was installed and fixed, it was definitely stated that water generated from the Shuttle engines is transferred to the ISS. The other poster is correct as well, in that NASA TV stated that the end of shuttle flights was part of the motivation behind installing the water recycling system.
I don't believe water transfer is done via a umbilical, instead bags of water are filled on the Shuttle and transferred oto the ISS. However, I could well be wrong regarding this point.
> Everyone drinks recycled urine and sweat every day.
While a good point, this may not be quite as true in the case of the astronauts aboard ISS.
A large portion of the water delivered to ISS comes from the Space Shuttle as it combusts liquid hydrogen to power itself while docked. Depending on the source of the liquid hydrogen and oxygen fuel (i.e. Is it generated from electrolysis of water? Condensed directly from the atmosphere? etc), it's possible a significant portion of their water supply has never been urine or sweat before.
And even if the liquid hydrogen and oxygen was water previously, do water molecules generated from hydrogen combustion really count as "recycled"?
I hate to say this since I don't even know the language (heck I'm barely competent with HTML) and came up through GW-BASIC, Turbo Pascal, assembly, FORTRAN, C, Tcl, C++, Perl, and some others I'm sure I'm overlooking, but...
JavaScript
First, it's nominally C-like, so it gives them exposure that will help them with a large variety of other languages (e.g. C, Pascal, C++, Java).
Second, it's available to be used pretty much anywhere the kids have access to a computer. At home. At school. At a friends house where they can show off their newfound coolness. Don't underestimate this, because it's very important that they have access to the necessary programming tools in their idle time at home and elsewhere. It's also important because they don't need to learn how to use a compiler, linker, and all those other tool distractions that will get in the way of understanding programming itself.
Finally, it's useful in a context they likely already somewhat understand -- web pages. Fibonacci sequences and prime number sieves and such are all wonderful, but an environment that allows them to build something a bit more interactive and, lets face it, relevant to their day-to-day life, will inspire some portion of them to continue the pursuit. Granted, I got a lot of personal satisfaction out of writing BASIC programs to print "x" characters in a sine wave scrolling up the screen, but somehow I think the bar has been raised for today's kids' expectations of what a computer can do.
Heh. For the past 10 years I've named all my workstations at work after Star Control; I've named machines "kohrah", "kzerza" (fittingly those two were in service at the same time running x2x between them), "chenjesu", "earthling", and "pkunk". So far I haven't been masochistic enough to name one "mmrnmhrm". I'm pretty sure my next machine will be either "arilou" or "shofixti".
And can I be the only person who consistently misreads the title "The Drudge Report" as "The Druuge Report"?
In answer to your first question, yes. The canonical way is ":noh". However, that's a pain in the butt. I've mapped it to Ctrl-N by putting this in my.vimrc:
" Control-N clears any search highlighting
map <C-n>:nohlsearch<CR>
Slashdot Mirror
We still do. The only major difference (other than generational improvements) is that these days it's x86 instead of MIPS.
What happens when enough old people are gazillionaires that they basically set policy (answer: I doubt it will be to the benefit of the young)
You mean that old people don't basically set policy already (at least in the U.S.)? Up until recently any politician who even breathed a word implying that Social Security or Medicare benefits would be reduced, or even held constant, could count on getting kicked to the curb.
The Baby Boomers and their parents have saddled their children and grandchildren with a crushing debt while enjoying the benefits of shifting a bunch of spending from the future to the present. In my opinion it's time for them to start repaying the piper.
Perhaps I was lucky, but I did read the top three books I'd recommend as I was starting my first job:
1. Advanced Programming in the UNIX Environment, W. Richard Stevens. This was influential in teaching me what clean functional programming interfaces look like, and hopefully the code I've developed since then has lived up to that ideal.
2. Network Programming in the UNIX Environment, W. Richard Stevens. Much the same as the first title, but in some ways illustrating programming interfaces that tackle more complex/flexible situations.
3. Writing Solid Code. Steve Maguire. Fifteen years later I still daily use a few of the ideas presented in the title. However it also served to show me the ugliness of some programming conventions (e.g. Hungarian Notation and StudlyCaps()) and led me to avoid those practices in my own code when I have a choice (i.e. when not having to conform to the style of existing code).
Fwiffo? Is that you?
This one time, at imaginary band camp...
So now we're stuck waiting on the NSA to release Duke Nukem Forever?
BIOS does actually very little these days. The OS re-initializes most devices anyway on boot
Well, actually being a BIOS developer, I can state with absolute confidence that you're wrong about BIOS doing very little these days.
The BIOS these days takes care of an incredible amount of work, such as detecting, training, testing, and configuring RAM, initializing the CPU state on many cores, configuring the interconnect between processors (QPI on some recent Intel processors, HT on AMD), setting up system memory maps, probing and setting up the entire IO fabric, building tables (e.g. ACPI) that fully describe every nitty-gritty aspect of the system to the OS, make your USB keyboard and mouse functional for ancient OSes, work around problems in hardware, have small drivers for accessing myriad devices for reading blocks from boot devices, in the case of EFI/UEFI manage options for boot ordering as well as bazillions of basic system settings, actually implementing each and every one of those bazillion settings, handle all sorts of hardware abstractions in the form of BIOS/EFI calls, manage and configure IO BARs, provide code to handle all sorts of potential correctable (and sadly sometimes uncorrectable) hardware errors, in some cases provide disaster fallback paths if you manage to corrupt the main BIOS image, in the case of EFI provide a runtime environment for pre-OS applications, etc. -- and do all of this with absolutely nothing underneath it other than hardware. If you think this is "very little", I'd encourage you to find a job developing BIOS code, and I think you'd be overwhelmed by the sheer bulk of the codebase in a modern BIOS. Just the source code trees these days push a fair bit over the 100MB level. Seriously.
Having also worked on OSes and kernel-level device drivers, it is true that the OS re-initializes a fair bit of the hardware, but not nearly the level of hardware the BIOS initializes (have fun trying to re-train RAM or reconfigure the CPU interconnect, for example). If anything the trend has been toward the BIOS taking on greater and greater responsibility for device initialization and provision of runtime services to make the OS less aware of "quirks" in the hardware. That's not to say there isn't a ton of work the OS still has to do, but your statement vastly over-trivializes the role of the BIOS in modern machines.
Heresy! There's no way I'm parking my Hypercar, ever -- I won't even permit it to slow down. Next thing we know you'll be encouraging consumption of non-cheeseburger foods.
To the Slave Pits with you!
It is complete nonsense to try to tie the 35W bridge collapse to the current administration, and your rhetoric attempting to do so comes up short
Let's see -- there is known to have been a design deficiency in the original bridge that could lead to catastrophic failure if a single component fails, i.e. the "fracture critical" design.
The fracture critical component which failed which led to the collapse had been inspected on previous occasions, but the failure was not detected in those inspections. It is not that the inspection was not done, but that the failure in progress was not noticed by the engineering firm which performed the inspection. As best I've ever heard this firm was not a slipshod outfit, though obviously their inspection methodology missed this particular point.
Explain to me again how this is a failure of the Minnesota executive branch? Explain to me again how this is attributable to holding the line on tax issues?
For perhaps the first time in my life I've seen an elected official stick to what they promised when running for office. The governor did _exactly_ what he promised he would do when he originally ran, admittedly shifting certain expenses onto those who make direct use of certain state services. Not only this, but after doing so he was re-elected during a time when the gloss was off the Republican apple, in a traditionally very Democratic-party friendly state. So the voters re-confirmed that yes, they liked how he was handling taxation issues, and that he should stay the course.
So, pick your poison: an elected official who keeps their word (or at least the spirit of it), or one who promises one thing and then does another once elected. I may or may not agree with a politician, but if they keep their word at least I know with certainty what to expect of them.
And one final thought -- I recently looked into relative taxation and spending rates between the various states. The information I could readily find indicated that Minnesota was about 6th highest in taxation, and about 12th highest in spending, per capita for each stat. Draw what conclusions you will, but this indicates to me that the state has both a spending problem, and an even more significant taxation problem, relative to other states. I find it difficult to fault the current governor for opposing overall tax increases when I see relative rankings such as this.
Hey, I have a LeCroy 9450A that has some, umm, "issues" when powering up. It often takes several power cycles before it will successfully boot.
I can't figure out a way to contact you directly through /., but if you'd be interested in earning a few bucks repairing my scope, I'd like to talk to you.
And then die off within a generation.
Because last time I checked "byte" isn't a friggin' SI unit of measurement. Meters, Litres, Grams, Kelvin, Joules, Watts, Pascals, yes. Bytes, eggs, toes, dollars, no.
I'm all in favor of the SI system, and wish we here in the U.S. would cut over. But keep your SI prefix hands off of my non-SI units.
It's simple really -- the same way you build up relationships with people outside the office -- around food and drink.
Things that have worked very successfully at my workplace (not all in place at the same time over the years):
- Friday Beer Bash. 3PM on Fridays (or most Fridays) have a self-sponsored beer bash. A few volunteers buy beer, some non-alcoholic beverages, and some chips/cookies etc. Everyone is invited to come, sit, and visit. Everyone is expected to chip in a couple bucks toward the food.
- Donuts. A set of people gets together at the same time in the morning once a week (Friday at 8AM when we did it) for donuts in the conference room. This isn't a "come grab a donut and go back to your office/cube" thing, but sit around the conference room and talk about anything and everything (work related or not). The participants are on a rotation to bring donuts, milk, and juice, paying out of their own pocket whenever their rotation comes around.
- Grilling. Pitch in together to buy a grill (or get one donated by someone, or the company). During months where the weather is nice enough, grill lunch outside, everyone bringing their own items to grill that day. Probably do this once a week. Organize payment for propane/charcoal however makes sense (chip in a buck once a week/etc).
- Cooking contests. An annual brownie contest, chili and cornbread contest, etc. A panel of employee judges gets to judge the contest, or everyone in attendance votes for their favorites. Have some sort of small prizes for the top three (e.g. small gift cards), funded however makes sense (company, entrance fee, proceeds from employees chipping in at the door to cover extras like beverages).
- Often the "self-sponsored" events above (beer bash, grilling, donuts if you choose to do it that way) end up generating more cash than actual costs. Whenever the amount builds up to a sufficient level, have a "free" pizza/whatever lunch paid out of the proceeds.
- Not quite a food thing, more of a beer thing, but start up a bowling league, company softball team, or something like that that gets people from different departments to join up around a common interest.
There's at least one notable substance that shares this property: Water. That's why it forms ice on the top surface rather than along the bottom/sides of the container (be that container a bucket, a river, or a lake). This very fact is instrumental to life on our little globe.
You answered your own question -- it's a "relatively simple tool". The tool has relatively little value-add or innovation compared to their other work. They'd rather spend their employees' time on developing software more core to their business.
The fact that this particular utility isn't particularly core to their business or seen as critically valueable or innovative is evidenced by the quick turnaround in releasing the source code. It's so far from their core business that it's just not worth their developers' and lawyers' time to rewrite/relicense/etc. the code to avoid the GPL entanglement, so the least expensive route to their objectives was to release the code.
If only I could mod the parent +1 Insightful and post... but I'll choose posting.
Most of the commenters do not realize that Joel is, at the heart of things, railing against over-complicated design more than praising lazy programming practices. Unfortunately that's not how he titled the article, and the reaction is thus predictable. I sincerely doubt he'd advocate sloppiness of code or design.
Unfortunately there are very non-junior designers who never make transition #3 (or maybe they regressed). As a result of their seniority and presumed competence, they are placed in a position to over-engineer solutions, miss market opportunities, and starve less elegant but competing solutions of the manpower and attention which bring the 50% solution up to a 95% solution. And unfortunately when their supervisor is too busy with other business concerns and a bit out of date with their technical knowledge, the necessary checks on over-engineering don't get applied. Couple that with politics/turf/etc typical of many businesses, and the non-over-engineered solution loses out. The entire organization suffers as a result, missing deadlines, solutions that aren't, and eventually it impacts the bottom line.
Personally I haven't made transition #4, however I'm starting to glimpse what it means. I'm not yet convinced that I care enough to make that transition, but I think that's a normal part of the process of growing.
Forget a mouse, forget wireless unless you're using a laptop.
The best dang "mouse" I've ever found is a Microsoft Trackball Explorer. Five buttons plus scrollwheel. I've used xmodmap to remap the buttons to help alleviate some nascent carpal tunnel symptoms. I own two of them, using one at work, and one at home. It does tend to get a bit gummed up on the trackball bearings, but about once a week I just swab around them with whatever pointy object is handy (paper clip, pen, thumbtack), and all is well. It'd probably help if I didn't eat junk food while working on the computer, and thus get all that goo on the trackball itself.
Unfortunately they stopped making it a few years ago. And when I say "unfortunately", know full well that I refuse to give Microsoft a dime for anything other than Trackball Explorers and keyboards, so you know the Trackball Explorer has to be awesome to overcome my loathing of Redmond.
I pretty much agree with the parent.
When I was fairly new to my company code reviews were reasonably helpful, as I was certainly not an expert in the areas I was fixing bugs, and there was a lot of undocumented knowledge of how various components interacted with eachother. As time went on and I became more proficient in these areas, code reviews began to be less useful.
I then moved on to taking primary responsibility for an important system library whose original developer left years earlier, and the current maintainer had been layed off. A year into that effort I was effectively the only person in the company who understood how the library worked, and as such was the sole expert on it. Code reviews for checkins were still mandatory, but about the only thing any other reviewer would ever find were minor stylistic issues -- the real bugs went undetected because the expertise required to detect them just wasn't reasonable to expect of anyone else.
Today I find myself working on deep close-to-the-metal code. Due to economic conditions it's just not feasible to have any overlap between engineers in the areas they're deeply familiar with (yes, that's a management issue -- city bus syndrome is a very real risk). For all but the smallest changes, others cannot fully understand the implications of my changes when they review my code, and I cannot understand the implications of the changes when I review their code. We still keep at it, but the effort rarely catches real problems.
Alongside those issues, I have been with this company for more than ten years, yet in my particular group I'm the youngest person with the least experience. With such a mature and historied team, significant mistakes are exceedingly rare, and even minor mistakes are uncommon. The most common thing we catch is someone forgetting to update the current copyright date in a file's comment block.
For the stated reasons, I currently view code reviews as generally just an extra hoop to jump through in the checkin process. If I should ever change jobs, I'm sure I'd once again appreciate having more experienced developers double-checking my efforts.
I know that some of the water comes up from the ground on Progress vehicles, so you are correct on that front. However I've watched the NASA TV channel quite a bit over the past year, and during the recent missions where the urine processing system was installed and fixed, it was definitely stated that water generated from the Shuttle engines is transferred to the ISS. The other poster is correct as well, in that NASA TV stated that the end of shuttle flights was part of the motivation behind installing the water recycling system.
I don't believe water transfer is done via a umbilical, instead bags of water are filled on the Shuttle and transferred oto the ISS. However, I could well be wrong regarding this point.
> Everyone drinks recycled urine and sweat every day.
While a good point, this may not be quite as true in the case of the astronauts aboard ISS.
A large portion of the water delivered to ISS comes from the Space Shuttle as it combusts liquid hydrogen to power itself while docked. Depending on the source of the liquid hydrogen and oxygen fuel (i.e. Is it generated from electrolysis of water? Condensed directly from the atmosphere? etc), it's possible a significant portion of their water supply has never been urine or sweat before.
And even if the liquid hydrogen and oxygen was water previously, do water molecules generated from hydrogen combustion really count as "recycled"?
-- CdM
I hate to say this since I don't even know the language (heck I'm barely competent with HTML) and came up through GW-BASIC, Turbo Pascal, assembly, FORTRAN, C, Tcl, C++, Perl, and some others I'm sure I'm overlooking, but...
JavaScript
First, it's nominally C-like, so it gives them exposure that will help them with a large variety of other languages (e.g. C, Pascal, C++, Java).
Second, it's available to be used pretty much anywhere the kids have access to a computer. At home. At school. At a friends house where they can show off their newfound coolness. Don't underestimate this, because it's very important that they have access to the necessary programming tools in their idle time at home and elsewhere. It's also important because they don't need to learn how to use a compiler, linker, and all those other tool distractions that will get in the way of understanding programming itself.
Finally, it's useful in a context they likely already somewhat understand -- web pages. Fibonacci sequences and prime number sieves and such are all wonderful, but an environment that allows them to build something a bit more interactive and, lets face it, relevant to their day-to-day life, will inspire some portion of them to continue the pursuit. Granted, I got a lot of personal satisfaction out of writing BASIC programs to print "x" characters in a sine wave scrolling up the screen, but somehow I think the bar has been raised for today's kids' expectations of what a computer can do.
Heh. For the past 10 years I've named all my workstations at work after Star Control; I've named machines "kohrah", "kzerza" (fittingly those two were in service at the same time running x2x between them), "chenjesu", "earthling", and "pkunk". So far I haven't been masochistic enough to name one "mmrnmhrm". I'm pretty sure my next machine will be either "arilou" or "shofixti".
And can I be the only person who consistently misreads the title "The Drudge Report" as "The Druuge Report"?
OK, now do ":split someother.file" that has different r/w attributes.
I win. ;)
In answer to your first question, yes. The canonical way is ":noh". However, that's a pain in the butt. I've mapped it to Ctrl-N by putting this in my .vimrc:
:nohlsearch<CR>
" Control-N clears any search highlighting
map <C-n>
Hmm. Apparently /. stripped out some of the code due to it looking like HTML. In the whitespace highlighting recipe, the last line should be:
autocmd Syntax * call WhitespaceHighlight(expand("<amatch>"))