In fairness, "Harry Potter" isn't capitalizing on the horsepower of the Wii. It's basically just a PS2 game ported over with new controls. "The Wii's graphics are good enough"-argument applies to games like Twilight Princess, Mario Galaxy, and other Nintendo titles that use the power of the Wii well. I'd even count Wii Sports in that category: although primitive, the graphics still get the job done without being distracting.
People do this in dictionaries, not encyclopedias. In dictionaries, they introduce plausible sounding nonsense words, to see if anyone copies the word into their own dictionary without checking first to see if it comes up in old texts. If the word does get into another dictionary, it means that they add words without fully vetting them and producing original definitions based on the vetting process. There's no danger of causing serious harm by doing this, since in the worst case, someone believes that a nonsense word has been used by a few people before when in fact it hasn't been used before. However, it wouldn't make sense to add errors of the sort described here to an encyclopedia. It would have a serious chance of misleading people, and it would be more likely to discredit the source encyclopedia than any of their competitors.
I accept that it's not perfect, but is there a better way in sight? Maybe if you could make something like Erlang popular, parallel computing might go somewhere in the future, but it would be really hard to retrain all the Blub programmers in the world. What do you think should be done?
Apple has announced that they're adding an API to OS 10.5 to make it easier to do parallel operations on a data set without getting bogged down in all the problems that come from multi-threading and whatnot:
NSOperation [is] a breakthrough new API that optimizes applications for the world of multicore processing. Independent chunks of computation (operations) are added to an NSOperationQueue, which dynamically determines how many operations to run in parallel based on the current architectures. So there's no need to hand-code the complexities of threading and locking. You simply describe the operations in a program along with their dependencies. Cocoa takes care of the rest.
"And given that Itunes and other system software is installed by the privileged user, there's no graceful way to prevent such software from hogging more privileges than it needs, right?"
No, that's not it at all. We're clearly having some sort of failure of communication. The proposal is that the system is changed. Today, a typical machine looks like this:
Root: Can do anything.
Admin user: Can do anything if they enter their password first and elevate to root. Otherwise can only use files set for their user/group.
Normal user: Like an admin user, but can't elevate permissions as needed.
Restricted user: Can only run a few things as whitelisted by another, more powerful user.
My proposal would add sub-restriction underneath the permissions of individual users. The first time you ever launch an application, you'll be asked to specify whether it gets "Minimium", "Normal", "Trusted", or "Custom" permissions. After that, the system will remember the permissions set for that application and if the same user requests to launch it, it will be loaded with the specified level of permissions. "Minimum" means a system can only read/write files in its own folder, and it cannot read any other folders, except the system folders needed for API access, etc. "Normal" means it can only write to its own area and a common downloads folder, but it can read the same files that the current user can read. "Trusted" means it can read or write anything that the current user can. "Custom" means custom. Of course, applications can request temporary elevation of their privileges from time to time, eg. Firefox is always run as "Minimum" for safety reasons, but you let it read your files for a little while when you want to upload stuff. Privileges should also be able to be set in the file browser, which for obvious reasons will have "Trusted" privileges.
This system would require a lot of deep kernel hooks to make it smooth (or you can just fake it with an assload of ACLs), but the GUI end of it would be almost as important, since it needs to ensure that users don't just set everything to "Trusted" when the spyware they download tells them to. You can also imagine various minor niceties like saying, "Oh, application X is associated with.XYZ files, so X will be allowed to read/write any XYZ files of this user." That shouldn't be set by the application though, but when you first try to open an.XYZ file, the shell should say, "Right now, there's no app associated with XYZ files, but X claims it can read them. Should I allow that?" If the user says OK, then it should ask, "Well, how about I let it read/write all of your XYZ files, is that, OK?"
Anyhow, you can imagine more details, but the point is to re-write everything so that A) the user has absolute control over the privileges of every app and B) the user doesn't feel the need to set every app to "Trusted" since the system is intelligent and unobtrusive enough to have sensible defaults and easy to understand dialogues.
Ah. I'm working under the assumption that UAC is just a broken version of what Apple's been doing for user authorization since 10.0. Basically, they made a pretty version of sudo. I haven't actually played with it yet, just read a little about it.
No, UAC is quite different from my proposal. In UAC, if I want to use certain restricted files, I have to tell Windows, "Let me user these files" every time I want to use them. Basically, what it does it get you to allow it to launch your app as a user with more permissions than usual. Once the app closes, the permissions are gone because the next time you launch the app, it will be as your weakened user not as your strengthened user, and so you can't touch the files again without elevating the app again.
What I am proposing is quite different. Instead you would say, eg. "Explorer can mess with any files, but RandomP2PAppFromWeb.exe can only mess with its own files." After you set it, those applications would *always* have those same permissions whenever your user launches them until the settings are changed by a super user. No recurring dialog boxes involved.
In my version of events, you as user set the permissions for applications. Applications do not set their own permissions. Accordingly, iTunes or whatever will not be able to mark its files as "only iTunes may read this." ITunes will have no choice about the permissions it gets. Those permissions will be set by the user and iTunes will be forced by the kernel to respect them.
Hey, it's time for me to bring out my rant against current Unix/Windows permissions systems! Whee.
OK, here's the short version: it's good that files on modern OS have access restricted to certain users, but that's not nearly enough. Instead access to files should be further restricted by process so that eg. Firefox only has permission to read/write to its cache, bookmarks, and download folders and that's it. If you need to upload, it should be forced to use a common API to beg the user for permission to even view uploadable files. Why? Well, exactly to stop this sort of exploit where a trojan promises to do something useful, but actually searches (using fancy new Spotlight and Windows Search, no less!) for files called "my CC#s" to send back to the mothership.
In other words, I think we should Sandbox Everything.
Apparently, SE Linux is trying to do something like this, but OS vendors need to find a way to make this whole process seamless and easy, so that I can right click on an application, go to permissions, and say, "This program I will allow to read my home directory, but only write to its own directories; that one I will let write anywhere, but read only itself" and so on.
It will be really hard to implement this in a user friendly way, but it is clearly the necessary next step in computer security. Apple, Microsoft, and (consumer oriented) Linux devs should start working on this now.
I liked Elebits right up until the final boss, which was so irritating it retroactively made me dislike earlier parts of the game.
If you play Elebits, throughout the game you'll find various knobs that need to be turned like door handles and sinks. You'll also notice that the knob turning code is almost completely broken. It is impossible to turn a knob without causing your camera to spaz out and end up pointing at the ceiling. But it's mostly no big deal, because there are only ever one or two doors or sinks that need to be turned in a level and fixing your camera doesn't take that long.
So, what did they do for the final boss? They basically made a giant, cheap ass knob that needs to be turned a lot before it hits you with a cheap death.
What the hell? Were the developers paying any attention to their own game at all? Did they not notice that knob turning is the absolute worst part of the whole game and completely broken? Why would you make the worst part of your game into the final challenge? It would be like if in the final level of Mario 64 you have to keep your camera on Mario in a narrow space. It's re-freaking-tarded ass design.
Ughhhh.
My advice is you should buy Elebits but never, ever play the final boss. Doing so will just make you dislike what you liked in the game before and sour you on Konami.
I imagine DNA is like Lisp with a GOTO statement. There's no separating the "data" from the "program," things jump around at random, the times when they don't jump randomly they end doing stuff like doubling back and re-executing the last 10 base-pairs, then last 9-base pairs, etc., as a weird form of compression, and every sequence is double redundant in case of damage, but triple obfuscated as well.
Sooo, at least Bush hasn't done that, yet.... But speaking seriously, in order to prevent America from becoming like non-Soviet Russia, we must watch carefully what reforms are suggested in this case.
It's called "marketing." Why do you think iTunes for Windows looks the way it does?
Also, I can't tell, but it seems like your message is implying that you believe Safari uses XUL or some other Mozilla based skin settings. It doesn't. Safari = Konqueror's KHTML engine wrapped in WebKit frameworks + Stuff that makes it look like a Mac app. There's no Mozilla anything involved. (Or maybe I'm misreading you?)
In Safari, you don't type ctrl-enter to type www.*.com. You just type the name of the website and Safari is smart enough to figure out that you wanted.com on it's own.
I know you're just joking around, but actually in the Old Testament's Book of Job, Job all but "sues" God for his terrible treatment by the hand of fate. In the end of the book, God comes down, tells Job that it isn't his place to judge God, but nevertheless forgives him and gives him back his health and wealth.
There are a lot of different interpretations of the moral of the book, but the one I prefer is that we have every right to be upset with God for the miseries of life, but we also have to remember that God has His own particular concerns in running the world such that while He will set things right eventually we cannot expect this life to be without its trials or pain...
Anyhow, so sometimes you can get away with suing the OT God.
When you wrote \"i you used three bytes (assuming an ASCII-style one byte per character encoding) to represent one character. In contrast, Unicode represents ï as codepoint x00EF, which in UTF-8 ends up as two bytes, x00C3 and x00AF.
You should amend your quote to "you can represent English in 7-bits... just so long as you're willing to use more than 7-bits to do it."
Slashdot Mirror
What ever happened to As Seen On TV?
Yes, you are trolling because the Wii uses a RISC architecture, which means its CPU Mhz is not comparable to other CISC CPUs.
Is the Wii in the same ballpark powerwise as the 360 or the PS3? No.
Is it hella better than the numbers suggestion? Yes.
Is it "good enough"? If developers do their job, then yes. If they just port stuff from the PS2, then no.
In fairness, "Harry Potter" isn't capitalizing on the horsepower of the Wii. It's basically just a PS2 game ported over with new controls. "The Wii's graphics are good enough"-argument applies to games like Twilight Princess, Mario Galaxy, and other Nintendo titles that use the power of the Wii well. I'd even count Wii Sports in that category: although primitive, the graphics still get the job done without being distracting.
People do this in dictionaries, not encyclopedias. In dictionaries, they introduce plausible sounding nonsense words, to see if anyone copies the word into their own dictionary without checking first to see if it comes up in old texts. If the word does get into another dictionary, it means that they add words without fully vetting them and producing original definitions based on the vetting process. There's no danger of causing serious harm by doing this, since in the worst case, someone believes that a nonsense word has been used by a few people before when in fact it hasn't been used before. However, it wouldn't make sense to add errors of the sort described here to an encyclopedia. It would have a serious chance of misleading people, and it would be more likely to discredit the source encyclopedia than any of their competitors.
I accept that it's not perfect, but is there a better way in sight? Maybe if you could make something like Erlang popular, parallel computing might go somewhere in the future, but it would be really hard to retrain all the Blub programmers in the world. What do you think should be done?
I wouldn't say I put much effort into this. Copy, paste, add a couple bullet points, et viola.
Allow me to add one more bullet:
Anyone have a guess about tomorrow's headline?...
That's good. Now they just need to polish it until it's good enough to be included and turned on in the default installations of Unbuntu et al.
"And given that Itunes and other system software is installed by the privileged user, there's no graceful way to prevent such software from hogging more privileges than it needs, right?"
.XYZ files, so X will be allowed to read/write any XYZ files of this user." That shouldn't be set by the application though, but when you first try to open an .XYZ file, the shell should say, "Right now, there's no app associated with XYZ files, but X claims it can read them. Should I allow that?" If the user says OK, then it should ask, "Well, how about I let it read/write all of your XYZ files, is that, OK?"
No, that's not it at all. We're clearly having some sort of failure of communication. The proposal is that the system is changed. Today, a typical machine looks like this:
Root: Can do anything.
Admin user: Can do anything if they enter their password first and elevate to root. Otherwise can only use files set for their user/group.
Normal user: Like an admin user, but can't elevate permissions as needed.
Restricted user: Can only run a few things as whitelisted by another, more powerful user.
My proposal would add sub-restriction underneath the permissions of individual users. The first time you ever launch an application, you'll be asked to specify whether it gets "Minimium", "Normal", "Trusted", or "Custom" permissions. After that, the system will remember the permissions set for that application and if the same user requests to launch it, it will be loaded with the specified level of permissions. "Minimum" means a system can only read/write files in its own folder, and it cannot read any other folders, except the system folders needed for API access, etc. "Normal" means it can only write to its own area and a common downloads folder, but it can read the same files that the current user can read. "Trusted" means it can read or write anything that the current user can. "Custom" means custom. Of course, applications can request temporary elevation of their privileges from time to time, eg. Firefox is always run as "Minimum" for safety reasons, but you let it read your files for a little while when you want to upload stuff. Privileges should also be able to be set in the file browser, which for obvious reasons will have "Trusted" privileges.
This system would require a lot of deep kernel hooks to make it smooth (or you can just fake it with an assload of ACLs), but the GUI end of it would be almost as important, since it needs to ensure that users don't just set everything to "Trusted" when the spyware they download tells them to. You can also imagine various minor niceties like saying, "Oh, application X is associated with
Anyhow, you can imagine more details, but the point is to re-write everything so that A) the user has absolute control over the privileges of every app and B) the user doesn't feel the need to set every app to "Trusted" since the system is intelligent and unobtrusive enough to have sensible defaults and easy to understand dialogues.
Ah. I'm working under the assumption that UAC is just a broken version of what Apple's been doing for user authorization since 10.0. Basically, they made a pretty version of sudo. I haven't actually played with it yet, just read a little about it.
Thank you. I'm glad someone understands what I'm proposing. If you weren't AC, I add you as to my friends list.
No, UAC is quite different from my proposal. In UAC, if I want to use certain restricted files, I have to tell Windows, "Let me user these files" every time I want to use them. Basically, what it does it get you to allow it to launch your app as a user with more permissions than usual. Once the app closes, the permissions are gone because the next time you launch the app, it will be as your weakened user not as your strengthened user, and so you can't touch the files again without elevating the app again.
What I am proposing is quite different. Instead you would say, eg. "Explorer can mess with any files, but RandomP2PAppFromWeb.exe can only mess with its own files." After you set it, those applications would *always* have those same permissions whenever your user launches them until the settings are changed by a super user. No recurring dialog boxes involved.
In my version of events, you as user set the permissions for applications. Applications do not set their own permissions. Accordingly, iTunes or whatever will not be able to mark its files as "only iTunes may read this." ITunes will have no choice about the permissions it gets. Those permissions will be set by the user and iTunes will be forced by the kernel to respect them.
This is the absolute opposite of DRM.
Hey, it's time for me to bring out my rant against current Unix/Windows permissions systems! Whee.
OK, here's the short version: it's good that files on modern OS have access restricted to certain users, but that's not nearly enough. Instead access to files should be further restricted by process so that eg. Firefox only has permission to read/write to its cache, bookmarks, and download folders and that's it. If you need to upload, it should be forced to use a common API to beg the user for permission to even view uploadable files. Why? Well, exactly to stop this sort of exploit where a trojan promises to do something useful, but actually searches (using fancy new Spotlight and Windows Search, no less!) for files called "my CC#s" to send back to the mothership.
In other words, I think we should Sandbox Everything.
Apparently, SE Linux is trying to do something like this, but OS vendors need to find a way to make this whole process seamless and easy, so that I can right click on an application, go to permissions, and say, "This program I will allow to read my home directory, but only write to its own directories; that one I will let write anywhere, but read only itself" and so on.
It will be really hard to implement this in a user friendly way, but it is clearly the necessary next step in computer security. Apple, Microsoft, and (consumer oriented) Linux devs should start working on this now.
I liked Elebits right up until the final boss, which was so irritating it retroactively made me dislike earlier parts of the game.
If you play Elebits, throughout the game you'll find various knobs that need to be turned like door handles and sinks. You'll also notice that the knob turning code is almost completely broken. It is impossible to turn a knob without causing your camera to spaz out and end up pointing at the ceiling. But it's mostly no big deal, because there are only ever one or two doors or sinks that need to be turned in a level and fixing your camera doesn't take that long.
So, what did they do for the final boss? They basically made a giant, cheap ass knob that needs to be turned a lot before it hits you with a cheap death.
What the hell? Were the developers paying any attention to their own game at all? Did they not notice that knob turning is the absolute worst part of the whole game and completely broken? Why would you make the worst part of your game into the final challenge? It would be like if in the final level of Mario 64 you have to keep your camera on Mario in a narrow space. It's re-freaking-tarded ass design.
Ughhhh.
My advice is you should buy Elebits but never, ever play the final boss. Doing so will just make you dislike what you liked in the game before and sour you on Konami.
I imagine DNA is like Lisp with a GOTO statement. There's no separating the "data" from the "program," things jump around at random, the times when they don't jump randomly they end doing stuff like doubling back and re-executing the last 10 base-pairs, then last 9-base pairs, etc., as a weird form of compression, and every sequence is double redundant in case of damage, but triple obfuscated as well.
Good luck! Let us know how it goes!
fucking hell, you mean God wrote our DNA in Perl?!
We've known this for a while.
After a school in Russia was attacked by terrorists in 2004, Putin announced he would implement measures that would directly prevent another such tragedy from occurring: He changed election laws so that he would appoint regional governors directly instead of letting people vote for them! Problem solved?
... But speaking seriously, in order to prevent America from becoming like non-Soviet Russia, we must watch carefully what reforms are suggested in this case.
Sooo, at least Bush hasn't done that, yet.
It's called "marketing." Why do you think iTunes for Windows looks the way it does?
Also, I can't tell, but it seems like your message is implying that you believe Safari uses XUL or some other Mozilla based skin settings. It doesn't. Safari = Konqueror's KHTML engine wrapped in WebKit frameworks + Stuff that makes it look like a Mac app. There's no Mozilla anything involved. (Or maybe I'm misreading you?)
Don't listen to the haters. I appreciated the joke.
In Safari, you don't type ctrl-enter to type www.*.com. You just type the name of the website and Safari is smart enough to figure out that you wanted .com on it's own.
I tried to get first post in the comments, but it costs $600! :-( At that rate, I'm not going to bother until they post on Metal Gear or GTA at least.
I know you're just joking around, but actually in the Old Testament's Book of Job, Job all but "sues" God for his terrible treatment by the hand of fate. In the end of the book, God comes down, tells Job that it isn't his place to judge God, but nevertheless forgives him and gives him back his health and wealth.
There are a lot of different interpretations of the moral of the book, but the one I prefer is that we have every right to be upset with God for the miseries of life, but we also have to remember that God has His own particular concerns in running the world such that while He will set things right eventually we cannot expect this life to be without its trials or pain...
Anyhow, so sometimes you can get away with suing the OT God.
When you wrote \"i you used three bytes (assuming an ASCII-style one byte per character encoding) to represent one character. In contrast, Unicode represents ï as codepoint x00EF, which in UTF-8 ends up as two bytes, x00C3 and x00AF.
You should amend your quote to "you can represent English in 7-bits... just so long as you're willing to use more than 7-bits to do it."