How can someone be rewarded for a success, if that success is later revealed to be a failure.
I see your point. How about deferred bonuses? They can be paid out, say, 24 months after they are "earned". This way, people are only rewarded for long-term success.
I doubt that it's possible to add progressive scan to a game using normal hacks. But you're welcome to join the wiird forums and create a request in the support area.
If the problem is no corresponding disincentive for failure, it doesn't make sense to remove the incentive for success.
Instead, should unwarranted bonuses be given that later turn out to be fraudulent, the bonuses should be clawed back. Perhaps add a penalty of 50% of the bonus on top of clawing back the full bonus.
The Israeli government is not losing support because they are Jews. They are losing support because of their actions.
We have a President who thinks his life would be a lot easier if the Israeli government would stop pissing off the international community with shit like the settlements. Then he wouldn't have to tell his ambassadors to exercise their Security Council veto every time the Israeli government engages in an international faux pas.
Regarding your last point, however, I'm inclined to agree. Look at how quickly the US turned on Gaddafi. Our loyalty does not run deep at all. Not that we should have had any loyalty with Gaddafi to begin with...
I wish my bank would automatically take the right amount from checking. I have to log in once a month to do it. But that's a good thing, because it allows me to keep an eye on my account for fraudulent purchases.
Wow, that's quite presumptuous of you. I didn't say I forgot how to do it, I said I shouldn't have to do it. And I don't know where this managed language thing came from, I never even told you what languages I've used. But if you really want to get into some kinda pissing match, then I shall whip out the credentials.
For the record, most of my actual programming is done in C, usually with an embedded compiler. It's the kind of programming that requires you to have a spare monitor just for datasheets, so that you can see what CPU register bits you need to fiddle with.
I also do some programming in VHDL using FPGAs, using finite state machines and datapaths. In fact, I memory mapped a whole suite of peripherals into the embedded microcontroller's memory space (ADC, DAC, Stereo output, stereo input, SRAM, PWM, etc). I've even built a pipelined MIPS CPU in VHDL before, from scratch.
Oh yeah, sometimes I also do some host-side programming. I've written a non-plug-and-play kernel mode driver, the kind you can't install with an inf file or "add new hardware". I've written C++ libraries that use known standards like NTP. I've written C# apps that interface with USB microcontrollers.
I even design circuit boards. So I have to know how to interface electrical signals with each other. I know how individual transistors behave together to form logic.
I'm not the best programmer, but trust me, I know how a computer works. I know my way from the transistor up through the managed high level language. I'm one of two developers on a custom remote debugger for reverse engineering and hacking Wii games, so my experience is generalized beyond just x86. I can look through PowerPC assembly and see the game iterating over an array of enemies, evaluating whether they have any damage pending, stuff like that.
I haven't coded a linked list in about 8 years. And I shouldn't have to. There are standard libraries for that, and if you're writing your own linked list, then you're a failure of a programmer in the first place. We learned how to make linked lists in college only so that we knew their strengths and weaknesses [ O(n) traversal, O(1) adding/removing element, etc ], not so we could go on to find jobs writing linked lists.
x86 ASM is horrible on the eyes, so I don't blame you for not wanting to really look at it. Most of my disassembly experience hacking comes from PowerPC (I hack Wii games as a hobby). PowerPC ASM is very easy to read.
However, I would imagine that the exploit should be pretty easy to see from just an ASM dump; it's probably written in ASM as it is, because a compiler wouldn't write good shellcode. Exploits themselves are not terribly complicated, it's the rest of the Duqu architecture that layers the tricks on thick.
This thing has encrypted resources out the wazoo, though. That makes it difficult to read. I hear IDA is a good disassembler for understanding encryption and other obfuscation techniques. But the exploit itself is probably not encrypted.
I doubt they'd be using text input or keypress events. More likely, it's probably some innocuous call, e.g. GetVersionOfWord(LPSTR path). Except that the path variable is strcopied into a stack variable which was only MAX_PATH+1 in length, or something tragic like that.
I'll be the first to admit, I don't really know much about Duqu in particular or what kernel exploit it used. In my head, I imagined a kernel function that took a LPSTR type input and didn't bother checking to see how long it was (classic buffer overflow). It's probably more complicated than that, but ultimately my bet is that the kernel did not sanitize userland inputs very well.
I guess undocumented API call on account of it being unknown. Most of the known API calls would probably have been poked and prodded by now, so that the vuln wouldn't be unknown. All speculation on my part.
The article says kernel exploit. Many user-land calls are wrappers for kernel-land functions. If this was some undocumented API call in Word, then the exploited function might not validate inputs very well.
Uh...what? Users don't have to do anything to the scheduler. That's the responsibility of the operating system. A Service Pack will be released and you won't have to do shit, so your argument is moot.
Besides, if your argument is "We shouldn't have to optimize schedulers", then you're a little late, because schedulers are most definitely optimized for their associated hardware
We still have to open the case to clear CMOS. But you're right, this kinda thing would irritate customers (although it may even create more business for you, since they would need technical assistance when rewriting boot sectors).
And you're also right, you shouldn't be able to write to this stuff from userland. However, malware is pretty good at gaining control of kernelland as well. A userland ban just adds another layer to their payload.
Requiring physical access is likely to be the only real solution that cannot be compromised remotely.
I don't want to criticize you. I just think you should go talk to a real climate scientist, not assholes on the Internet. Assholes on the Internet just give you fuel for straw men fires; the consensus doesn't say the east coast will be underwater by 2050 and so arguing against that belief just makes you look naive. There have also been studies on what to do to mitigate climate change, and it's not really that expensive.
If you go up to real climate scientists with valid scientific criticism (e.g. "the urban heat island introduces a bias into temperature records"), with evidence supporting your hypotheses, they will gladly engage with you and calmly explain the evidence (e.g. "the bias has been accounted for and does not alter the basic trajectory we are on"). Real climate scientists do not use shrill fear-mongering or self-serving hyperbole. Assholes on both sides of the Internet do that.
The images are small enough that you can't see their logos. So how many of those can you tell apart? Can you tell me which ones are manufactured by Westinghouse, just by their visual appearance?
The designs of most older refrigerators have a lot of similarities. The freezer was almost always on top. They almost always opened from the same side. They're typically the same size, with shelves and railings inside. Their user interface (the thermostats) were often numbered from 1-10. In fact, apart from the logo, it's usually quite difficult to tell refrigerators apart.
I see your point. How about deferred bonuses? They can be paid out, say, 24 months after they are "earned". This way, people are only rewarded for long-term success.
I doubt that it's possible to add progressive scan to a game using normal hacks. But you're welcome to join the wiird forums and create a request in the support area.
If the problem is no corresponding disincentive for failure, it doesn't make sense to remove the incentive for success.
Instead, should unwarranted bonuses be given that later turn out to be fraudulent, the bonuses should be clawed back. Perhaps add a penalty of 50% of the bonus on top of clawing back the full bonus.
The Israeli government is not losing support because they are Jews. They are losing support because of their actions.
We have a President who thinks his life would be a lot easier if the Israeli government would stop pissing off the international community with shit like the settlements. Then he wouldn't have to tell his ambassadors to exercise their Security Council veto every time the Israeli government engages in an international faux pas.
Regarding your last point, however, I'm inclined to agree. Look at how quickly the US turned on Gaddafi. Our loyalty does not run deep at all. Not that we should have had any loyalty with Gaddafi to begin with...
I wish my bank would automatically take the right amount from checking. I have to log in once a month to do it. But that's a good thing, because it allows me to keep an eye on my account for fraudulent purchases.
The fact that you have forgotten
Wow, that's quite presumptuous of you. I didn't say I forgot how to do it, I said I shouldn't have to do it. And I don't know where this managed language thing came from, I never even told you what languages I've used. But if you really want to get into some kinda pissing match, then I shall whip out the credentials.
For the record, most of my actual programming is done in C, usually with an embedded compiler. It's the kind of programming that requires you to have a spare monitor just for datasheets, so that you can see what CPU register bits you need to fiddle with.
I also do some programming in VHDL using FPGAs, using finite state machines and datapaths. In fact, I memory mapped a whole suite of peripherals into the embedded microcontroller's memory space (ADC, DAC, Stereo output, stereo input, SRAM, PWM, etc). I've even built a pipelined MIPS CPU in VHDL before, from scratch.
Oh yeah, sometimes I also do some host-side programming. I've written a non-plug-and-play kernel mode driver, the kind you can't install with an inf file or "add new hardware". I've written C++ libraries that use known standards like NTP. I've written C# apps that interface with USB microcontrollers.
I even design circuit boards. So I have to know how to interface electrical signals with each other. I know how individual transistors behave together to form logic.
I'm not the best programmer, but trust me, I know how a computer works. I know my way from the transistor up through the managed high level language. I'm one of two developers on a custom remote debugger for reverse engineering and hacking Wii games, so my experience is generalized beyond just x86. I can look through PowerPC assembly and see the game iterating over an array of enemies, evaluating whether they have any damage pending, stuff like that.
I haven't coded a linked list in about 8 years. And I shouldn't have to. There are standard libraries for that, and if you're writing your own linked list, then you're a failure of a programmer in the first place. We learned how to make linked lists in college only so that we knew their strengths and weaknesses [ O(n) traversal, O(1) adding/removing element, etc ], not so we could go on to find jobs writing linked lists.
Wii Bone, a sequel to the critically acclaimed We Dare title from Ubisoft. No, I am not joking.
x86 ASM is horrible on the eyes, so I don't blame you for not wanting to really look at it. Most of my disassembly experience hacking comes from PowerPC (I hack Wii games as a hobby). PowerPC ASM is very easy to read.
However, I would imagine that the exploit should be pretty easy to see from just an ASM dump; it's probably written in ASM as it is, because a compiler wouldn't write good shellcode. Exploits themselves are not terribly complicated, it's the rest of the Duqu architecture that layers the tricks on thick.
This thing has encrypted resources out the wazoo, though. That makes it difficult to read. I hear IDA is a good disassembler for understanding encryption and other obfuscation techniques. But the exploit itself is probably not encrypted.
I doubt they'd be using text input or keypress events. More likely, it's probably some innocuous call, e.g. GetVersionOfWord(LPSTR path). Except that the path variable is strcopied into a stack variable which was only MAX_PATH+1 in length, or something tragic like that.
I'll be the first to admit, I don't really know much about Duqu in particular or what kernel exploit it used. In my head, I imagined a kernel function that took a LPSTR type input and didn't bother checking to see how long it was (classic buffer overflow). It's probably more complicated than that, but ultimately my bet is that the kernel did not sanitize userland inputs very well.
I guess undocumented API call on account of it being unknown. Most of the known API calls would probably have been poked and prodded by now, so that the vuln wouldn't be unknown. All speculation on my part.
Give the outside consultant VPN access to a restricted share.
Another attack vector is plug-and-play drivers. For instance, the PS3 jailbreak exploited the USB driver. That's not coming from userland.
The article says kernel exploit. Many user-land calls are wrappers for kernel-land functions. If this was some undocumented API call in Word, then the exploited function might not validate inputs very well.
Instead of using email attachments, make it company policy to drop the attachments on a network drive, and instead share intranet links.
Anyone who spear phishes with attachments will fail. Now they will need intranet access, which can be significantly harder to acquire.
Will the end user have to do esoteric tweaks after the next Service Pack for Windows? Nope.
Uh...what? Users don't have to do anything to the scheduler. That's the responsibility of the operating system. A Service Pack will be released and you won't have to do shit, so your argument is moot.
Besides, if your argument is "We shouldn't have to optimize schedulers", then you're a little late, because schedulers are most definitely optimized for their associated hardware
Yeah, who would have ever thought something like herd immunity would be sensible...
We still have to open the case to clear CMOS. But you're right, this kinda thing would irritate customers (although it may even create more business for you, since they would need technical assistance when rewriting boot sectors).
And you're also right, you shouldn't be able to write to this stuff from userland. However, malware is pretty good at gaining control of kernelland as well. A userland ban just adds another layer to their payload.
Requiring physical access is likely to be the only real solution that cannot be compromised remotely.
For real protection, it can't be based in software. It must be a physical switch, like that on floppy disks or SD cards.
The WHO said that cell phones have a cancer risk similar to drinking coffee. Hardly an alarm.
I don't want to criticize you. I just think you should go talk to a real climate scientist, not assholes on the Internet. Assholes on the Internet just give you fuel for straw men fires; the consensus doesn't say the east coast will be underwater by 2050 and so arguing against that belief just makes you look naive. There have also been studies on what to do to mitigate climate change, and it's not really that expensive.
If you go up to real climate scientists with valid scientific criticism (e.g. "the urban heat island introduces a bias into temperature records"), with evidence supporting your hypotheses, they will gladly engage with you and calmly explain the evidence (e.g. "the bias has been accounted for and does not alter the basic trajectory we are on"). Real climate scientists do not use shrill fear-mongering or self-serving hyperbole. Assholes on both sides of the Internet do that.
I was thinking more along the lines of Google Image Search for white refrigerator.
http://www.google.com/search?q=white+refrigerator&tbm=isch
The images are small enough that you can't see their logos. So how many of those can you tell apart? Can you tell me which ones are manufactured by Westinghouse, just by their visual appearance?
The designs of most older refrigerators have a lot of similarities. The freezer was almost always on top. They almost always opened from the same side. They're typically the same size, with shelves and railings inside. Their user interface (the thermostats) were often numbered from 1-10. In fact, apart from the logo, it's usually quite difficult to tell refrigerators apart.
Find any two white refrigerators of the same size. Remove their logos. Tell them apart at 10 feet away.
Are you one of the lawyers for Apple by chance?
Okay.
http://www.samsung.com/global/microsite/galaxytab/10.1/images.html
Not much of a difference. I still see SAMSUNG clearly emblazoned on both the front and back of the device.