What you said is true, however there's a flip side to it: if you aren't putting in so many hours, and you work in an at-will state, the employer can simply terminate you.
So, while they can't legally require you to work n hours per week, if you consistently fail to do so they will just fire you. You can be terminated for any reason or no reason at all, as long as they don't say it's for one of the handful of forbidden reasons (race, gender, etc.)
Many salaried positions actually forbid you from engaging in other work without the company's permission. The idea is that if you are being paid salary, you are on the clock 24/7, so technically you shouldn't be working for anyone else.
(My employer has no such policy, fortunately. But my previous one did.)
The results should still be the same, assuming you have structured your systems meticulously and accounted for any errors. Intel has an interesting article about deterministic parallelization.
As I said, if you introduce any deliberately random elements, you will obviously not get the same results. But if both systems have been developed to produce entirely deterministic results, and use adequate data validation to ensure no errors creep in, the results would be identical.
You guys telling me it's not possible to write a program that behaves the same way and produces the same results on more than one system? Might as well toss out the entire field of Computer Science, then.:-p
I admit it's not easy to do this, the more complex a program gets, but it is by no means impossible.
I do comment my code. Sorry if I implied otherwise. My problem is with code that's sloppy, hard to follow, and uncommented. People often do this because they think it makes their jobs more secure.
Well, it doesn't. They eventually get laid off, and someone like me is brought in to figure out what the hell they did. Leaving out comments is just a dick thing to do.
You can code it to be deterministic. Whether or not that matters to you obviously depends on what you're trying to accomplish. If the goal is 100% reliable and repeatable results, then you'd code it accordingly.
Like I said, I compare the code with the comments. Intentions matter. If the comments say the code does something that it doesn't actually do, it leads me to suspect a problem. I never take the comments at face value, but I do consider them important documentation of what the developer meant to do.
I hope I didn't give the impression that I rely on the comments to tell me what the code really does. As you said, that's foolish and simply asking for trouble.
I agree there. I will tend toward writing more verbose code for the sake of making it very clear and easy to follow. Unfortunately, I have worked with a lot of people who try to cram as much logic into as little space as possible, with worthless variable names and no comments, so while you can figure out what the code is doing, you have no idea why it's doing it.
For me, that's the real value of comments: they tell you what the developer intended, and from there it's much easier to determine whether it's doing what it should. I've seen plenty of cases where a comment says the code should be doing x, but it's actually doing y. Without any comments, I'm forced to go back to original requirements, and sometimes I don't even have those available (legacy systems suck sometimes.)
Those things you mentioned are bugs. They may be really trivial bugs, but they're still bugs.
You are right by way of implication that the more complex a program is, the more likely it is to expose any obscure bugs in the system.
That said, there are safeguards one can have in place to ensure consistency of results, like checksums/CRCs/ECC for all data and storage. You just aren't going to find that level of quality in consumer-grade hardware. Then again, what kind of idiot would want to store his very essence on the $300 netbook he bought at Costco?:-p
The problem is that the continuity of existence you perceive as "you" will end the moment your original body is destroyed. The new body and mind will be identical to the original in every way--except that the conscious existence of the original is gone.
Everyone else will see that person as you, but from your own perspective, you're dead.
Computers aren't magic. Two systems, given the exact same hardware, software, and configuration should produce exactly the same results for a given program, unless there is a hardware defect somewhere (e.g. bad RAM) or there was deliberate randomness introduced.
Yeah, I had a crappy little Samsung feature phone with Sprint, and I could install any third-party J2ME apps I wanted (so long as my phone had the horsepower to run them, of course.)
Er, the person designing the software absolutely should know in what ways someone might attack it, otherwise how are they going to secure it?
A developer should know, broadly, what attack vectors their code might be vulnerable to--injection, overflows, etc.--and code to avoid them. But that's all part of having a security-conscious development organization. You are right in that they shouldn't be guarding against very narrow, specific attacks, but knowing what the general methods of attack are is absolutely essential, otherwise what is it you're going to defend against?
I think what people (particularly those who are not developers or system administrators) often fail to realize is that security isn't something you can easily bolt-on later, it should be built into the application/system from the start. Unfortunately, just about all organizations are going to wind up buying software to which they have no access to source code and no guarantees that there's any reasonable security built into it, so you still have to protect it any other way you can.
A big part of it is controlling information--and access to it--inside your organization. Anyone who cold calls your office should not be able to reach someone who is both a) capable of handing out sensitive information and b) not informed enough to realize the information they're giving out is sensitive.
A really trivial example would be something like a receptionist knowing the access code to the server room. Some guy shows up with a toolkit, claims to be from Dell, says there's a down server and it's absolutely critical he gets into the server room immediately--the first person he encounters should not be someone who can actually give him that access, as they most likely do not understand the implications of granting it.
Instead, you have a small number of people with such sensitive access--a primary and two backups--and anyone who wants in has to go through those individuals, and they should be technically-oriented and fully cognizant of the consequences of granting someone access to their machines.
Likewise, any data on your company's public network should be segregated so that everyone doesn't have access to everything. Developers don't need access to HR data. HR doesn't need access to development systems. Marketing doesn't need access to development systems. With a decent privilege system in place, social engineering attacks are much less effective. Such attacks often work best when you get someone who, again, has access to interesting information but doesn't realize its importance to the attacker--so they don't realize exactly why they shouldn't give it out. By "access," I mean both physical and network access. Developers where I work cannot physically get into the server room, only IT can. We do, however, have network access to particular systems in the server room. This is as it should be.
Another important aspect of preventing social engineering attacks is having a security culture across your company. This does not work overnight. You have to really drill into your people why you control access the way you do, and why you never, ever give out information that's not really yours to share just because someone sounds desperate. Have a procedure for handling those types of requests and follow it to the letter. For emergencies, have a defined process for expediting any requests--but still make sure they get to the right person. You can't afford to cut corners on this. Everyone needs to know your security policy, why you have it, how to follow it, and clear consequences for ignoring or subverting it. If that means firing people, so be it.
I am a Palm fan from way back, but really, what is the company even worth now? They don't own the original OS (that was spun off into another company years ago), they don't manufacture devices anymore, and while webOS is pretty nice, it's not different enough to set itself apart from Android and iOS. And didn't HP basically can all the old Palm employees, anyway?
Sad to see a once great company trashed this way, but I'm not sure there's much to recover from it at this point.
Yeah, webOS is a nice platform, but they probably could've developed their own mobile OS for less than a billion dollars. And I can't imagine the patent portfolio is worth enough to ever pay back what HP spent on the acquisition.
So far, Facebook has seemed content to grow their core business rather than branch out into other offerings. They also don't currently sell any physical items at all (as far as I know), so going into a really tough market like mobile devices would be a huge investment without any guaranteed payoff.
Slashdot Mirror
What you said is true, however there's a flip side to it: if you aren't putting in so many hours, and you work in an at-will state, the employer can simply terminate you.
So, while they can't legally require you to work n hours per week, if you consistently fail to do so they will just fire you. You can be terminated for any reason or no reason at all, as long as they don't say it's for one of the handful of forbidden reasons (race, gender, etc.)
Many salaried positions actually forbid you from engaging in other work without the company's permission. The idea is that if you are being paid salary, you are on the clock 24/7, so technically you shouldn't be working for anyone else.
(My employer has no such policy, fortunately. But my previous one did.)
I've seen Windows 7 systems where the user profile folders are kept on a separate partition, so evidently it is possible to do that.
But there's still no way to guarantee all programs store their data under user profile folders.
And the whole point of Net Neutrality is to keep those middlemen from abusing their power the way middlemen always tend to do.
The results should still be the same, assuming you have structured your systems meticulously and accounted for any errors. Intel has an interesting article about deterministic parallelization.
As I said, if you introduce any deliberately random elements, you will obviously not get the same results. But if both systems have been developed to produce entirely deterministic results, and use adequate data validation to ensure no errors creep in, the results would be identical.
You guys telling me it's not possible to write a program that behaves the same way and produces the same results on more than one system? Might as well toss out the entire field of Computer Science, then. :-p
I admit it's not easy to do this, the more complex a program gets, but it is by no means impossible.
I do comment my code. Sorry if I implied otherwise. My problem is with code that's sloppy, hard to follow, and uncommented. People often do this because they think it makes their jobs more secure.
Well, it doesn't. They eventually get laid off, and someone like me is brought in to figure out what the hell they did. Leaving out comments is just a dick thing to do.
You can code it to be deterministic. Whether or not that matters to you obviously depends on what you're trying to accomplish. If the goal is 100% reliable and repeatable results, then you'd code it accordingly.
Like I said, I compare the code with the comments. Intentions matter. If the comments say the code does something that it doesn't actually do, it leads me to suspect a problem. I never take the comments at face value, but I do consider them important documentation of what the developer meant to do.
I hope I didn't give the impression that I rely on the comments to tell me what the code really does. As you said, that's foolish and simply asking for trouble.
Much of the code I work with is written in MUMPS.
Pity me.
I agree there. I will tend toward writing more verbose code for the sake of making it very clear and easy to follow. Unfortunately, I have worked with a lot of people who try to cram as much logic into as little space as possible, with worthless variable names and no comments, so while you can figure out what the code is doing, you have no idea why it's doing it.
For me, that's the real value of comments: they tell you what the developer intended, and from there it's much easier to determine whether it's doing what it should. I've seen plenty of cases where a comment says the code should be doing x, but it's actually doing y. Without any comments, I'm forced to go back to original requirements, and sometimes I don't even have those available (legacy systems suck sometimes.)
That's called "job security"!
(For anyone who doesn't get it, I'm kidding. I hate it when people don't comment their code, especially when it's for that very reason.)
Really? I hadn't heard that. Quite interesting.
You are illustrating my point, really. :)
Those things you mentioned are bugs. They may be really trivial bugs, but they're still bugs.
You are right by way of implication that the more complex a program is, the more likely it is to expose any obscure bugs in the system.
That said, there are safeguards one can have in place to ensure consistency of results, like checksums/CRCs/ECC for all data and storage. You just aren't going to find that level of quality in consumer-grade hardware. Then again, what kind of idiot would want to store his very essence on the $300 netbook he bought at Costco? :-p
"Should" is just a hedge. They will behave identically. If they don't, something is wrong. A properly-functioning computer is entirely deterministic.
Nah, cosmic rays just give them superpowers.
The problem is that the continuity of existence you perceive as "you" will end the moment your original body is destroyed. The new body and mind will be identical to the original in every way--except that the conscious existence of the original is gone.
Everyone else will see that person as you, but from your own perspective, you're dead.
Computers aren't magic. Two systems, given the exact same hardware, software, and configuration should produce exactly the same results for a given program, unless there is a hardware defect somewhere (e.g. bad RAM) or there was deliberate randomness introduced.
Yeah, I had a crappy little Samsung feature phone with Sprint, and I could install any third-party J2ME apps I wanted (so long as my phone had the horsepower to run them, of course.)
Er, the person designing the software absolutely should know in what ways someone might attack it, otherwise how are they going to secure it?
A developer should know, broadly, what attack vectors their code might be vulnerable to--injection, overflows, etc.--and code to avoid them. But that's all part of having a security-conscious development organization. You are right in that they shouldn't be guarding against very narrow, specific attacks, but knowing what the general methods of attack are is absolutely essential, otherwise what is it you're going to defend against?
I think what people (particularly those who are not developers or system administrators) often fail to realize is that security isn't something you can easily bolt-on later, it should be built into the application/system from the start. Unfortunately, just about all organizations are going to wind up buying software to which they have no access to source code and no guarantees that there's any reasonable security built into it, so you still have to protect it any other way you can.
A big part of it is controlling information--and access to it--inside your organization. Anyone who cold calls your office should not be able to reach someone who is both a) capable of handing out sensitive information and b) not informed enough to realize the information they're giving out is sensitive.
A really trivial example would be something like a receptionist knowing the access code to the server room. Some guy shows up with a toolkit, claims to be from Dell, says there's a down server and it's absolutely critical he gets into the server room immediately--the first person he encounters should not be someone who can actually give him that access, as they most likely do not understand the implications of granting it.
Instead, you have a small number of people with such sensitive access--a primary and two backups--and anyone who wants in has to go through those individuals, and they should be technically-oriented and fully cognizant of the consequences of granting someone access to their machines.
Likewise, any data on your company's public network should be segregated so that everyone doesn't have access to everything. Developers don't need access to HR data. HR doesn't need access to development systems. Marketing doesn't need access to development systems. With a decent privilege system in place, social engineering attacks are much less effective. Such attacks often work best when you get someone who, again, has access to interesting information but doesn't realize its importance to the attacker--so they don't realize exactly why they shouldn't give it out. By "access," I mean both physical and network access. Developers where I work cannot physically get into the server room, only IT can. We do, however, have network access to particular systems in the server room. This is as it should be.
Another important aspect of preventing social engineering attacks is having a security culture across your company. This does not work overnight. You have to really drill into your people why you control access the way you do, and why you never, ever give out information that's not really yours to share just because someone sounds desperate. Have a procedure for handling those types of requests and follow it to the letter. For emergencies, have a defined process for expediting any requests--but still make sure they get to the right person. You can't afford to cut corners on this. Everyone needs to know your security policy, why you have it, how to follow it, and clear consequences for ignoring or subverting it. If that means firing people, so be it.
I am a Palm fan from way back, but really, what is the company even worth now? They don't own the original OS (that was spun off into another company years ago), they don't manufacture devices anymore, and while webOS is pretty nice, it's not different enough to set itself apart from Android and iOS. And didn't HP basically can all the old Palm employees, anyway?
Sad to see a once great company trashed this way, but I'm not sure there's much to recover from it at this point.
Yeah, webOS is a nice platform, but they probably could've developed their own mobile OS for less than a billion dollars. And I can't imagine the patent portfolio is worth enough to ever pay back what HP spent on the acquisition.
So far, Facebook has seemed content to grow their core business rather than branch out into other offerings. They also don't currently sell any physical items at all (as far as I know), so going into a really tough market like mobile devices would be a huge investment without any guaranteed payoff.
If being a vegan was so great, why did you quit?
This claptrap gets a +5, Insightful? Christ, Slashdot, what the hell happened?