That is how all of our servers are setup. I'm just a "developer" that uses them but I believe no one knows the root password for our systems. It is a *big* random string that is printed out by the sysadmin that sets up the machine, sealed in an envelope with that person's signature on both sides and stuck in a safe. In the event that a machine is so hosed that the root password is needed it is used and then a new one is generated and sealed away again.
Everyone uses sudo for everything. All sudo access is logged.
The system isn't perfect of course, nothing is, but it goes a long way to the worry of one person having root keys for things.
It probably isn't much work for the ECU to include a little logic to measure battery voltage and only do the shutoff when there is enough juice to start back up and also to restart if the battery drops low due to things like AC. I'd also be unsurprised if it doesn't do the shutoff at idle until the engine temp reaches a certain point. None of that seems like anything complex for a system like that.
Wrapping C/C++ in Java is doable but a pain. I'd argue that Java has such a large set of available libraries and built in APIs that you can generally do a lot more with a lot less code than in other languages.
I can't find the link but there was a good article on Ars a week or so ago that went into the details of a backscatter x-ray versus x-rays used at the doctors office. I believe there are two components, 1 the frequency of the x-ray (where on the EM spectrum the wave lies) and 2 the energy of the x-ray.
Diagnostic x-rays mostly go through you, except for things like bone that are denser and absorb the rays, to expose the x-ray film on the other side of your body.
The body scanners use a different type of x-ray because the goal here is for your skin to absorb all of the x-ray energy which gives off photos that the backscatter machine can detect and convert into an image.
I don't know enough about this to really comment but from what I've read the concern is that even though the total exposure value is much smaller for the scanner than the diagnostic x-ray the scanner has the goal of having your body absorb the entire energy of the x-rays where as the diagnostic x-ray essentially passes through your body without being absorbed except for dense things (like bones).
I don't have the exact language but it is a "Field of Use" restriction such that any implementation that uses the TCK must stipulate in its license that it cannot be used in embedded systems and a few other places. That sort of restriction is not compatible with the Apache license or really any other OSS license from what I've read. Essentially that FoU restriction was added to specifically prevent a competing open source Java implementation, specifically Harmony since it isn't like writing a TCK compliant Java implementation is a trivial task and there were going to be a ton of Java implementations diluting the space.
We have poles all over in the midwest where cables transition from underground to above ground. There is a decent sized conduit that comes out of the ground at the base of the utility pole and runs to the top where it breaks out into the 3 phase above ground run. That looks like exactly what they had here.
Also I have no real idea about the body convulsing at various voltages but I'm guessing 13kv is a bit higher than what is going to cause you to convulse and more in the range of completely frying your nervous system, muscles and whatever else it feels like before the concept of convulsing ever makes it to your muscles.
You can tell a browser to cache things provided over SSL by setting the cache-control and expires headers appropriately as well as making use of etags and 304 responses. Its not hard and with good use of etags you can reduce a LOT of both network and application work.
That was my thought as well. Do what most Java servlet containers do, use a 256 bit securely hashed random number for the session tracking cookie. If you need to track a user for longer than an in-memory session stick that in your database as a key to the necessary info. I've always thought it rather irresponsible for storing encrypted data in cookies. You're just asking for someone to spend time trying to get your keys or session data and if they do they can spoof any data they want.
I'm not a crypto expert but it seems like generating a secure random token should be a lot easier than all that goes into implementing a functional crypto solution.
Ouch, yeah I think that says something about the CS curriculum at that school. The list that the grand parent posted is pretty much the core classes that I had to go through in college. Really the only optional thing that I think everyone should have to take as well is a Sr. Design project type course set like most engineers do.
The problem is not all 4 sides of the signal get obscured. The lights get covered due to blowing winds, which generally come from one direction. Then you get 2 or 3 sides of the signal that appear normal to the drivers and 1 or 2 sides that are obscured.
So the person just driving through is doing what they should, they see an unobscured green light and, as we are all conditioned, drives right through. Someone with an obscured signal may have done the prudent thing and stopped then proceeded with caution but if you're at an intersection of a road with a 45+ speed limit you may not clear the intersection before someone you didn't see when you started comes driving through. Since there is enough snow and ice to foul the light you can bet the roads will be at least somewhat slippery and that makes stopping and avoidance that much harder.
Re:I want an attractive digital display
on
Hand Written Clock
·
· Score: 2, Interesting
I'm using a WRT-3XXN with dd-wrt (not at home and can't remember the model exactly). 1 10/100 uplink, 4 10/100/1000 switched and b/g/n wireless. I've been able to saturate both the wired and wireless on the LAN but I only have 15Mbps DLS so I haven't maxed the WAN port but even with maxing out my DSL at 15Mbps via bittorrent the load average on the thing is like 0.02 with gobs of free memory so I would guess one of these would be fine.
Complete off-topic for the original story but this is exactly why I'm hoping more cars get CVTs as the technology matures. I have a Subaru Legacy with a CVT and it is great for MPG. The car can always run the engine at the optimal RPM for the combination of speed, load and acceleration demand. When cruising on the highway its fun to watch the RPMs vary slightly to compensate for hills but having the speed never budge. I think in this case the Legacy with the CVT gets ~5mpg better than the same care with an automatic or manual transmission.
True but the core Java language doesn't ship with any nice HTML widgets. I believe JSF either does escaping by default or at least has a single app-wide setting to enable it by default. The Spring MVC framework has similar options, where with one line I can enable XML and JS escaping in all content written out by UI components. Being backwards compatible is one thing but not having an option to do default escaping is just opening your developer base up to all sorts of issues.
Look at Confluence by Atlassian. When you edit a page they track the edit action. When another user goes to edit the page they are warned that "John Doe is currently editing this page, last edit at date/time". They also do polling via AJAX so if you're working on a page and another user starts actually editing it you see a message on the page "Jane Doe started editing this page". They also save page drafts scoped to the user to help people resolve edit conflicts. It seems to balance things well with not explicitly forcing locks but actively letting users know when they are heading for a conflict.
How about any sort of web-server type task. I do development on web-based portal software that is highly threaded. Each thread doesn't due a huge amount of work but there are a lot of them (multiple threads per web server request) so having a machine that can run 128 threads (though each is fairly slow) easily outperforms a machine with much faster CPUs but only 4 or 8 of them.
Generally webserver type loads do better on hardware/clusters that can deal with lots of threads even if they aren't all that fast.
The whole point of this is *2* Factor authentication. You use this as well as a password (something you have, something you know). Stealing one or the other is useless. Key loggers are useless because you need to physically have the device or a copy of it to make the system work.
Really this is a stab at an inexpensive version of something like an RSA Card which uses a cryptographically secure RNG that is synced to a master server when it is initialized. The numbers it generates every 60 seconds are only good for a small window so along with a password it makes systems very hard to crack.
Not sure where you are getting your Mozy prices but for home use it is $5/month with unlimited storage space. I currently have 3 home accounts, one of which has over 1TB of data and I'm paying a total of $15/month for all three.
Except you're not going to get compile time errors from the third party library you're using since it is already compiled, you're still stuck with the ugly runtime UnsatisfiedLinkErrors. The JDK has features to support what Google wants to do built in specifically for this case and they really aren't very complicated to use.
Well sure, If you're re-using a standard library it may have handling for the security exception chain and either fail gracefully or work with limited functionality.
If a JDK class is missing and the library class you want to use references it the code won't even run with an UnsatisfiedLinkError. That is a HUGE difference.
Another case where the library class references a missing JDK class but the use of the library class you're using never touches the forbidden code. In that case you again get a UnsatisfiedLinkError. If the use of the JDK class was just restricted by a security policy you only get the security exception if you actually call the API, a much better alternative.
Yeah I'm surprised they didn't do this. Everything they describe is doable via a security policy configuration file and a single custom ClassLoader implementation.
Slashdot Mirror
That is how all of our servers are setup. I'm just a "developer" that uses them but I believe no one knows the root password for our systems. It is a *big* random string that is printed out by the sysadmin that sets up the machine, sealed in an envelope with that person's signature on both sides and stuck in a safe. In the event that a machine is so hosed that the root password is needed it is used and then a new one is generated and sealed away again.
Everyone uses sudo for everything. All sudo access is logged.
The system isn't perfect of course, nothing is, but it goes a long way to the worry of one person having root keys for things.
It probably isn't much work for the ECU to include a little logic to measure battery voltage and only do the shutoff when there is enough juice to start back up and also to restart if the battery drops low due to things like AC. I'd also be unsurprised if it doesn't do the shutoff at idle until the engine temp reaches a certain point. None of that seems like anything complex for a system like that.
Wrapping C/C++ in Java is doable but a pain. I'd argue that Java has such a large set of available libraries and built in APIs that you can generally do a lot more with a lot less code than in other languages.
I can't find the link but there was a good article on Ars a week or so ago that went into the details of a backscatter x-ray versus x-rays used at the doctors office. I believe there are two components, 1 the frequency of the x-ray (where on the EM spectrum the wave lies) and 2 the energy of the x-ray.
Diagnostic x-rays mostly go through you, except for things like bone that are denser and absorb the rays, to expose the x-ray film on the other side of your body.
The body scanners use a different type of x-ray because the goal here is for your skin to absorb all of the x-ray energy which gives off photos that the backscatter machine can detect and convert into an image.
I don't know enough about this to really comment but from what I've read the concern is that even though the total exposure value is much smaller for the scanner than the diagnostic x-ray the scanner has the goal of having your body absorb the entire energy of the x-rays where as the diagnostic x-ray essentially passes through your body without being absorbed except for dense things (like bones).
I don't have the exact language but it is a "Field of Use" restriction such that any implementation that uses the TCK must stipulate in its license that it cannot be used in embedded systems and a few other places. That sort of restriction is not compatible with the Apache license or really any other OSS license from what I've read. Essentially that FoU restriction was added to specifically prevent a competing open source Java implementation, specifically Harmony since it isn't like writing a TCK compliant Java implementation is a trivial task and there were going to be a ton of Java implementations diluting the space.
We have poles all over in the midwest where cables transition from underground to above ground. There is a decent sized conduit that comes out of the ground at the base of the utility pole and runs to the top where it breaks out into the 3 phase above ground run. That looks like exactly what they had here.
Also I have no real idea about the body convulsing at various voltages but I'm guessing 13kv is a bit higher than what is going to cause you to convulse and more in the range of completely frying your nervous system, muscles and whatever else it feels like before the concept of convulsing ever makes it to your muscles.
It doesn't matter what domain the HTTP content is coming from. ANY HTTP content from ANY domain on an HTTPS page results in a warning.
You can tell a browser to cache things provided over SSL by setting the cache-control and expires headers appropriately as well as making use of etags and 304 responses. Its not hard and with good use of etags you can reduce a LOT of both network and application work.
That was my thought as well. Do what most Java servlet containers do, use a 256 bit securely hashed random number for the session tracking cookie. If you need to track a user for longer than an in-memory session stick that in your database as a key to the necessary info. I've always thought it rather irresponsible for storing encrypted data in cookies. You're just asking for someone to spend time trying to get your keys or session data and if they do they can spoof any data they want.
I'm not a crypto expert but it seems like generating a secure random token should be a lot easier than all that goes into implementing a functional crypto solution.
Jasig CAS is another good Apache 2 licensed SSO system. Both it and Shib even include support for true N-Tier proxied authentication.
http://www.jasig.org/cas
Ouch, yeah I think that says something about the CS curriculum at that school. The list that the grand parent posted is pretty much the core classes that I had to go through in college. Really the only optional thing that I think everyone should have to take as well is a Sr. Design project type course set like most engineers do.
The problem is not all 4 sides of the signal get obscured. The lights get covered due to blowing winds, which generally come from one direction. Then you get 2 or 3 sides of the signal that appear normal to the drivers and 1 or 2 sides that are obscured.
So the person just driving through is doing what they should, they see an unobscured green light and, as we are all conditioned, drives right through. Someone with an obscured signal may have done the prudent thing and stopped then proceeded with caution but if you're at an intersection of a road with a 45+ speed limit you may not clear the intersection before someone you didn't see when you started comes driving through. Since there is enough snow and ice to foul the light you can bet the roads will be at least somewhat slippery and that makes stopping and avoidance that much harder.
http://www.thinkgeek.com/gadgets/watches/8e18/
I'm using a WRT-3XXN with dd-wrt (not at home and can't remember the model exactly). 1 10/100 uplink, 4 10/100/1000 switched and b/g/n wireless. I've been able to saturate both the wired and wireless on the LAN but I only have 15Mbps DLS so I haven't maxed the WAN port but even with maxing out my DSL at 15Mbps via bittorrent the load average on the thing is like 0.02 with gobs of free memory so I would guess one of these would be fine.
The easier thing to do would be to look at the DD-WRT hardware page ( http://www.dd-wrt.com/wiki/index.php/Supported_Devices ) and find something with a decent CPU/RAM combo.
Complete off-topic for the original story but this is exactly why I'm hoping more cars get CVTs as the technology matures. I have a Subaru Legacy with a CVT and it is great for MPG. The car can always run the engine at the optimal RPM for the combination of speed, load and acceleration demand. When cruising on the highway its fun to watch the RPMs vary slightly to compensate for hills but having the speed never budge. I think in this case the Legacy with the CVT gets ~5mpg better than the same care with an automatic or manual transmission.
True but the core Java language doesn't ship with any nice HTML widgets. I believe JSF either does escaping by default or at least has a single app-wide setting to enable it by default. The Spring MVC framework has similar options, where with one line I can enable XML and JS escaping in all content written out by UI components. Being backwards compatible is one thing but not having an option to do default escaping is just opening your developer base up to all sorts of issues.
Look at Confluence by Atlassian. When you edit a page they track the edit action. When another user goes to edit the page they are warned that "John Doe is currently editing this page, last edit at date/time". They also do polling via AJAX so if you're working on a page and another user starts actually editing it you see a message on the page "Jane Doe started editing this page". They also save page drafts scoped to the user to help people resolve edit conflicts. It seems to balance things well with not explicitly forcing locks but actively letting users know when they are heading for a conflict.
How about any sort of web-server type task. I do development on web-based portal software that is highly threaded. Each thread doesn't due a huge amount of work but there are a lot of them (multiple threads per web server request) so having a machine that can run 128 threads (though each is fairly slow) easily outperforms a machine with much faster CPUs but only 4 or 8 of them.
Generally webserver type loads do better on hardware/clusters that can deal with lots of threads even if they aren't all that fast.
The whole point of this is *2* Factor authentication. You use this as well as a password (something you have, something you know). Stealing one or the other is useless. Key loggers are useless because you need to physically have the device or a copy of it to make the system work.
Really this is a stab at an inexpensive version of something like an RSA Card which uses a cryptographically secure RNG that is synced to a master server when it is initialized. The numbers it generates every 60 seconds are only good for a small window so along with a password it makes systems very hard to crack.
Except mozy only charges $5/month for unlimited storage for a personal account so it should only cost you $60/year for as much as you want.
Not sure where you are getting your Mozy prices but for home use it is $5/month with unlimited storage space. I currently have 3 home accounts, one of which has over 1TB of data and I'm paying a total of $15/month for all three.
Exactly what I was going to say. It sounds exactly like what the poster is asking for.
Except you're not going to get compile time errors from the third party library you're using since it is already compiled, you're still stuck with the ugly runtime UnsatisfiedLinkErrors. The JDK has features to support what Google wants to do built in specifically for this case and they really aren't very complicated to use.
Well sure, If you're re-using a standard library it may have handling for the security exception chain and either fail gracefully or work with limited functionality.
If a JDK class is missing and the library class you want to use references it the code won't even run with an UnsatisfiedLinkError. That is a HUGE difference.
Another case where the library class references a missing JDK class but the use of the library class you're using never touches the forbidden code. In that case you again get a UnsatisfiedLinkError. If the use of the JDK class was just restricted by a security policy you only get the security exception if you actually call the API, a much better alternative.
Yeah I'm surprised they didn't do this. Everything they describe is doable via a security policy configuration file and a single custom ClassLoader implementation.