This isn't any different than the way Steam works right now...
I never said I agree with how Steam does it. In some ways, this is different from Steam (which is currently a primarily PC-based service) in a cultural way.
For the sake of argument let's only focus on activities done within the bounds of the law. In the console world part of the common culture is sharing, trading, and re-selling games. Not everyone does it but it's commonplace. (Sure, it happens with PC games (maybe not so much reselling) but my impression is that it's never been nearly as common as with consoles.) Moreover, console gaming has always been a place where two or more people can sit in front of the same machine to play together, something that PC games rarely do. Does this new model mean that when my friends come over to play Rock Band or Mario Kart they all have to ante up to the game publishers first?
It's more as if the console manufacturers and publishers are trying to change console gaming culture in the name of profit. This is certainly great for their bottom line in theory, but much of the console community is understandably upset.
But I reserve the right to hack into your image recognition software and replace my face with some other image of my choosing, Ghost in the Shell style.
That's truly an interesting concept. You may have the right to record everything around you but I have the right to forcibly alter my own image by gaining access to your systems, encrypted or not. Or perhaps we could extend that to "alter or delete any information about me."
Takeoff and landing, you're supposed to concentrate on safety instructions which (very rarely) you might need to think about right soon and seriously. Just... put down the gadget for a moment, and join the real and dangerous world of the paid staff.
Then why are non-electronic devices, such as books and magazines, allowed during said safety briefing?
Okay, fair enough: Migrate her to the platform(s) you are most comfortable supporting and/or use at home. "But, but..." Give your mother some credit - she will adapt.
This is exactly the reason I plan to migrate the machine to Windows 7. I have a hard time remembering what things are called in XP anymore since I use Windows 7 at home and at work. True I could load up XP Mode and figure it out, but it's also time to move to something newer and more secure.
He's not willing to do that due to the time involved.
He is likely to have to spend far more time re-training on Linux than just fixing the problems via remote log in.
These are big reasons why I say Linux is not an option. The other significant one is that I'm no Linux guru myself. While I'd certainly like to learn more and this is a great opportunity to do so, I just don't have the time in my life right now.
To the article submitter, what does your mom use AOL for? The AOL experience isn't necessarily much different than the browser experience, for certain activities, so you might want to try setting up Windows 7 and then seeing if the browser is "close enough"..
I think she just uses AOL because it's what she is used to and what we used in our house literally 20 years ago. You're absolutely right about the browser experience. Trying to make it a replacement seems like a good option.
All good points and very doable. Understand that it will take you at least five years to do this.
To be fair, it's becoming more common for the "4-year" Bachelor's degree to take five or more years anyway, at least with engineering.
Honestly, you know what this says? This just says some programmers still need to go practice in the threading space.
. .
Seriously. If threading seems that hard, you need to go do some studying. It's not the threading. It's you. You really should get on this bus.
That's true. Threading concepts aren't hard, they're just not as widely taught as they should be. In my computer/software engineering education, I can't recall any required classes that really put a focus on developing multi-threaded applications.Operating Systems took a look at some of the issues associated with multi-tasking and thus multi-threaded programming, but it didn't really go so far as to force you to develop complex applications that put such lessons into practice.
The real issue is that debugging your multi-threaded application can be difficult and becomes more difficult as your application becomes more complex, requiring more and more threads. Maybe that's not hard if all your threads are doing exactly the same thing, but if they're all heterogeneous then it becomes tough. How do you know what caused this dead-lock or that crash? Why does it only happen sometimes and not others? Why did adding this line of code here break all the other threads? It's not an easy problem to solve and requires either better tools (that don't exist yet) or a lot of experience to get a feel for where to look and what to do (or not do).
Then again, some problem spaces lend themselves very well to multiple core approaches -- I just finished a library that slices up images and then applies various separable algorithms to the slices in a variable number of threads (the user of the library can specify.) I wrote it in pure C, used posix threads, no sweat at all, in my 8-core machine, you get just about exactly the gains you'd think (x the number of cores) when the process is CPU cycle intensive, less as the ops are simpler and memory I/O rates rise.
If you are trying to accomplish the same amount of work in a shorter amount of time, Amdahl's Law calls you a liar. If, on the other hand, you're trying to do more work in the same amount of time, then Gustafson's Law agrees with you but you will still NEVER get a speedup of N by adding N cores; it will always be somewhat less than N.
The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra
