That's a funny song, but of course in practice your mother is always the person who gave birth to you and your father is always the person who contributed the sperm to fertilise her egg, regardless of marriage. Given the events in the song, you'd be a step-grandfather at best, and since society doesn't consider "step-grandfather" to be a meaningful family relationship, you're really just a person with a dad who was strange enough to wed your wife's daughter. Or something.
In the first case, presumably you'd know that your mother got shot at when she was younger, since something that traumatic would certainly be memorable. You'd also know that the shooter missed. You wouldn't know that the shooter was you, but it might later give you the inspiration to try to shoot your mother in the past. If you'd never been told that someone tried to shoot your mother, you might not have thought of trying in the first place.
Your actions when you went back in time would inspire your actions in "the present", causing the actions when you went back in time. Sounds like a fun little paradox!
I'm guessing that the reason they called it "JavaScript" was that in the early days it was used as little more than a glue language between HTML forms and embedded Java applets. JavaScript in Netscape was able to connect into the JVM and call methods on applets, and other such interesting things. The name comes from it being "a scripting language for Java", not "a scripting language based on Java".
Of course, I have no actual insider knowledge. This just seems like the most likely reason based on how JavaScript was set up back in the early implementations, before all this crazy DHTML stuff came along.
I've not yet looked at the code to find out if it's written cleanly enough for this, but theoretically someone could use an out-of-browser JavaScript interpreter and a replacement terminal part to make it talk over a socket, telnet-style. Then you could run it as a daemon and forget it's written in JavaScript...
If you were really crazy, you could even figure out how to make it support multiple concurrent terminals, run it as init (with an appropriate wrapper+js-interpreter written in C) on a system with the Linux kernel installed and have it bind to all of the local ttys and a provide a telnet server. You'd still have a kernel running atop a kernel, but in all other respects JS/UIX would be your operating system.
Neither of those are particularly useful, but would be kinda neat.:)
Of course, once one of your bridges is erected and in service it will never need to be replaced nor maintained. The market for bridges will dry up. This, I think, is one of the flaws in this model of selling items in these game worlds.
When I buy a t-shirt, 10-15 years later it's quite likely to have deteriorated to the point where it is no longer able to perform its job well. Likewise a car, or indeed a bridge, though each with a different average lifespan. Real items get broken, lost or even just worn out. When I buy a "car" in Second Life, I own and can use that car. That car will work forever and the game (presumably) makes it quite hard for me to lose it. Assuming no artificial barriers are erected to prevent it, there's no technical or physical reason why I can't duplicate and resell copies of that car.
The economy in these worlds is driven by novelty. The only reason I'd buy a new car is because the creator has done something wacky that can't be done by my existing car purchases. Eventually a point will be reached where no more innovations are possible, because all of these virtual worlds have their limits. I understand that Second Life's are less limiting than most, but given that it's been going for a few years now I'd expect that players have done just about everything that can be done with cars. Once there is no more room for novelty, there will be no point in buying anything. Everyone will own everything they could possibly want, and have no reason to replace any of it. The "exchange rate" beween their in-game currency and real-world currencies will suffer. Items will be so widespread that there is no scarsity to warrant non-trivial prices.
I hope no-one that is currently drawing a wage out of their activities in Second Life is relying on that lasting.
I can't help but wonder what would happen if someone were to run alongside one of these trucks in line with the sensors and just leap around. Would they then end up with just a big, smeared, stretched out person rather than the city?
I could imagine that one group might be a development house which has software targetting both Windows and MacOS. Eventually they'll be testing the software on a real Mac, but it'd sure be cheaper if all of the programmers could just run commoditty PC hardware and emulate a Mac well enough to do their testing alongside the Windows versions.
Of course, the fact that it'll be illegal might put them off a little.
It does, however, mean that Wine no longer needs an x86 emulator embedded in it in order to be ported to OS X. I expect that once x86 Macs are commonplace (assuming that it is really x86 that Apple is going for) it won't take long for Wine to be ported first to use X under OS X and hopefully latter to target the OS X window API directly. This would leave older users with PPC machines out of luck, of course.
Porting Winelib would, in theory, allow Windows apps to be built to target a PPC version of Winelib and thus allow PPC users to enjoy the software too, of course. I have a feeling, though, that most Mac users would rather suffer in a world of no software than run an ugly Windows application on their beautiful Mac desktops.
Years ago when my connection was unreliable I routinely used a tool called PKZipFix which would fix a partial ZIP archive to allow you to retrieve any contained files which had been wholly transferred. It even kept the filenames.
I won't pretend to know how it works or to know anything about the format, but clearly it is possible to work with partial ZIP archives.
The "installer" (and "uninstaller") model is terrible. Every installer works differently, and most of them do really stupid things like spending ages searching the hard disk(s) for existing copies of themselves. They also give companies the excuse to do irritating things like demanding the entry of a 24-digit hexidecimal number to continue.
Applications should just run from where they are and go away when you delete them. The program shouldn't be so fragile that it requires a preparation tool to ensure everything is just right before the program is used, and it shouldn't leave crap everywhere that needs yet another tool to clean it all up.
...and no, I don't like package managers in Linux much either, but at least the installation process for them is always the same.
Re:Too many keyboard layouts
on
Blank Keyboard
·
· Score: 1
Also, that keyboard would be useless for me because I've learned to type on a UK keyboard which has two extra keys: one to the left of the Enter key, and one to the left of Z. (Technically I suppose it's only one extra key, because we lose the # and \ key which is normally up around backspace somewhere.)
I find, actually, that UK keyboards are a lot more consistant than US ones for some reason.
Look inside your "eMbedded VC++" directory. In there somewhere is a version of Microsoft's C++ compiler which targets ARM (called CLARM.EXE if memory serves) which you can use independently of the IDE. You then just need the header files and libraries, which you can find by checking where the IDE is configured to look for them.
There's also the obvious option of just continuing to use the version you already have. It's not suddenly going to stop working just because there's a new release.
I've not really done much Windows Mobile development (I dabbled briefly a while back, but the app I wrote was just a quick hack to get a job done) but from what little I know I can't really see how it could require Visual Studio.
I suspect Visual Studio will give some extra added features, like the ability to remotely debug and to deploy directly at the click of a button, but all you really need to do development for the platform is the header files, libraries and a version of cl.exe that can build for the right architecture. Those things are present in the current toolset, so for those who aren't IDE-bound it won't really matter very much.
Maybe you should just show up in a pirate costume, with a black patch over your eye. It'll probably make more of an impact than quibbling with the lawyers.
The problem OpenID attempts to solve is "Is this person who claims to have been here a week ago really the same person?", coupled with "Is pla who posted on slashdot the same person as pla who posted on my weblog?". That is it, really. There is no profile information shared explicitly by this system, though from reading the mailing list they seem to expect that people will invent mechanisms for doing this to complement OpenID. Sites which implement OpenID but only allow their own identities to log in would have missed the point completely. Even if no-one else uses it, LiveJournal, many of the LiveJournal clone sites, TypePad and MovableType will all support it, and that accounts for a large chunk of the weblog and journal users online. Any other support is a bonus, really.
As for anonymity, all that's needed for that is an ID server which will approve any arbitrary user within its domain. A bit like Mailinator but for identities rather than email. It's likely that such a site would quickly get banned from everywhere due to the spam it would be used for, but that's no different than certain sites disallowing anonymous users.
Regarding coding in spare time, I code stuff that's interesting or useful to me. I probably wouldn't have written a distributed identity system, but I can see why the Danga folks did it: they scratched their own itch in a manner which simultanously scratched a few other people's itches. I have no use for any of the things you claim "we" need. Different people need or desire different things.
In the ideal world where everyone uses keys and certificates, you'd get an instutution like the passport office to give you a certificate saying who you are. Your credit card company would also give you a certificate saying that you are a user of their credit services. You would supply the relevant certificates, signed by an organisation trusted to provide such a certificate, to the sites in order to log in, just like you might show your passport and a proof of address to a bank when you create an account, and like when you present your credit card to a merchant to make a purchase. LiveJournal could even give you a certificate saying that you are a given user at LiveJournal, thus allowing you to prove that to other people.
Unfortunately, all this stuff is hard to do right and users don't understand it, so it's unlikely to happen without some radical changes somewhere. OpenID and similar systems solve the very specific problem of knowing whether the Tom who is posting in some forum today is the same Tom who posted last week, and is the same Tom who posted in some other forum. It's not a magic bullet to solve all identity problems.
End-users can be protected from knowing about all this by their service, though. LiveJournal users, for example, can log in as "user.livejournal.com". This doesn't look like a URL, but it can be transformed into one. This does get tricky for established mass-hosting blog sites because they don't have such pretty-looking URLs already. A Xanga user would have to sign in as xanga.com/username, for example. Supporting whatever.xanga.com would require a DNS wildcard record, and they (like LiveJournal, in fact) might already be using some of their existing usernames as real hosts within their domain.
Hopefully at some point sites which only provide identities and no other service will spring up, and they'll provide URLs like that which don't actually go to anything except a blank HTML page with the right ID server link in it. I guess eventually anonymizing sites will appear which will allow anything.theirdomain.com and just approve it without question, though of course those sites will no doubt get banned from most sites pretty quickly because they'll be used for spam.
This is mitigated to a certain extent because a site can only ask the question "Is this MooseGuy529?". They can't ask "Who is logged in?". Therefore unless a site wants to target a particular user there is no tracking issue. In legitimate use, you enter the ID you wish to use into a little box and the site goes off and checks it. Unless you enter that ID, they have no idea what to check for.
There's nothing to stop the different services coming into agreement and working with each other. For example, it appears that TypeKey will eventually provide an OpenID identity server so that TypeKey accounts can be used on any OpenID site. That admittedly is cheating a little because Danga and TypeKey both belong to Six Apart, but since OpenID doesn't depend on one identity server, there's no technical reason why (for example) MSN Passport couldn't provide an OpenID identity server so that you could use your MSN Passport on any OpenID-supporting site.
It's harder for the other methods to share because they depend on a single ID server, but OpenID can bind them all together in theory.
If you post on slashdot and then run off and post on LiveJournal, both as "Daedala", no-one has any guarantee that we're dealing with the same Daedala. With OpenID, assuming you used the same identity (a word I'm only using because that's what they're calling it), other people would be able to know that the two are the same.
It's not a total solution, and only answers one question: "Is this the same person as I saw before?". It's a useful question to answer when it comes to interacting with people, though. It means that (on an OpenID-supporting, trustworthy site) no-one can pretend to be you.
I also hate having to sign in to comment on blogs or journals.
That's essentially what OpenID is for, I think. It's a way to not have to have an account at every blog but still to prove that you are the same absolutemeg that posted on some other blog, or that posted on the same blog a week ago.
It's certainly not intended to be used for anything important, like bank sign-ins or online shopping.
I think the idea here is just to answer the question "is this person the same person I dealt with last time?". It can't answer other questions, such as proving the visitor isn't the same user, or finding out what the user's address is, but for non-critial applications like weblog comments and web forums that's all you need, really.
Obviously no-one's suggesting that a system like this be used to log into your bank.
The only reason Passport remembers your last login is because you go through Passport's login page to become authenticated. With OpenID, the way the system works is different and this would be hard to implement.
If the demos and examples are anything to go by, you will enter the identity you want to use onto the site you want to log in as, and whatever is necessary to authenticate that identity will be done. LiveJournal's identity server can validate any identity you like if you have a LiveJournal account; you don't have to use your LiveJournal identity. (I'm not quite sure how that works yet, but the people on the mailing list seem pretty sure that it does.)
I guess if you have multiple LiveJournal accounts things could get tricky, since you can only be logged in as one at a time and the ID server will only work if you're using the right one. Multiple identities attached to a single LiveJournal account is fine, though.
It would be interesting to have packs of these things fly around in a pattern and meet up with one another periodically and share pending packets. They would also periodically fly near base stations and exchange packets with the network there. It would be like a fully-networked version of RFC 1149!
Slashdot Mirror
That doesn't change the fact that merely marrying someone's mother doesn't make you their father, which is what the song was about.
That's a funny song, but of course in practice your mother is always the person who gave birth to you and your father is always the person who contributed the sperm to fertilise her egg, regardless of marriage. Given the events in the song, you'd be a step-grandfather at best, and since society doesn't consider "step-grandfather" to be a meaningful family relationship, you're really just a person with a dad who was strange enough to wed your wife's daughter. Or something.
In the first case, presumably you'd know that your mother got shot at when she was younger, since something that traumatic would certainly be memorable. You'd also know that the shooter missed. You wouldn't know that the shooter was you, but it might later give you the inspiration to try to shoot your mother in the past. If you'd never been told that someone tried to shoot your mother, you might not have thought of trying in the first place.
Your actions when you went back in time would inspire your actions in "the present", causing the actions when you went back in time. Sounds like a fun little paradox!
I'm guessing that the reason they called it "JavaScript" was that in the early days it was used as little more than a glue language between HTML forms and embedded Java applets. JavaScript in Netscape was able to connect into the JVM and call methods on applets, and other such interesting things. The name comes from it being "a scripting language for Java", not "a scripting language based on Java".
Of course, I have no actual insider knowledge. This just seems like the most likely reason based on how JavaScript was set up back in the early implementations, before all this crazy DHTML stuff came along.
I've not yet looked at the code to find out if it's written cleanly enough for this, but theoretically someone could use an out-of-browser JavaScript interpreter and a replacement terminal part to make it talk over a socket, telnet-style. Then you could run it as a daemon and forget it's written in JavaScript...
If you were really crazy, you could even figure out how to make it support multiple concurrent terminals, run it as init (with an appropriate wrapper+js-interpreter written in C) on a system with the Linux kernel installed and have it bind to all of the local ttys and a provide a telnet server. You'd still have a kernel running atop a kernel, but in all other respects JS/UIX would be your operating system.
Neither of those are particularly useful, but would be kinda neat. :)
Of course, once one of your bridges is erected and in service it will never need to be replaced nor maintained. The market for bridges will dry up. This, I think, is one of the flaws in this model of selling items in these game worlds.
When I buy a t-shirt, 10-15 years later it's quite likely to have deteriorated to the point where it is no longer able to perform its job well. Likewise a car, or indeed a bridge, though each with a different average lifespan. Real items get broken, lost or even just worn out. When I buy a "car" in Second Life, I own and can use that car. That car will work forever and the game (presumably) makes it quite hard for me to lose it. Assuming no artificial barriers are erected to prevent it, there's no technical or physical reason why I can't duplicate and resell copies of that car.
The economy in these worlds is driven by novelty. The only reason I'd buy a new car is because the creator has done something wacky that can't be done by my existing car purchases. Eventually a point will be reached where no more innovations are possible, because all of these virtual worlds have their limits. I understand that Second Life's are less limiting than most, but given that it's been going for a few years now I'd expect that players have done just about everything that can be done with cars. Once there is no more room for novelty, there will be no point in buying anything. Everyone will own everything they could possibly want, and have no reason to replace any of it. The "exchange rate" beween their in-game currency and real-world currencies will suffer. Items will be so widespread that there is no scarsity to warrant non-trivial prices.
I hope no-one that is currently drawing a wage out of their activities in Second Life is relying on that lasting.
I can't help but wonder what would happen if someone were to run alongside one of these trucks in line with the sensors and just leap around. Would they then end up with just a big, smeared, stretched out person rather than the city?
I could imagine that one group might be a development house which has software targetting both Windows and MacOS. Eventually they'll be testing the software on a real Mac, but it'd sure be cheaper if all of the programmers could just run commoditty PC hardware and emulate a Mac well enough to do their testing alongside the Windows versions.
Of course, the fact that it'll be illegal might put them off a little.
It does, however, mean that Wine no longer needs an x86 emulator embedded in it in order to be ported to OS X. I expect that once x86 Macs are commonplace (assuming that it is really x86 that Apple is going for) it won't take long for Wine to be ported first to use X under OS X and hopefully latter to target the OS X window API directly. This would leave older users with PPC machines out of luck, of course.
Porting Winelib would, in theory, allow Windows apps to be built to target a PPC version of Winelib and thus allow PPC users to enjoy the software too, of course. I have a feeling, though, that most Mac users would rather suffer in a world of no software than run an ugly Windows application on their beautiful Mac desktops.
Years ago when my connection was unreliable I routinely used a tool called PKZipFix which would fix a partial ZIP archive to allow you to retrieve any contained files which had been wholly transferred. It even kept the filenames.
I won't pretend to know how it works or to know anything about the format, but clearly it is possible to work with partial ZIP archives.
The "installer" (and "uninstaller") model is terrible. Every installer works differently, and most of them do really stupid things like spending ages searching the hard disk(s) for existing copies of themselves. They also give companies the excuse to do irritating things like demanding the entry of a 24-digit hexidecimal number to continue.
Applications should just run from where they are and go away when you delete them. The program shouldn't be so fragile that it requires a preparation tool to ensure everything is just right before the program is used, and it shouldn't leave crap everywhere that needs yet another tool to clean it all up.
...and no, I don't like package managers in Linux much either, but at least the installation process for them is always the same.
Also, that keyboard would be useless for me because I've learned to type on a UK keyboard which has two extra keys: one to the left of the Enter key, and one to the left of Z. (Technically I suppose it's only one extra key, because we lose the # and \ key which is normally up around backspace somewhere.)
I find, actually, that UK keyboards are a lot more consistant than US ones for some reason.
Look inside your "eMbedded VC++" directory. In there somewhere is a version of Microsoft's C++ compiler which targets ARM (called CLARM.EXE if memory serves) which you can use independently of the IDE. You then just need the header files and libraries, which you can find by checking where the IDE is configured to look for them.
There's also the obvious option of just continuing to use the version you already have. It's not suddenly going to stop working just because there's a new release.
I've not really done much Windows Mobile development (I dabbled briefly a while back, but the app I wrote was just a quick hack to get a job done) but from what little I know I can't really see how it could require Visual Studio.
I suspect Visual Studio will give some extra added features, like the ability to remotely debug and to deploy directly at the click of a button, but all you really need to do development for the platform is the header files, libraries and a version of cl.exe that can build for the right architecture. Those things are present in the current toolset, so for those who aren't IDE-bound it won't really matter very much.
Maybe you should just show up in a pirate costume, with a black patch over your eye. It'll probably make more of an impact than quibbling with the lawyers.
The problem OpenID attempts to solve is "Is this person who claims to have been here a week ago really the same person?", coupled with "Is pla who posted on slashdot the same person as pla who posted on my weblog?". That is it, really. There is no profile information shared explicitly by this system, though from reading the mailing list they seem to expect that people will invent mechanisms for doing this to complement OpenID. Sites which implement OpenID but only allow their own identities to log in would have missed the point completely. Even if no-one else uses it, LiveJournal, many of the LiveJournal clone sites, TypePad and MovableType will all support it, and that accounts for a large chunk of the weblog and journal users online. Any other support is a bonus, really.
As for anonymity, all that's needed for that is an ID server which will approve any arbitrary user within its domain. A bit like Mailinator but for identities rather than email. It's likely that such a site would quickly get banned from everywhere due to the spam it would be used for, but that's no different than certain sites disallowing anonymous users.
Regarding coding in spare time, I code stuff that's interesting or useful to me. I probably wouldn't have written a distributed identity system, but I can see why the Danga folks did it: they scratched their own itch in a manner which simultanously scratched a few other people's itches. I have no use for any of the things you claim "we" need. Different people need or desire different things.
In the ideal world where everyone uses keys and certificates, you'd get an instutution like the passport office to give you a certificate saying who you are. Your credit card company would also give you a certificate saying that you are a user of their credit services. You would supply the relevant certificates, signed by an organisation trusted to provide such a certificate, to the sites in order to log in, just like you might show your passport and a proof of address to a bank when you create an account, and like when you present your credit card to a merchant to make a purchase. LiveJournal could even give you a certificate saying that you are a given user at LiveJournal, thus allowing you to prove that to other people.
Unfortunately, all this stuff is hard to do right and users don't understand it, so it's unlikely to happen without some radical changes somewhere. OpenID and similar systems solve the very specific problem of knowing whether the Tom who is posting in some forum today is the same Tom who posted last week, and is the same Tom who posted in some other forum. It's not a magic bullet to solve all identity problems.
End-users can be protected from knowing about all this by their service, though. LiveJournal users, for example, can log in as "user.livejournal.com". This doesn't look like a URL, but it can be transformed into one. This does get tricky for established mass-hosting blog sites because they don't have such pretty-looking URLs already. A Xanga user would have to sign in as xanga.com/username, for example. Supporting whatever.xanga.com would require a DNS wildcard record, and they (like LiveJournal, in fact) might already be using some of their existing usernames as real hosts within their domain.
Hopefully at some point sites which only provide identities and no other service will spring up, and they'll provide URLs like that which don't actually go to anything except a blank HTML page with the right ID server link in it. I guess eventually anonymizing sites will appear which will allow anything.theirdomain.com and just approve it without question, though of course those sites will no doubt get banned from most sites pretty quickly because they'll be used for spam.
This is mitigated to a certain extent because a site can only ask the question "Is this MooseGuy529?". They can't ask "Who is logged in?". Therefore unless a site wants to target a particular user there is no tracking issue. In legitimate use, you enter the ID you wish to use into a little box and the site goes off and checks it. Unless you enter that ID, they have no idea what to check for.
There's nothing to stop the different services coming into agreement and working with each other. For example, it appears that TypeKey will eventually provide an OpenID identity server so that TypeKey accounts can be used on any OpenID site. That admittedly is cheating a little because Danga and TypeKey both belong to Six Apart, but since OpenID doesn't depend on one identity server, there's no technical reason why (for example) MSN Passport couldn't provide an OpenID identity server so that you could use your MSN Passport on any OpenID-supporting site.
It's harder for the other methods to share because they depend on a single ID server, but OpenID can bind them all together in theory.
If you post on slashdot and then run off and post on LiveJournal, both as "Daedala", no-one has any guarantee that we're dealing with the same Daedala. With OpenID, assuming you used the same identity (a word I'm only using because that's what they're calling it), other people would be able to know that the two are the same.
It's not a total solution, and only answers one question: "Is this the same person as I saw before?". It's a useful question to answer when it comes to interacting with people, though. It means that (on an OpenID-supporting, trustworthy site) no-one can pretend to be you.
That's essentially what OpenID is for, I think. It's a way to not have to have an account at every blog but still to prove that you are the same absolutemeg that posted on some other blog, or that posted on the same blog a week ago.
It's certainly not intended to be used for anything important, like bank sign-ins or online shopping.
I think the idea here is just to answer the question "is this person the same person I dealt with last time?". It can't answer other questions, such as proving the visitor isn't the same user, or finding out what the user's address is, but for non-critial applications like weblog comments and web forums that's all you need, really.
Obviously no-one's suggesting that a system like this be used to log into your bank.
The only reason Passport remembers your last login is because you go through Passport's login page to become authenticated. With OpenID, the way the system works is different and this would be hard to implement.
If the demos and examples are anything to go by, you will enter the identity you want to use onto the site you want to log in as, and whatever is necessary to authenticate that identity will be done. LiveJournal's identity server can validate any identity you like if you have a LiveJournal account; you don't have to use your LiveJournal identity. (I'm not quite sure how that works yet, but the people on the mailing list seem pretty sure that it does.)
I guess if you have multiple LiveJournal accounts things could get tricky, since you can only be logged in as one at a time and the ID server will only work if you're using the right one. Multiple identities attached to a single LiveJournal account is fine, though.
It would be interesting to have packs of these things fly around in a pattern and meet up with one another periodically and share pending packets. They would also periodically fly near base stations and exchange packets with the network there. It would be like a fully-networked version of RFC 1149!