Comment Re:AGAIN? (Score 3, Insightful) 417
You have clients
You have clients
Even if Windows were running on bare hardware I could play tricks with the clock, I could hide memory from any program that Blizzard could come up with to attempt to scan regions of memory, I still could pull all of the tricks you just mentioned. How? Using good ol' virtualisation extensions that exist within processors.
Not only that but I own the hardware, I have physical access to the hardware, there is no good way for any program to insert itself at a higher level. I control the boot process so I get to choose where the OS is loaded, I get to change the way it works and interacts. Writing kernel level modules that tamper with time like you are suggesting that would be simple with Wine are entirely possible using straight Windows as well.
Thats the biggest problem, Blizzard doesn't own, they don't manufacture and they can't guarantee that no-one has tampered with the hardware. There comes a point where the software is running on top of the hardware and it has to trust that the hardware is not being malicious. This is how cable box hacks, and satellite box hacks used to work.
Blizzard can write a root kit all they want, if people want to cheat and if there is enough incentive to do so people will find ways to defeat the rootkits behaviour and cheat. Until everything is sent over an RDP like protocol and no code executes client side this is a problem that is going to exist for the foreseeable future.
This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.
http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587
Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.
If the device/board already has 120v coming in on it, then having a device keep its time from AC is rather simple. One zener diode, a resistor and an open pin on a microcontroller are all that are required.
Take a look at some zero cross detection circuits, they are extremely simple, and the parts for them are cheaper than for a crystal that is accurate at time keeping when the power companies keep the 60 Hz in sync.
I've got a MacBook Pro. It's going on year 5 at the moment. No issues with the hard drive.
Whisper Systems is an US based company that has never provided user data to Egypts government, nor has it allowed them to send messages through their system. You are thinking about Vodafone which was forced to do so by the government.
I am probably missing something funny here. Egypt did not remove their top-level domain entries, that wouldn't accomplish anything. Egypt stopped announcing their ASN, and thus all of the routes for their assigned IP addresses.
Removing just the top-level domain would still allow people to use IP addresses to communicate over the network, and would still allow outgoing traffic as well.
You can do NAT on an IPv6 connection the same way you are doing NAT on IPv4. Also, instead of using NAT to protect resources you should be using a border firewall that has the same rules for IPv6 as you have for your IPv4. That way from the outside even if they scan one of your IP addresses it still has the proper ports closed.
Assign internal IPv6 addresses to your network, and then NAT on those. Simple.
Whatever gateway you have that is doing route advertisements for IPv6 is still the primary location for firewalling, and is still your single point in and out of your network.
What functionality are we BSD users going to be missing? It didn't really say in the article at all other than that apparently there is a lot of Linux only stuff out there in the open source world. As a developer I am saddened by this fact, that what I have available for use on Linux won't work the same on FreeBSD for example making my life as a developer and porter much harder.
Where does the problem lie? Is it in the library developers or in the OS developers? What can be done to change the situation? Where are some places we can start looking?
I drive a manual car, and as such my hands are almost NEVER both on my steering wheel. Should my GPS still be disabled when there is a passenger in the car? How is it supposed to know that there is a passenger in the car since I now don't have both hands on the steering wheel?
And don't tell me that my stick shift is part of the problem. I am more attentive to the road for one particular reason, I can't just have the car take care of shifting for me, I have to be involved in what my car is doing, how fast I am going, what the RPM's are of my engine so I don't blow it up, because of that I need to pay attention to the road, I need to watch other cars to know to slow down, when I can shift into a higher gear, when I need to down shift, I need to watch the road for any inclination so I can appropriately shift into the various different gears.
Because of driving a stick shift I would say I am better prepared to multi tasking within my car and still operating it safely more so than others.
Why doesn't this have more points? I wish I had mod points just to set the record straight!
Good luck to you guys!
Something like http://www.tinyclr.com/ is actually pretty cool, having used it, yes the 72 Mhz chip feels a little slow compared to using it more directly using C.
Microsoft has also updated many of the libraries, so it is easier to do various different tasks at the same time, however there are still a lot of steps involved in writing code for something like the FEZ domino, I could definitely understand that it is harder, yet at the same time Visual Studio is an absolutely awesome development environment that is not yet matched on Mac OS X or Linux.
No, and the amateurs that are playing with the Arduino and Basic stamp are not going to use
Depends on the engine. My engine will not provide enough power while in idle so that I stay in the same place on a steep incline. I use the handbrake. Pull up the handbrake, move foot from brake pedal to gas pedal, slowly let the clutch up, give it a little gas and when I feel it starting to move let go of the hand brake.
Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.
Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.
I agree with you, don't put all the blame on me as a programmer.
Oh, if I had mod points, you sir would have them!
Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.
