From what I can tell, 2.6 probably is up to our standards for production. Linux is great, the transparent development is great, and even the changelogs are great.. for kernel hackers. However the changelogs are rarely informative to me. Not that that's a bad thing, or should be changed, it's just reality. As always, production usage decisions have to be made based on testing individual releases with your particular workload. But it would be nice to have some release notes to point us in the right direction from time to time. That's all.
I think you're right. That's certainly the case in our datacenters... we're ditching all our Dell servers (buh bye Intel, so long, it's been real..) and replacing them with nice shiny new IBM BladeCenters and JS20 blades (PPC64) running Linux. What I couldn't believe is how much *CHEAPER* the 970 blades were than the Intel Xeon blades. Go figure.
From the "I-might-have-to-run-this-in-production" department, VM patches like this in a stable tree give me the roaring shiznits:
[PATCH] Narrow blk_congestion_wait races [PATCH] kswapd throttling fixes - comment "The logic in balance_pgdat() is all bollixed up" [PATCH] shrink_slab: math precision fix - comment "In shrink_slab(), do the multiply before the divide to avoid losing precision." !!!! [PATCH] vmscan: avoid bogus throttling [PATCH] fix the kswapd zone scanning algorithm...etc etc. Many more of the same.
If we're weren't currently having VM issues with 2.4 (servers with 8gig+ memory) I wouldn't care. But we're seriously thinking of using 2.6 in production to resolve it. No, stop laughing, really.
Actually I don't think I'm going to read any more kernel changelogs. It's like being at a restaurant, sometimes you just don't want to know what's going on in the kitchen. Except with open source, the kitchen is more like a public urinal. And the food is one big shit sandwich that everone... ok I'll stop now.
Re:Plain text passwords in web.xml
on
J2EE Security
·
· Score: 2, Informative
It can be done. The decryption of the password should take place outside the server itself, using a physically secure encryption device such as an Atalla or Futurex box. An organization should also have solid key management policies and procedures in place (dual-control/split-knowledge/etc) to keep your master key safe - otherwise the PSD don't really add any value.
There are no absolutes in security. There is always a security risk, the name of the game is to manage that risk in a cost-effective manner. If anyone can access the data, in any way, then you have a potential security problem. Having a server with no network connectivity only removes a subset of potential risks. e.g. employee fraud for many companies is a larger problem than external threats.
Clearly network security is worthwhile, but I've always felt there is not enough focus placed on application-level security, along with careful assessment of the policies and procedures relating to data access within an organization.
All the firewalls and encryption in the world won't help you if a bug in your app allows people to bypass the password screen, or some employee in your company uses their access to steal data.
Slashdot Mirror
From what I can tell, 2.6 probably is up to our standards for production. Linux is great, the transparent development is great, and even the changelogs are great.. for kernel hackers. However the changelogs are rarely informative to me. Not that that's a bad thing, or should be changed, it's just reality. As always, production usage decisions have to be made based on testing individual releases with your particular workload. But it would be nice to have some release notes to point us in the right direction from time to time. That's all.
I think you're right. That's certainly the case in our datacenters... we're ditching all our Dell servers (buh bye Intel, so long, it's been real..) and replacing them with nice shiny new IBM BladeCenters and JS20 blades (PPC64) running Linux. What I couldn't believe is how much *CHEAPER* the 970 blades were than the Intel Xeon blades. Go figure.
From the "I-might-have-to-run-this-in-production" department, VM patches like this in a stable tree give me the roaring shiznits:
...etc etc. Many more of the same.
[PATCH] Narrow blk_congestion_wait races
[PATCH] kswapd throttling fixes - comment "The logic in balance_pgdat() is all bollixed up"
[PATCH] shrink_slab: math precision fix - comment "In shrink_slab(), do the multiply before the divide to avoid losing precision." !!!!
[PATCH] vmscan: avoid bogus throttling
[PATCH] fix the kswapd zone scanning algorithm
If we're weren't currently having VM issues with 2.4 (servers with 8gig+ memory) I wouldn't care. But we're seriously thinking of using 2.6 in production to resolve it. No, stop laughing, really.
Actually I don't think I'm going to read any more kernel changelogs. It's like being at a restaurant, sometimes you just don't want to know what's going on in the kitchen. Except with open source, the kitchen is more like a public urinal. And the food is one big shit sandwich that everone... ok I'll stop now.
It can be done. The decryption of the password should take place outside the server itself, using a physically secure encryption device such as an Atalla or Futurex box. An organization should also have solid key management policies and procedures in place (dual-control/split-knowledge/etc) to keep your master key safe - otherwise the PSD don't really add any value.
Harry Knowles' site has a bunch of reviews here, here, here, and the funniest one here.
There are no absolutes in security. There is always a security risk, the name of the game is to manage that risk in a cost-effective manner. If anyone can access the data, in any way, then you have a potential security problem. Having a server with no network connectivity only removes a subset of potential risks. e.g. employee fraud for many companies is a larger problem than external threats.
Clearly network security is worthwhile, but I've always felt there is not enough focus placed on application-level security, along with careful assessment of the policies and procedures relating to data access within an organization.
All the firewalls and encryption in the world won't help you if a bug in your app allows people to bypass the password screen, or some employee in your company uses their access to steal data.