I think it's pretty clear. MySpace terms of service dictate that you will not access the service while filling out fraudulent data in your profile. She could have chosen not to create a profile.
An analogy: The GPL is quite clear. You can only redistribute it if you comply with the license. If you don't like that requirement, then you can choose not to redistribute GPL software.
I can understand lots of people here on slashdot want to be anonymous, or use pseudonyms; and are not sympathetic to being forced to fill out truthful information in social profiles. To them I say: Though, choose not to create that profile. (And I suspect most of you really didn't want that profile anyway)
The directive concerns removable batteries. Not replaceable batteries. Consumers need to be able to quickly and easily remove the battery for separate disposal before throwing away the device.
Quickly and easily removing the battery may require cracking the casing of the device by applying pressure with a screwdriver at a location indicated in the manual.
I bother with it. Now, I don't vote for the green political party, support nuclear all the way and don't get upset about animal testing. But if the manufacturer made it easy to remove the battery or capacitor? Then yes, I remove the battery before dumping the electronic gizmo.
Why? Because it takes me little effort anyway, and it's "the right thing to do".
Strange. Over here in the old country *ahem*, isp's give you web-access to your currently used volume and how many GB you have left... One isp even delivers this information also through a windows app that lives in the taskbar tray.
Terminating a customer account without giving the customer followup tools so they can watch their usage... just seems malicious.
So, organize, and pressure Comcast into providing access to this information...
When you watch television, and someone walks into the room; they can casually join your activity.
When you are gaming, this is not the case. Usually someone entering the room either interrupts you, leaves, or passively watches.
Talking: When watching television you can talk to somebody else. Most television programs are not that interesting anyway. Gaming requires more attention, and so the gamer has to stop his gaming to respond or even listen to a question. And there is a higher chance the gamer gives a irritable response, since his character on WoW just got killed while somebody was distracting him.
This leaves non-gamers with a negative image of gaming.
For getting java docs on 3rd party libraries your best bet is letting Maven manage your dependencies and generate your Eclipse project files. Maven can then also download the sources and javadoc of those libraries and make them accessible from Eclipse.
Failure can happen when CPU1 creates the singleton;
CPU2 retrieves the pointer to the singleton;
If, and only if, CPU2 already has (stale) cache information about the memory the singleton occupies (I admit, this could be rare condition);
methods executed on CPU2 using that memory will now fail in unexpected ways.
It's a race condition that you could test for a million times and not have a fail; but with my luck, put it on a production machine and the JVM will have a native crash.
Anyway, YMMV, but I don't go hunting for this kind of bug in the codebase. If I have to edit that file for any other reason though, I'll change it to be correct.
I understand your point. Please understand my point that there is a very subtle reason why this code can fail on multiprocessor systems.
Please take the time to read about the Java Memory Model and about Memory Barriers. The reason why this code can fail is very subtle and is covered by my previous message.
As a example, a instance of this particular class can fail on CPU2 when calling getClass() on it. I'm not kidding.
First; I agree with some of the things you say. But I have to disagree on the following:
Other examples include more mundane stuff like the tools recommending that you synchronize or un-synchronize a getter, even when everyone understands why it's OK for it to be as it is.
E.g., a _stateless_ class as a singleton is just an (arguably premature and unneded) speed optimization, because some people think they're saving so much by a singleton instead of the couple of cycles it takes to do a new on a class with no members and no state. It doesn't really freaking matter if there's exactly one of it, or someone gets a copy of it. But invariably the tools will make an "OMG, unsynchronized singleton" fuss, because they don't look deep enough to see if there's actually some state that must be unique. A unsynchronized singleton is not a problem on a singlecore CPU system. But it may fail on SMP system or on a multicore CPU system, and when it does fail, it may do so spectacularly.
I'll explain: You create the unsynchronized singleton on CPU1. CPU2 now retrieves the singleton. But it's possible CPU2 has out-of-date cache on the memory that is occupied by your singleton. If that happens, your singleton will not work correctly.
Don't create a unsynchronized singleton. Either synchronize; or create the singleton in a static initializer; or just call new anytime you need a instance of that class.
You may believe I'm wrong on some subtle point, or for some particular use case. I'm not. In Java, do not use a unsynchronized singleton on a multithreaded system.
The same happened to me. I purchased my X-Fi just for Bioshock.
Environmental surround sound through my regular headphones was my must-have feature. This is provided by the X-Fi through EAX 5 and CMSS-3D. Sadly, I will not be leaving Creative as a customer, until another brand of soundcard can give me a identical or superior experience.
Some car manufacturers still make runs of brand-new parts for some antique cars. Yes, I know, "Some". For instance Ford, for the 1970's mustang. Well, maybe it's not Ford itself that makes the parts and they've sold (some) molds to someone else, point is; there is a demand, and supply is created.
Disclaimer: I'm not that into cars, so I could be wrong about what decade Mustangs are originally from.
It's an interesting argument. Well, not because of what it says in the blog. But because it makes me question what exactly should be considered cross-site. There can be two opinions on where a potential cross site exploit is located in the html.
A: <object data="data:application/x-unknown,ERROR">
<object data="HTTP://WWW.EVIL.INC/404/" type="text/html">
<object data="data:*the eyes DATAURI*...>
</object>
</object>
The evil code is either the EVIL.INC url by itself and only that, or the entire object with all of its contents that were tainted by the cross-site url. In the first case, we can safely render the embedded fallback, in the other case the fallback has become as suspicious as the cross-site url. I don't believe cross site vulnerabilities, and how browsers should react to them or avoid them, are mentioned anywhere in the HTML spec.
I don't know, both possibilities can be valid. I'm glad I don't build browsers.
If I put my code to MBR and LILO loader somewhere else and then start it, will it work? I guess so.
Are you root? If not then the answer is no. Root is still a user, and LILO is still just usercode.
Note: MBR can be modified from usermode, the first sectors of disk are still unprotected Yes, in this regard it is just as secure as Linux. You still need to be a administrator to overwrite the mbr. Reversing all of this damn argument, how exactly do you propose we defend the contents of the MBR from root on Linux? (Or GNU/Linux if you will)
Slashdot Mirror
Apparently commands for the botnet are signed with a 1024 byte key.
I bet Srizbi would pass its SOX compliance audit.
Waterboarding?
I think it's pretty clear. MySpace terms of service dictate that you will not access the service while filling out fraudulent data in your profile. She could have chosen not to create a profile.
An analogy: The GPL is quite clear. You can only redistribute it if you comply with the license. If you don't like that requirement, then you can choose not to redistribute GPL software.
I can understand lots of people here on slashdot want to be anonymous, or use pseudonyms; and are not sympathetic to being forced to fill out truthful information in social profiles. To them I say: Though, choose not to create that profile. (And I suspect most of you really didn't want that profile anyway)
You may want to evaluate Avira: http://www.avira.com/en/products/index.html
I use the free personal edition, and am quite satisfied with it. YMMV
Why is it reasonable for Steam to run at startup by default?
I don't think that it is reasonable by the way. It is pure laziness on the part of software developers.
So, as the GP said, stop defending Steam.
The directive concerns removable batteries. Not replaceable batteries. Consumers need to be able to quickly and easily remove the battery for separate disposal before throwing away the device.
Quickly and easily removing the battery may require cracking the casing of the device by applying pressure with a screwdriver at a location indicated in the manual.
I bother with it. Now, I don't vote for the green political party, support nuclear all the way and don't get upset about animal testing. But if the manufacturer made it easy to remove the battery or capacitor? Then yes, I remove the battery before dumping the electronic gizmo.
Why? Because it takes me little effort anyway, and it's "the right thing to do".
Tools are created for a particular audience. So, either the design of the tool is wrong XOR the user is not in the target audience.
Strange. Over here in the old country *ahem*, isp's give you web-access to your currently used volume and how many GB you have left... One isp even delivers this information also through a windows app that lives in the taskbar tray.
Terminating a customer account without giving the customer followup tools so they can watch their usage... just seems malicious.
So, organize, and pressure Comcast into providing access to this information...
Great, if the blocked site makes use of frames, you just can't bypass the warning. And there's no way to permanently unblock a site...
<sarcasm>I feel safer already</sarcasm>
When you watch television, and someone walks into the room; they can casually join your activity.
When you are gaming, this is not the case. Usually someone entering the room either interrupts you, leaves, or passively watches.
Talking: When watching television you can talk to somebody else. Most television programs are not that interesting anyway. Gaming requires more attention, and so the gamer has to stop his gaming to respond or even listen to a question. And there is a higher chance the gamer gives a irritable response, since his character on WoW just got killed while somebody was distracting him.
This leaves non-gamers with a negative image of gaming.
no
For getting java docs on 3rd party libraries your best bet is letting Maven manage your dependencies and generate your Eclipse project files. Maven can then also download the sources and javadoc of those libraries and make them accessible from Eclipse.
Yes.
Failure can happen when CPU1 creates the singleton;
CPU2 retrieves the pointer to the singleton;
If, and only if, CPU2 already has (stale) cache information about the memory the singleton occupies (I admit, this could be rare condition);
methods executed on CPU2 using that memory will now fail in unexpected ways.
It's a race condition that you could test for a million times and not have a fail; but with my luck, put it on a production machine and the JVM will have a native crash.
Anyway, YMMV, but I don't go hunting for this kind of bug in the codebase. If I have to edit that file for any other reason though, I'll change it to be correct.
I understand your point. Please understand my point that there is a very subtle reason why this code can fail on multiprocessor systems.
Please take the time to read about the Java Memory Model and about Memory Barriers. The reason why this code can fail is very subtle and is covered by my previous message.
As a example, a instance of this particular class can fail on CPU2 when calling getClass() on it. I'm not kidding.
E.g., a _stateless_ class as a singleton is just an (arguably premature and unneded) speed optimization, because some people think they're saving so much by a singleton instead of the couple of cycles it takes to do a new on a class with no members and no state. It doesn't really freaking matter if there's exactly one of it, or someone gets a copy of it. But invariably the tools will make an "OMG, unsynchronized singleton" fuss, because they don't look deep enough to see if there's actually some state that must be unique. A unsynchronized singleton is not a problem on a singlecore CPU system. But it may fail on SMP system or on a multicore CPU system, and when it does fail, it may do so spectacularly.
I'll explain: You create the unsynchronized singleton on CPU1. CPU2 now retrieves the singleton. But it's possible CPU2 has out-of-date cache on the memory that is occupied by your singleton. If that happens, your singleton will not work correctly.
Don't create a unsynchronized singleton. Either synchronize; or create the singleton in a static initializer; or just call new anytime you need a instance of that class.
A link to a related problem:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
You may believe I'm wrong on some subtle point, or for some particular use case. I'm not. In Java, do not use a unsynchronized singleton on a multithreaded system.
Dear Google, If you ever set foot in France, you will be arrested. Regards, the French Republic
Seconded! I used to watch those when I was young.
The same happened to me. I purchased my X-Fi just for Bioshock.
Environmental surround sound through my regular headphones was my must-have feature. This is provided by the X-Fi through EAX 5 and CMSS-3D. Sadly, I will not be leaving Creative as a customer, until another brand of soundcard can give me a identical or superior experience.
Some car manufacturers still make runs of brand-new parts for some antique cars. Yes, I know, "Some". For instance Ford, for the 1970's mustang. Well, maybe it's not Ford itself that makes the parts and they've sold (some) molds to someone else, point is; there is a demand, and supply is created. Disclaimer: I'm not that into cars, so I could be wrong about what decade Mustangs are originally from.
A:
<object data="data:application/x-unknown,ERROR">
<object data="HTTP://WWW.EVIL.INC/404/" type="text/html">
<object data="data:*the eyes DATAURI*
</object>
</object>
B:
<object data="data:application/x-unknown,ERROR">
<OBJECT DATA="HTTP://WWW.EVIL.INC/404/" TYPE="TEXT/HTML">
<OBJECT DATA="DATA:*THE EYES DATAURI*
</OBJECT>
</object>
The evil code is either the EVIL.INC url by itself and only that, or the entire object with all of its contents that were tainted by the cross-site url. In the first case, we can safely render the embedded fallback, in the other case the fallback has become as suspicious as the cross-site url. I don't believe cross site vulnerabilities, and how browsers should react to them or avoid them, are mentioned anywhere in the HTML spec.
I don't know, both possibilities can be valid. I'm glad I don't build browsers.
You mean like a Self Replicating Lunar Factory?
Root is still a user, and LILO is still just usercode. Note: MBR can be modified from usermode, the first sectors of disk are still unprotected
Yes, in this regard it is just as secure as Linux. You still need to be a administrator to overwrite the mbr. Reversing all of this damn argument, how exactly do you propose we defend the contents of the MBR from root on Linux? (Or GNU/Linux if you will)