Yes, it's a sign that the people doing the study aren't especially bright when they immediately leap to the conclusion that coffee equals caffeine. There are hundreds of alkaloids in coffee, many of which aren't understood in the slightest.
When I cut back on coffee because of a sleep issue, I tappered off then switched to decaf until my consumption habit was cured. Decaf works great as negative stimulus. However I noticed that decaf still gave me many of the coffee effects I was used to, it even seemed to change my thinking slightly. Coffee tends to flatten my thought process like a JPEG compression that overkills the colours. Without coffee my brain is a G450. The image looks good, but the frame rate is modest. With coffee my brain is an Nvideo card with a great frame rate pumped through one of those crappy RIVA ramdacs that bleach out all the contrasts. I was very surprised to get the RIVA effect drinking decaf.
Coffee has widespread systemic impact. The first cup you drink in the morning causes your vaso tension to increase for the whole day. There are so many ways coffee could be affecting this disease it isn't even a good clue if the results prove correct.
IIRC they often find aluminum buildup in the brain plaque associated with this disease, but to my knowledge they don't even know that the plaque is responsibible for the symptoms (I think I saw some recent results on Science Daily which suggests another mechanism is causal) and they certainly haven't linked the plaque buildup with possible sources of aluminum in the diet. Last time I checked this was nothing more than an urban myth.
I would say it is prudent not to cook highly acidic food in aluminum pots, but I seriously doubt that the amount of aluminum ingested from your aluminum rice cooker is a factor in this disease.
I seriously hope they drive television straight into the gutter, to the point where any sane person knows better than to turn it on in the first place. Talk TV all day long with crawlers for cheap diamond rings on top, popups for ab crunchers below, and more bleeps on the sound track than words you can hear.
Commercial advertising was a Faustian bargain to begin with, and now the devil is collecting interest as well.
no such thing as perfect, diversity rules
on
Painless Chairs?
·
· Score: 3, Interesting
Like the last guy, I'm extra tall. 6'5" but with most of my height in my back. I drive my MGA looking over top of the windscreen. When I tried the Herman Miller it wasn't a good fit for. The large model belongs in the kind of Big & Tall shop, where you find one pair of jeans in every style with a 36" inseam, but every waste size all the way up to 60" for every pair of slacks in the store. I felt like a toothpick sitting in the size C chair and I'm 230lbs right now. Also I didn't like the metal hoop behind my shouldblades since it prevented me from stretching my arms behind my neck.
Instead I bought myself an expensive Leap chair from Steelcase. Every adjustment under the sun, and pretty well made. Only it doesn't work for me. There is a pivot in the back rest to cause the lumbar support to track your posture. For me the pivot is too low in the back. I have to completely disable the recline feature because the pivot is increasing stress rather than support. Another small complaint is the the seat padding isn't thick enough for someone with my body mass without extra padding of my own. I can sometimes feel the screw heads inside the plastic seat tray.
I have a nonbranded chair here at half the price I use more often. It functions on a completely different concept. This has a clamshell pivot under the seat pan, which means the pivot for the seat tray is just behind your knees. Instead of having the usual lumbar curve, it has a cylindrical shape that folds behind my ribs and gives me extra rib support. There is a bit of extra padding behind the lumbar, but not as pronounced as many chairs. It also has the ability to reach a positive seat inclination (where you are tipped forward toward your work area). This chair is comfortable when I'm power hacking in the foward position, and comfortable when I'm in deep though and deep recline.
The secret, however, is not to use just one chair. I find it helps a lot to switch between the two chairs on alternate days, or sometimes during the day. This way I don't get all the stress on one place all the time.
I think variety is the key here. I don't think I'm ever going to find that one perfect chair which I can sit in all day long and not have back pain.
Another comment I want to make is be very careful about mouse and keyboard placement. I once went to a back clinic that made me wear a giant X on my back made from two strips of masking tape. It's a useful exercise because the tape reminds you when your posture is off kilter. It tears out your back hairs! I discovered that my back problem (on that iteration) was entirely caused by my mouse usage. My keyboard posture was exceptional, but I twisted my torso slightly to the right to use the mouse and I was doing a mouse intensive project at the time.
Since then I created a platform over my numeric keypad where my mouse sits (on a giant FuncSurface mouse pad) and I've never had mouse related back pain since. During that episode I spent more time with my back on the floor and my legs in my chair than the other way around. That tiny twist was really bad for me.
The top of your monitor should be at eye level or just below. Don't put it up so high you are looking straight at the center.
My last remaining ergonomic problem with my desk is that I'm running two systems so I have another keyboard on the desk above the main keyboard tray, and another mouse at this level as well. It's harder on my hands to type on the top keyboard, and harder on my back to use the top mouse. Soon I'm going to get a KVM so I can exclusively use the better arrangement. Actually, it is probably not bad for my back to use the high keyboard occasionally. I think variety is a good thing. But the high mouse has no redeeming qualities. Sometimes I drag it down to the main mouse surface, but I really don't like having both mice in the same place. It's hard enough already to grab the right input device.
A final comment here: it isn't always your chair/desk either. You can be causing your problems with a bad bed, and then suffering during the day because you are already inflamed.
I recently purchased a Latex rubber mattress and this has improved my pain at night immensely. A good latex mattress will only compress a few percent over twenty years. Spring mattresses have never worked for me. I get a futon just right, two weeks later it gets a dent and I have to start over.
Some people claim that armrests cause more problems than they solve because people get lazy about their posture when they have armrests. Sometimes what kills you is half an inch. I have to be very careful because I've never owned a chair yet where the armrests come all the way up to my arms, including chairs that claim to be designed for the very tall.
I had an Osborne myself, with a C compiler that came from Software Toolworks in a ziplock baggie. Did a tremendous amount of hacking on that machine.
At the time, IIRC Osborne made their first $100 million faster than any company before them. And they were dead six months after the misguided product preannouncement.
My next machine was the original fat Mac. I never did find a good C compiler. The Aztec compiler I had only sorta worked. I spent more time on that machine swapping floppies that getting anything useful accomplished. Least useful machine I ever bought, and also the most expensive. The one serious project I completed was a for a psychology experiment in reading comprehension. One of the requirements of this project was not having any text on the screen except the text presented by the experiment. It turned out that you didn't enable the Apple menu bar, the machine was completely unstable. I must have spent several weeks in total trying to find a way to make the machine stable with the menu bar suppressed while the machine constantly spat out the floppy disk it was going to need next. I really really really grew to hate that machine. Meanwhile Apple was constantly promising a proper pre-emptive virtual memory subsystem which didn't ultimately arrive until OS X.
Why do people fawn over a company that behaves this way? I've never been able to understand it. Must be the same people who thrive on beauty and broken promises in their relationships.
Palladium is just ActiveX revisited. Security is confusing because it covers two entirely different problems: 1) protecting the machine from rogue users, 2) protecting the machine from rogue software.
The second point bifurcates into two opposing camps: 1) most rogue software comes from unemployed college dropouts, 2) most rogue software comes from Fortune 500 companies.
Palladium is the approach of keeping the foxes away from the chickens by building a coop for the foxes.
I tried mnogosearch and swish-e. Different plusses and minuses. Later on I discovered that mnogosearch has a PHP front end and can be installed from a Debian package.
My advice is to set up two entirely different search databases. Otherwise it's very difficult to compare hits, ranking performance, or discovered differences in the lexeme policy.
Every choice in handling this matter carries a different consequence for different groups of people. Theo can't serve every group equally.
As it turns out, recent OpenBSD installations were exposed to this, where many other platforms were not exposed.
The first question Theo had to decide was whether to spread the information around before his own user community was protected. Of course every vendor thinks they are entitled to this information. No black hats here! No rooted systems here! Your secrets are safe with us. Tell enough vendors, your secret is certain to escape.
The next question to decide is whether to create a window of opportunity for his own user base to protect themselves before giving away anything of use to the black hat community.
He can't do this without admitting that there is a big problem here. But any further details he gives become clues for those who might try to discover the flaw themselves.
As it stood, he had an option to put forward which allowed his user base to protect themselves while giving nothing away to his black hat adversaries. privsep is a case of Doing The Right Thing. I'm sure Theo does get frustrated that vendors don't put a higher priority on Do The Right Thing initiatives.
On OpenBSD itself, privsep has been there quite a while and I don't think it would be considered untested in its nascient environment.
He couldn't very well suggest to his user base "disable challenge/response". That's like backing away from Mike Tyson.
What could he have done differently?
He could have informed his own user base to install the reasonably well tested privsep version *in advance* of informing other vendors of the actual problem in secrecy *after* he completed the actual bug fix patch. This would have meant keeping the patch secret for another week or two.
But instead he chose to put his boot up the ass of vendors who think that compatibility with PAM is more important than adopting a model which eliminates 90% of the future prospect for more of the same.
If Theo were entirely sane he wouldn't be doing what he's doing. Maybe he has your best interests at heart, but the same best interests you chose for yourself.
There are always people who have good reasons for delaying The Right Thing. In the long term, I think these people contribute more to the sorry state of security that brash actions by people like Theo.
If you invest your faith in Doing The Right Thing on the technical merits, I think you'll stick with OpenSSH. If you prefer the relationship model of working hand in hand behind the scenes, maybe you won't.
I looked again more closely. With the new ssh when you make a connection, two new sshd processes are created: one running as root, the other running under your userid. And there is also the master instance running as root which spawns new connections.
If you're a black-hat poking around in Apache or Cisco routers or whatever looking for rootable holes, wouldn't you instantly drop what you're doing and start looking for this hole?
Oh for sure. I figure this bug has been in OpenSSH nearly as long as OpenSSH has existed. It hasn't come to light in two years despite widespread adoption and repeated security reviews by smart people who really care about this stuff, but you'll find it in five days starting with the ultimate non clue because you are a l33t black hat, and you can hone in on bugs in 10,000 lines of complex code without hardly trying.
You aren't being forced to upgrade because the vulnerability *hasn't* be released into the wild. You are being given an option to upgrade before necessity becomes a mother.
I can you all you people with this viewpoint one thing for certain: if I end up in a game of prisoner's dilemma with any of you, I'll rat you out as fast as I can.
There are four quadrants in this game. Do the math. You'll discover how stupid it is to play this card.
Black hats probably already know the exploit. Theo is keeping the information away from the white hats and the users. This is irresponsible.
You have no reason whatsoever, based on the information available, to surmise this state of affairs. If this bug has been in OpenSSH for two years there can't be that many people who know about it.
If there are a few uber hats who managed to figure this out years ago, keep it to themselves while exploiting thousands of systems and never being traced, get over it. You've been rooted already. A five day delay in full disclosure isn't going to make one whit of difference.
I upgrade OpenSSH remotely all the time. No problem. It's perfectly designed to allow this.
There is a controlling instance of sshd which accepts new connections. Each new connection spawns a new sshd process to handle that connection.
To do the upgrade you only need to replace the controlling sshd process. Once you do this, your *new* connections will run the new code, but your existing session is not affected.
Just be careful not to log out of your upgrade session until you are sure that the new sshd is accepting inbound.
I think announcement made a good call on risk/reward. The fix they suggest doesn't give away anything at all to the black hats, yet it makes it possible for many of us, with a little bit of trouble, to eliminate this vulnerability immediately.
Thanks for mentioning the new location of the ssh conf files. I upgraded two OpenBSD systems this morning. An old box running 2.7 and a recently upgraded system running 3.1 On the 3.1 box I had the new sshd_config in the wrong place.
Listing the [priv] tag does work. The new ssh sessions show [priv}, but ssh sessions started before I did the upgrade still have the old process record.
One thing they should point out in the upgrade instructions is that you have to kill all existing sshd processes to be certain that the defect is no longer running.
When my host, pair.com, upgraded their sshd after the last vulnerability, they left some old ssh sessions running since before the patch. I had a two week old ssh session which they killed. But others had a one week old session that was left running.
Come on people. Not long ago I read a retrospective on the dotcom era where they stated outright that eyeballs were one of the worst business metrics ever invented.
I think Mozilla has a significance that goes far beyond the total number of eyeballs it captures.
One point I can think of off the top of my head is the arms race between the desires of the user population and the cupcake engineers. IE takes a very lax stance in this department. Mozilla has the potential to restore the voice of the user to the user experience.
While Mozilla was stuck in the shipping bay door like a sideways piano, it wasn't the right time for the outside community to put forward these enhancements. I
MS can't afford to let Mozilla gain a clear upper hand in cupcake sobriety.
Too bad the justice dept. hasn't imposed upon MS the requirement to put in the right button menu the option to "open link/page in other browser".
I'd use this on every shitty page that displays in microfonts, every shitty page that opens a pop-under, every shitty page with more shimmering JPEGS than text. If I had that feature in IE I'd almost wear it out.
Even better, a way to mark my preference for each web site as to which browser opens each window (regardless of the browser used to click on the original link).
But don't listen to me. I'm one of those weird people who bought a bread knife when I already had many other knives in my kitchen.
One of the major safty factors in having a larger car is having a larger car than the car you collide with. By this logic, you can't make a car large enough. By the same logic, everyone in America should carry a handgun and violent crime would be completely eliminated. I think the kind of safty you are talking about is giving more than you get.
Re:The series finale was pretty good.
on
The Truth Revealed
·
· Score: 1
Naw, you reload the black tubes of missile spewing death by farting into little pneumatic suction cups that connect to the tubes through the tube spars.
The golden rule here: clock frequency scales all code, architecture scales new code.
There is so much incredibly interesting work out there that no one can cost justify when you get exactly the same performance results by sitting on your thumbs for 18 months.
I'm entirely in favour, though lacking in hope, that Moore's law soon ceases to be the single dominant term in computational progress.
I ran a G450 side by side against a Radeon 8500 DDR playing Quake III. The G450 was in a dual P3/750 system with 384MB, the Radeon 8500 DDR was in an Athlon/900 system with 768MB.
You'd think the Radeon would seriously win that competition. It didn't.
First of all, the G450 with 16 bit colour produced an image quality just as good as the Radeon in 32 bit colour. Maybe a bit better.
On the G450 you had to tune the texture detail down a couple of notches, whereas the Radeon could run at full texture detail. Playing these two cards I barely noticed the difference in texture detail.
The Radeon with 32 bit colour and full textures was still faster than the G450 most of the time. Unless the scene became complicated. Then the Radeon would fall to half the regular frame rate, whereas the Matrox would continue to pump along at 45fps all the time.
A lot of people who looked at the terrible benchmarks of the G450 in 32 bit colour with full textures enabled don't realize how playable this card really was. I actually like the G450 slightly better than the Radeon because the colours were somewhat more intense and the frame rate was more consistent. It terms of my game play success, it was a complete toss up.
I always thought it pretty unfair that the G450 was so heavily critized for not doing 180fps on some silly game loop as if that were a sensible thing for Matrox to accomplish.
The same is true with cars. Some cars with less raw horsepower perform a lot better on the road than you would think looking at the spec. sheet.
Adding in the superior image quality of the G450 the other 90% of the time (when I wasn't playing games) it was a no brainer.
I would say that Matrox was competing well enough at what they set out to accomplish if you bothered to look. Unfortunately, you get no respect in this market unless you run up the numbers on your spec. sheet.
No, unfortunately the STL could not have been designed that way, because the standardization commitee exempted diagnostics from their mandate from the outset. This was before templates were a vital feature of modern C++ and a bad call in retrospect IMHO. However, they had so much trouble finishing off what they did have on their plate that adding another dimension might have sunk the entire enterprise.
The "middle of the road" that the STL strives to achieve is suitability to professional 3rd party library vendors, somewhat randomized by time pressures.
The feeling was that the majority of programmers should be programming on top of application specific libraries not the raw STL itself (although that is intended to be viable where it makes sense to do so).
People come to strange ideas about what C++ was trying to achieve by looking at it from the point of view of "one stop shopping". Rather than providing convenient solutions for every need at the bottom layer, they focussed on making it possible to provide good solutions in the intermediate layers.
None of the STL books recommend thinking about the different containers as interchangable.
Every pair of containers has significantly different semantics. The only pair where this might make sense is vector/deque if front insertion is not required. deque has the advantage of never copying your objects from one place to another behind the scenes. If object copies are expensive, deque is often faster than vector. deque is the default storage for the stack adaptor.
It's still a good practice for application classes to supply their own iterator typedefs.
Slashdot Mirror
Yes, it's a sign that the people doing the study aren't especially bright when they immediately leap to the conclusion that coffee equals caffeine. There are hundreds of alkaloids in coffee, many of which aren't understood in the slightest.
When I cut back on coffee because of a sleep issue, I tappered off then switched to decaf until my consumption habit was cured. Decaf works great as negative stimulus. However I noticed that decaf still gave me many of the coffee effects I was used to, it even seemed to change my thinking slightly. Coffee tends to flatten my thought process like a JPEG compression that overkills the colours. Without coffee my brain is a G450. The image looks good, but the frame rate is modest. With coffee my brain is an Nvideo card with a great frame rate pumped through one of those crappy RIVA ramdacs that bleach out all the contrasts. I was very surprised to get the RIVA effect drinking decaf.
Coffee has widespread systemic impact. The first cup you drink in the morning causes your vaso tension to increase for the whole day. There are so many ways coffee could be affecting this disease it isn't even a good clue if the results prove correct.
IIRC they often find aluminum buildup in the brain plaque associated with this disease, but to my knowledge they don't even know that the plaque is responsibible for the symptoms (I think I saw some recent results on Science Daily which suggests another mechanism is causal) and they certainly haven't linked the plaque buildup with possible sources of aluminum in the diet. Last time I checked this was nothing more than an urban myth.
I would say it is prudent not to cook highly acidic food in aluminum pots, but I seriously doubt that the amount of aluminum ingested from your aluminum rice cooker is a factor in this disease.
I seriously hope they drive television straight into the gutter, to the point where any sane person knows better than to turn it on in the first place. Talk TV all day long with crawlers for cheap diamond rings on top, popups for ab crunchers below, and more bleeps on the sound track than words you can hear.
Commercial advertising was a Faustian bargain to begin with, and now the devil is collecting interest as well.
Like the last guy, I'm extra tall. 6'5" but with most of my height in my back. I drive my MGA looking over top of the windscreen. When I tried the Herman Miller it wasn't a good fit for. The large model belongs in the kind of Big & Tall shop, where you find one pair of jeans in every style with a 36" inseam, but every waste size all the way up to 60" for every pair of slacks in the store. I felt like a toothpick sitting in the size C chair and I'm 230lbs right now. Also I didn't like the metal hoop behind my shouldblades since it prevented me from stretching my arms behind my neck.
Instead I bought myself an expensive Leap chair from Steelcase. Every adjustment under the sun, and pretty well made. Only it doesn't work for me. There is a pivot in the back rest to cause the lumbar support to track your posture. For me the pivot is too low in the back. I have to completely disable the recline feature because the pivot is increasing stress rather than support. Another small complaint is the the seat padding isn't thick enough for someone with my body mass without extra padding of my own. I can sometimes feel the screw heads inside the plastic seat tray.
I have a nonbranded chair here at half the price I use more often. It functions on a completely different concept. This has a clamshell pivot under the seat pan, which means the pivot for the seat tray is just behind your knees. Instead of having the usual lumbar curve, it has a cylindrical shape that folds behind my ribs and gives me extra rib support. There is a bit of extra padding behind the lumbar, but not as pronounced as many chairs. It also has the ability to reach a positive seat inclination (where you are tipped forward toward your work area). This chair is comfortable when I'm power hacking in the foward position, and comfortable when I'm in deep though and deep recline.
The secret, however, is not to use just one chair. I find it helps a lot to switch between the two chairs on alternate days, or sometimes during the day. This way I don't get all the stress on one place all the time.
I think variety is the key here. I don't think I'm ever going to find that one perfect chair which I can sit in all day long and not have back pain.
Another comment I want to make is be very careful about mouse and keyboard placement. I once went to a back clinic that made me wear a giant X on my back made from two strips of masking tape. It's a useful exercise because the tape reminds you when your posture is off kilter. It tears out your back hairs! I discovered that my back problem (on that iteration) was entirely caused by my mouse usage. My keyboard posture was exceptional, but I twisted my torso slightly to the right to use the mouse and I was doing a mouse intensive project at the time.
Since then I created a platform over my numeric keypad where my mouse sits (on a giant FuncSurface mouse pad) and I've never had mouse related back pain since. During that episode I spent more time with my back on the floor and my legs in my chair than the other way around. That tiny twist was really bad for me.
The top of your monitor should be at eye level or just below. Don't put it up so high you are looking straight at the center.
My last remaining ergonomic problem with my desk is that I'm running two systems so I have another keyboard on the desk above the main keyboard tray, and another mouse at this level as well. It's harder on my hands to type on the top keyboard, and harder on my back to use the top mouse. Soon I'm going to get a KVM so I can exclusively use the better arrangement. Actually, it is probably not bad for my back to use the high keyboard occasionally. I think variety is a good thing. But the high mouse has no redeeming qualities. Sometimes I drag it down to the main mouse surface, but I really don't like having both mice in the same place. It's hard enough already to grab the right input device.
A final comment here: it isn't always your chair/desk either. You can be causing your problems with a bad bed, and then suffering during the day because you are already inflamed.
I recently purchased a Latex rubber mattress and this has improved my pain at night immensely. A good latex mattress will only compress a few percent over twenty years. Spring mattresses have never worked for me. I get a futon just right, two weeks later it gets a dent and I have to start over.
Some people claim that armrests cause more problems than they solve because people get lazy about their posture when they have armrests. Sometimes what kills you is half an inch. I have to be very careful because I've never owned a chair yet where the armrests come all the way up to my arms, including chairs that claim to be designed for the very tall.
I had an Osborne myself, with a C compiler that came from Software Toolworks in a ziplock baggie. Did a tremendous amount of hacking on that machine.
At the time, IIRC Osborne made their first $100 million faster than any company before them. And they were dead six months after the misguided product preannouncement.
My next machine was the original fat Mac. I never did find a good C compiler. The Aztec compiler I had only sorta worked. I spent more time on that machine swapping floppies that getting anything useful accomplished. Least useful machine I ever bought, and also the most expensive. The one serious project I completed was a for a psychology experiment in reading comprehension. One of the requirements of this project was not having any text on the screen except the text presented by the experiment. It turned out that you didn't enable the Apple menu bar, the machine was completely unstable. I must have spent several weeks in total trying to find a way to make the machine stable with the menu bar suppressed while the machine constantly spat out the floppy disk it was going to need next. I really really really grew to hate that machine. Meanwhile Apple was constantly promising a proper pre-emptive virtual memory subsystem which didn't ultimately arrive until OS X.
Why do people fawn over a company that behaves this way? I've never been able to understand it. Must be the same people who thrive on beauty and broken promises in their relationships.
Palladium is just ActiveX revisited. Security is confusing because it covers two entirely different problems: 1) protecting the machine from rogue users, 2) protecting the machine from rogue software.
The second point bifurcates into two opposing camps: 1) most rogue software comes from unemployed college dropouts, 2) most rogue software comes from Fortune 500 companies.
Palladium is the approach of keeping the foxes away from the chickens by building a coop for the foxes.
I tried mnogosearch and swish-e. Different plusses and minuses. Later on I discovered that mnogosearch has a PHP front end and can be installed from a Debian package.
My advice is to set up two entirely different search databases. Otherwise it's very difficult to compare hits, ranking performance, or discovered differences in the lexeme policy.
Every choice in handling this matter carries a different consequence for different groups of people. Theo can't serve every group equally.
As it turns out, recent OpenBSD installations were exposed to this, where many other platforms were not exposed.
The first question Theo had to decide was whether to spread the information around before his own user community was protected. Of course every vendor thinks they are entitled to this information. No black hats here! No rooted systems here! Your secrets are safe with us. Tell enough vendors, your secret is certain to escape.
The next question to decide is whether to create a window of opportunity for his own user base to protect themselves before giving away anything of use to the black hat community.
He can't do this without admitting that there is a big problem here. But any further details he gives become clues for those who might try to discover the flaw themselves.
As it stood, he had an option to put forward which allowed his user base to protect themselves while giving nothing away to his black hat adversaries. privsep is a case of Doing The Right Thing. I'm sure Theo does get frustrated that vendors don't put a higher priority on Do The Right Thing initiatives.
On OpenBSD itself, privsep has been there quite a while and I don't think it would be considered untested in its nascient environment.
He couldn't very well suggest to his user base "disable challenge/response". That's like backing away from Mike Tyson.
What could he have done differently?
He could have informed his own user base to install the reasonably well tested privsep version *in advance* of informing other vendors of the actual problem in secrecy *after* he completed the actual bug fix patch. This would have meant keeping the patch secret for another week or two.
But instead he chose to put his boot up the ass of vendors who think that compatibility with PAM is more important than adopting a model which eliminates 90% of the future prospect for more of the same.
If Theo were entirely sane he wouldn't be doing what he's doing. Maybe he has your best interests at heart, but the same best interests you chose for yourself.
There are always people who have good reasons for delaying The Right Thing. In the long term, I think these people contribute more to the sorry state of security that brash actions by people like Theo.
If you invest your faith in Doing The Right Thing on the technical merits, I think you'll stick with OpenSSH. If you prefer the relationship model of working hand in hand behind the scenes, maybe you won't.
Safe ground there guy, staking out the non falsifiable position when the other side of the coin IS falsifiable (by example).
I'll believe someone had the exploit ahead of the fix when someone declares a compromised system.
Until then, all we have to go on is paranoia, and find that a thin gruel.
Hear, hear!
I looked again more closely. With the new ssh when you make a connection, two new sshd processes are created: one running as root, the other running under your userid. And there is also the master instance running as root which spawns new connections.
I read, I read. Here are my results on 4.2-STABLE after all that reading:
/var/log/messages
sshd: no modules loaded for `sshd' service
sshd: fatal: PAM session setup failed[6]: Permission denied
This happens on every connection, even connections to localhost.
I positively did everything I sshd. What next?
I just installed ssh 3.3p1-0.0woody1
There is no
There is no ssh group in
There is no documentation of priv sep in man sshd
There is no UsePrivSep options in the
The ps auwx | grep ssh does not show [priv] in new sshd process instances. My OpenBSD instance does show this.
I _suspect_ that the woody ssh 3.3 was compiled with priv sep disabled, which means it doesn't fix this problem.
You aren't being forced to upgrade because the vulnerability *hasn't* be released into the wild. You are being given an option to upgrade before necessity becomes a mother.
I can you all you people with this viewpoint one thing for certain: if I end up in a game of prisoner's dilemma with any of you, I'll rat you out as fast as I can.
There are four quadrants in this game. Do the math. You'll discover how stupid it is to play this card.
I upgrade OpenSSH remotely all the time. No problem. It's perfectly designed to allow this.
There is a controlling instance of sshd which accepts new connections. Each new connection spawns a new sshd process to handle that connection.
To do the upgrade you only need to replace the controlling sshd process. Once you do this, your *new* connections will run the new code, but your existing session is not affected.
Just be careful not to log out of your upgrade session until you are sure that the new sshd is accepting inbound.
I think announcement made a good call on risk/reward. The fix they suggest doesn't give away anything at all to the black hats, yet it makes it possible for many of us, with a little bit of trouble, to eliminate this vulnerability immediately.
Thanks for mentioning the new location of the ssh conf files. I upgraded two OpenBSD systems this morning. An old box running 2.7 and a recently upgraded system running 3.1 On the 3.1 box I had the new sshd_config in the wrong place.
Listing the [priv] tag does work. The new ssh sessions show [priv}, but ssh sessions started before I did the upgrade still have the old process record.
One thing they should point out in the upgrade instructions is that you have to kill all existing sshd processes to be certain that the defect is no longer running.
When my host, pair.com, upgraded their sshd after the last vulnerability, they left some old ssh sessions running since before the patch. I had a two week old ssh session which they killed. But others had a one week old session that was left running.
Come on people. Not long ago I read a retrospective on the dotcom era where they stated outright that eyeballs were one of the worst business metrics ever invented.
I think Mozilla has a significance that goes far beyond the total number of eyeballs it captures.
One point I can think of off the top of my head is the arms race between the desires of the user population and the cupcake engineers. IE takes a very lax stance in this department. Mozilla has the potential to restore the voice of the user to the user experience.
While Mozilla was stuck in the shipping bay door like a sideways piano, it wasn't the right time for the outside community to put forward these enhancements. I
MS can't afford to let Mozilla gain a clear upper hand in cupcake sobriety.
Too bad the justice dept. hasn't imposed upon MS the requirement to put in the right button menu the option to "open link/page in other browser".
I'd use this on every shitty page that displays in microfonts, every shitty page that opens a pop-under, every shitty page with more shimmering JPEGS than text. If I had that feature in IE I'd almost wear it out.
Even better, a way to mark my preference for each web site as to which browser opens each window (regardless of the browser used to click on the original link).
But don't listen to me. I'm one of those weird people who bought a bread knife when I already had many other knives in my kitchen.
One of the major safty factors in having a larger car is having a larger car than the car you collide with. By this logic, you can't make a car large enough. By the same logic, everyone in America should carry a handgun and violent crime would be completely eliminated. I think the kind of safty you are talking about is giving more than you get.
Naw, you reload the black tubes of missile spewing death by farting into little pneumatic suction cups that connect to the tubes through the tube spars.
The golden rule here: clock frequency scales all code, architecture scales new code.
There is so much incredibly interesting work out there that no one can cost justify when you get exactly the same performance results by sitting on your thumbs for 18 months.
I'm entirely in favour, though lacking in hope, that Moore's law soon ceases to be the single dominant term in computational progress.
I ran a G450 side by side against a Radeon 8500 DDR playing Quake III. The G450 was in a dual P3/750 system with 384MB, the Radeon 8500 DDR was in an Athlon/900 system with 768MB.
You'd think the Radeon would seriously win that competition. It didn't.
First of all, the G450 with 16 bit colour produced an image quality just as good as the Radeon in 32 bit colour. Maybe a bit better.
On the G450 you had to tune the texture detail down a couple of notches, whereas the Radeon could run at full texture detail. Playing these two cards I barely noticed the difference in texture detail.
The Radeon with 32 bit colour and full textures was still faster than the G450 most of the time. Unless the scene became complicated. Then the Radeon would fall to half the regular frame rate, whereas the Matrox would continue to pump along at 45fps all the time.
A lot of people who looked at the terrible benchmarks of the G450 in 32 bit colour with full textures enabled don't realize how playable this card really was. I actually like the G450 slightly better than the Radeon because the colours were somewhat more intense and the frame rate was more consistent. It terms of my game play success, it was a complete toss up.
I always thought it pretty unfair that the G450 was so heavily critized for not doing 180fps on some silly game loop as if that were a sensible thing for Matrox to accomplish.
The same is true with cars. Some cars with less raw horsepower perform a lot better on the road than you would think looking at the spec. sheet.
Adding in the superior image quality of the G450 the other 90% of the time (when I wasn't playing games) it was a no brainer.
I would say that Matrox was competing well enough at what they set out to accomplish if you bothered to look. Unfortunately, you get no respect in this market unless you run up the numbers on your spec. sheet.
No, unfortunately the STL could not have been designed that way, because the standardization commitee exempted diagnostics from their mandate from the outset. This was before templates were a vital feature of modern C++ and a bad call in retrospect IMHO. However, they had so much trouble finishing off what they did have on their plate that adding another dimension might have sunk the entire enterprise.
The "middle of the road" that the STL strives to achieve is suitability to professional 3rd party library vendors, somewhat randomized by time pressures.
The feeling was that the majority of programmers should be programming on top of application specific libraries not the raw STL itself (although that is intended to be viable where it makes sense to do so).
People come to strange ideas about what C++ was trying to achieve by looking at it from the point of view of "one stop shopping". Rather than providing convenient solutions for every need at the bottom layer, they focussed on making it possible to provide good solutions in the intermediate layers.
None of the STL books recommend thinking about the different containers as interchangable.
Every pair of containers has significantly different semantics. The only pair where this might make sense is vector/deque if front insertion is not required. deque has the advantage of never copying your objects from one place to another behind the scenes. If object copies are expensive, deque is often faster than vector. deque is the default storage for the stack adaptor.
It's still a good practice for application classes to supply their own iterator typedefs.