You are absolutely right, thank you for this critical correction.
I've been looking at the docs since your reply. The additional layer Google's placed in front appears to give the GoogleID Service Provider a means of passing a few fields into the Identity Provider. As an identity provider, even after five days of consideration, I cannot think of any extra value I could provide to a service provider or client given these extra fields.
I'm delighted that at least its implementable, unfortunately I still dont understand what the value is.
Again, thank you for this very critical correction.
a single distro gaining popularity will be instrumental for standardizing what is expected of Linux for introduction into a larger market
the flaws in your biased & self interested statement are manifest. manifest and hilarious.
first off, i dont see what advantage linux has by gaining a larger market. will these corporate interest invest time and code into linux? will they provide free support to end users? will the people joining your standardized Linux gain anything from the homogenized OS they've switched to?
second, how will standardization improve linux's marketability? to what extend to we enforce homogenization? do we enforce a single wm on all users? do we enforce a single office suite? a single programming language?
third, how do you plan to tell everyone they must work on the same thing? do you think everyone will willingly conform to the standard patterns you wish to impose and stop working on the things they think are cool?
Linux's only strength is that it grants developers an open environment to develop novel new things. all I see in your desire is a self interested bid to crush out the free spirited developer spirit and to replace it with something tooled to replace commercial operating systems with something free, for your own good. honestly I dont think you or your desires contribute anything useful to the linux community, in fact I think the desire to make Linux conform to the expectations of the "typical" desktop has been the worst mistake the Linux movement.
"I don't care whether I can login to Google with OpenID."
Wait a second, wtc? What does this have to do with anything at all? Not only have you not read about googles changes, you dont appear to know anything about the identity space.
No one anywhere logs in to their identity provider with their OpenID; they log in to their identity provider manually for the explicit purpose of authorizing their OpenID. If you could log in to a OpenID account with an OpenID url anyone could log into your account just by using your OpenID URL; there wouldnt be any security at all.
I really havent a clue what in my argument this line has anything to do with, nor whether this statement even makes any sense.
Reading your thread you do a very fine job justifying a means to an end, but I'd still wager that the means that Google used are abominable.
"It means that now, people who have Google accounts can login to my website without having to register."
It also means FooBarWidget's dad (the proverbial Joe the Plumber of this thread) also has to remember that on every other site he has to use something else. And if he wants to use his Yahoo or MSN account, he has to remember its something totally different. Google has simply added to the confusion by throwing in their own proprietary non-interoperable standard, further fractioning a standard you've already argued is unusable for its complexity.
The only acceptable way to make this a win for users was to make some kind of a standard. Google didnt. Instead they've only further exacerbated the mess of online identity standards. I'm happy that you're happy that you can tell your dad to just use his email, but for Dad thats only ever going to work on a very very small handful of sites for users who happen to want to use their google account identity; for the other 99.99% of use cases it only murkier the water further.
The real insult-to-injury here is that OpenID already supports email logins. Theres no reason Google couldnt have let good ole dad login with foo.dad@gmail.com; OpenID translates this to http://gmail.com/ which happens to be a valid web address. But instead of implementing an existing standard at no cost to developers everywhere, Google added more complexity for developers and more confusion for users.
I dont see whats salvagable about this. Google didnt add anything new for users, made it so users of gmail couldnt use 99.999% of OpenID consumers, put a huge burden on developers, and confused a lot of users struggling with an complex system whose only boon was interoperability.
I'm happy its easy for you and your dad. But theres about eighty things a 9 year old programmer would have made better decisions about, and at no cost to the rediculously low bar you've set for your expectations.
You clearly havent spent even the most cursory effort to investigate what Google has actually done here.
They havent changed OpenID, they've built their own black box to lookup OpenID URL's for email addresses.
Your entire argument is posited around Google making a more usable version of OpenID. While it may be easier for gmail users in that they can use their email addresses instead of url's, Google has not provided any spec for how other sites can implement the black box they've thrown in front of a completely vanilla OpenID. Since no one else can use it, its easy to say it hasnt helped OpenID.
2) Define a protocol for developers to map email addresses to URLs. Use some kind of URI-template to convert ApathyMaybe@gmail.com into one of the aboves.
As you sarcastically point out, they ignored both options and dropped a heinously ugly black box in front of OpenID that developers must correspond with first. They didnt embrace and extend OpenID, they hacked a solution they internally are content to suffer with.
Google hasnt provided any extensions or changes to OpenID and has released no new protocols. They've introduced a black box you have to go through to get to their vanilla OpenID service. Theres no value add for developers.
The value add for clients is that they can just enter their email address instead of a URL. This would've been far better served by defining a DNS-SD spec for use in looking up emails and transforming them into OpenID's. Instead Google's opted for a black box of no use to anyone except gmail clients.
I agree, and further I think all the PHEV companies are shooting their market/cash cow in the foot by producing such ridiculous and deceptive marketting.
If you're going to measure battery power, why claim mpg at all? Why not just say you have 30000 mpg, or 3000000000 mpg or infinite mpg? Are any of these untrue?
however, real horizontal scaling has to be able to go beyond SMP scaling; with this in mind i dont see a interpreter lock as necessarily a dealbreaker. running an interpretter per CPU and using a combination of networking and shared memory for message passing is still viable, and those remoting techniques would ultimately be required down the road even with SMP scaling.
actually, the inability to scale on SMP systems gives me faith that CCP wont do the wrong thing yet again: they cannot take that easy single VM route out, mercy be. this is a huge challenge, but its one ccp needs to step up and face.
Great post, but I have one qualm. Microthreading/tasklet models are not explicitly incompatible with SMP systems. Theres nothing inherent to microthreads that would prevent, say, eight separate hardware threads all working in tandem to run a single solar system & its batch of microthreads.
Classical concurrency coordination mechanisms like mutexes and locks are not ideal for microthreading environments, so perhaps scaling out with these concurrency primitives might make abandoning stackless a logical step. Something like an actor model or a message passing scheme may however work extremely well in a stackless environment. Particularly if all you are doing is processing messages, you still want that ability to context switch extremely quickly.
My understanding is the main hold-back for concurrent Eve servers is things like guns firing at a ship thats already blown up, but the local thread doesnt know the ships blown up (not possible in their present non-concurrent environment). You can deal with this either by holding mutexes on the target, or you can use message passing and simply have the blown up ship send a message back saying "sorry, you cant shoot me, i already asploded," and then deal with that failure message in an async fashion.
If I were CCP I know what path I'd be taking. But thus far, CCP has focused largely on platform wins like asynch IO (although given the CPU usage their IO USED to be taking up perhaps that was in order) and proxy servers. They've systematically been ignoring the question of real concurrency. Its a problem I'd love to take a crack at, although it sounds like another one of those things where I'd be locked in a tower for years unshaven half blind & three quarters crazy. Ultimately though, there is no choice for CCP: this is a path they MUST pursue if they want their game to ever work. Presently 400 person combat is miserable, and recent enguagements have crested far past that to over 1000 people in system. Single threaded execution will never work for a world without shards.
Eve is extremely well balance for incoming players
Theres been some talk about logarithmic advantage: training skills to level 5/5 takes far longer than 1->4 took yet provides the same boost as 1->2 or 2->3 or 3->4. As long as they're not 1v1 dueling older players (1v1 dueling... which _never_ _ever_ happens in this game), a new player will do fine with a scattering of level 3,4, & 5 skills.
The ships bear a similar diminishing rewards scheme. Old players with a crap ton of money fly Tier2 ships, which cost 8-16x as much but provide either a moderate boost in stats or are special purpose (long range jamming, tackling, space-priesting, &c). As a new player, this spells opportunity: you have a ship that costs very little and is possible insured, flying against someone with a marginal ship advantage flying an outrageously more costly ship. What I'm pointing out is that Tier2 ships are not overwhemlingly powerful: if you (and your friends) try and take down the T2 ship, you've got a decent chance & you'll've caused huge economic damage. If they tag you, your ship didnt cost that much to begin with. Its the cardinal rule of Eve: fly what you can afford.
I have a character with a sizable amount of XP, yet I fly mostly Tier1 ships: it largely frees me from having to make money, even though i'm constantly swinging into fleet battles, smashing as many T2 enemies as I can, and constantly losing shit. For the marginal advantage I'd gain flying Tier2, its a great trade off to be able to make.
I agree that a PvP spec character requires 6-9 months. But from there its only another 3 months to be fully specced on any one class of ship (T2 cruisers for a race). Once you get up and going with PvP, you're most of the way there. This is the logarithmic acceleration parent was talking about: you need a lot of skills to level 4/5, but only a couple to 5/5: it just so happens that 5/5 takes significantly longer than 1->4 took. Usually you need the 5/5 to use equipment, and not because the 5% energy capacity advantage is what it takes to keep up with the joneses.
Older characters just have more choice. And they can fly cap ships. But for really good PvP experience, I dont see either of these as particularly vital. If you dont mind flying light absolutely vital PvP ships, you can get well specced in interdictors in 6 months. T2 cruisers are 9 months.
There are two and only two use cases for the current market of cloud computing. You either a) have highly elastic demands on some kind of periodic basis and you dont want to deploy/manage enough hardware to meet these infrequent spikes or b) you are not rich enough or competent enough to put together a team to handle your own operations.
The first one is a valid use case. The second one basically means your architects dont know enough to scale horizontally, and should be handed their pink slip.
I dont get what you want. You can either explain how it works, or explain it to the public: they start by explaining it to the public, then they tell you how they actually do it. The public facing stuff is mildly deceptive (doesnt mention their throttling severely breaks TCP) & the how they do it stuff is actually fairly acurate.
I just dont get what your ask is. To the average person TCP/IP doesnt mean a damned thing. How do you propose they discuss a TCP/IP centric topic in a way a "average person" will care about?
+5 Insightful? I'm sorry but way way overrated. This isnt a press release for the common person. Its the medias fault if they cant distill down the truth to an intersting and accurate account of what Comcast did.
UDP requires clients to know how to throttle. If your clients and the clients you are connected to do not throttle correctly you will overload your pipe and there is no long term recourse except to continually drop packets.
Admitantly usually incoming data is not where people have problems-- its outgoing where its your client thats in control-- but I really think UDP is a poor choice for P2P protocols based on its complete lack of bandwidth control.
When the number of unidirectional upload sessions for any of the managed P2P protocols for a particular Sandvine PTS reaches the pre-determined session threshold, the Sandvine PTS issues instructions called âoereset packetsâ that delay unidirectional uploads for that particular P2P protocol in the geographic area managed by that Sandvine PTS. The âoeresetâ is a flag in the packet header used to communicate an error condition in communication between two computers on the Internet. As used in our current congestion management practices, the reset packet is used to convey that the system cannot, at that moment, process additional high-resource demands without creating risk of congestion. - comcast report
Their use of RST packets are exactly what ECN and ECN+ are for. The difference is ECN doesnt completely break TCP. Vista has ECN built in, but disabled. I'm not sure how ECN works in Linux or BSD.
I dont see how sun emission spectra & earth radiation levels are relevant to measured absorption capabilities of a photovoltaic cell. If this thing CAN get 500x more absorption than a current 35% efficient photovoltaic cell, which it might be able to, it's not doing it in IR and visible. Assuming this isnt just faulty reporting thats what has to be going on here.
Eve obviously has a big player controlled world building aspect (galaxy building); I guess my qualm is there is the lack of ability to shape much besides sovereignty and a handful of special-purpose player owned structures. Yes its entirely player run but the extent of what in game influence lets you do is pretty limited.
Tabula Rasa has "control point" bases that the NPC's swarm and take over. To get the point back you've got to get some people together and go take back the control point. The "epic" virtue of the notion is lost, in that control points will change hands twenty times a day and that aside from access to a handful of NPCs theres no game impact at all. Still, its a mild version of the game world influence you are talking about, and its damned fun sitting inside a base mowing down hordes of advancing npcs.
Someone mentioned Shadowbane as having really sweet player controlled cities. As its free, I'll have to check it out.
Did Planetside have anything to offer here?
What else needs to go into the catalog of games that have history?
Slashdot Mirror
You are absolutely right, thank you for this critical correction.
I've been looking at the docs since your reply. The additional layer Google's placed in front appears to give the GoogleID Service Provider a means of passing a few fields into the Identity Provider. As an identity provider, even after five days of consideration, I cannot think of any extra value I could provide to a service provider or client given these extra fields.
I'm delighted that at least its implementable, unfortunately I still dont understand what the value is.
Again, thank you for this very critical correction.
I wish I could find docs on the NX protocol; alas it appears I'd have to reverse engineer from the source.
a single distro gaining popularity will be instrumental for standardizing what is expected of Linux for introduction into a larger market
the flaws in your biased & self interested statement are manifest. manifest and hilarious.
first off, i dont see what advantage linux has by gaining a larger market. will these corporate interest invest time and code into linux? will they provide free support to end users? will the people joining your standardized Linux gain anything from the homogenized OS they've switched to?
second, how will standardization improve linux's marketability? to what extend to we enforce homogenization? do we enforce a single wm on all users? do we enforce a single office suite? a single programming language?
third, how do you plan to tell everyone they must work on the same thing? do you think everyone will willingly conform to the standard patterns you wish to impose and stop working on the things they think are cool?
Linux's only strength is that it grants developers an open environment to develop novel new things. all I see in your desire is a self interested bid to crush out the free spirited developer spirit and to replace it with something tooled to replace commercial operating systems with something free, for your own good. honestly I dont think you or your desires contribute anything useful to the linux community, in fact I think the desire to make Linux conform to the expectations of the "typical" desktop has been the worst mistake the Linux movement.
"I don't care whether I can login to Google with OpenID."
Wait a second, wtc? What does this have to do with anything at all? Not only have you not read about googles changes, you dont appear to know anything about the identity space.
No one anywhere logs in to their identity provider with their OpenID; they log in to their identity provider manually for the explicit purpose of authorizing their OpenID. If you could log in to a OpenID account with an OpenID url anyone could log into your account just by using your OpenID URL; there wouldnt be any security at all.
I really havent a clue what in my argument this line has anything to do with, nor whether this statement even makes any sense.
Reading your thread you do a very fine job justifying a means to an end, but I'd still wager that the means that Google used are abominable.
"It means that now, people who have Google accounts can login to my website without having to register."
It also means FooBarWidget's dad (the proverbial Joe the Plumber of this thread) also has to remember that on every other site he has to use something else. And if he wants to use his Yahoo or MSN account, he has to remember its something totally different. Google has simply added to the confusion by throwing in their own proprietary non-interoperable standard, further fractioning a standard you've already argued is unusable for its complexity.
The only acceptable way to make this a win for users was to make some kind of a standard. Google didnt. Instead they've only further exacerbated the mess of online identity standards. I'm happy that you're happy that you can tell your dad to just use his email, but for Dad thats only ever going to work on a very very small handful of sites for users who happen to want to use their google account identity; for the other 99.99% of use cases it only murkier the water further.
The real insult-to-injury here is that OpenID already supports email logins. Theres no reason Google couldnt have let good ole dad login with foo.dad@gmail.com; OpenID translates this to http://gmail.com/ which happens to be a valid web address. But instead of implementing an existing standard at no cost to developers everywhere, Google added more complexity for developers and more confusion for users.
I dont see whats salvagable about this. Google didnt add anything new for users, made it so users of gmail couldnt use 99.999% of OpenID consumers, put a huge burden on developers, and confused a lot of users struggling with an complex system whose only boon was interoperability.
I'm happy its easy for you and your dad. But theres about eighty things a 9 year old programmer would have made better decisions about, and at no cost to the rediculously low bar you've set for your expectations.
You clearly havent spent even the most cursory effort to investigate what Google has actually done here.
They havent changed OpenID, they've built their own black box to lookup OpenID URL's for email addresses.
Your entire argument is posited around Google making a more usable version of OpenID. While it may be easier for gmail users in that they can use their email addresses instead of url's, Google has not provided any spec for how other sites can implement the black box they've thrown in front of a completely vanilla OpenID. Since no one else can use it, its easy to say it hasnt helped OpenID.
I see two options Google could have pursued if they'd wanted to embrace and extend OpenID to let users use their email addresses.
1) Define a mapping users can use. Tell users to use http://gmail.com/~ApathyMaybe or http://apathymaybe.gmail.com/ for their url's for example.
2) Define a protocol for developers to map email addresses to URLs. Use some kind of URI-template to convert ApathyMaybe@gmail.com into one of the aboves.
As you sarcastically point out, they ignored both options and dropped a heinously ugly black box in front of OpenID that developers must correspond with first. They didnt embrace and extend OpenID, they hacked a solution they internally are content to suffer with.
Read the article.
Google hasnt provided any extensions or changes to OpenID and has released no new protocols. They've introduced a black box you have to go through to get to their vanilla OpenID service. Theres no value add for developers.
The value add for clients is that they can just enter their email address instead of a URL. This would've been far better served by defining a DNS-SD spec for use in looking up emails and transforming them into OpenID's. Instead Google's opted for a black box of no use to anyone except gmail clients.
the inverse would have meant it would have massed nearly 6000 lbs, making it an even bigger crater.
It weights 1984 lbs on earth, hence its mass is 1984 lbs.
You should point out it weights 1984 pounds... just shy of one ton. It makes the landing system a lot more intuitive.
I agree, and further I think all the PHEV companies are shooting their market/cash cow in the foot by producing such ridiculous and deceptive marketting.
If you're going to measure battery power, why claim mpg at all? Why not just say you have 30000 mpg, or 3000000000 mpg or infinite mpg? Are any of these untrue?
i did not know that: good point!
however, real horizontal scaling has to be able to go beyond SMP scaling; with this in mind i dont see a interpreter lock as necessarily a dealbreaker. running an interpretter per CPU and using a combination of networking and shared memory for message passing is still viable, and those remoting techniques would ultimately be required down the road even with SMP scaling.
actually, the inability to scale on SMP systems gives me faith that CCP wont do the wrong thing yet again: they cannot take that easy single VM route out, mercy be. this is a huge challenge, but its one ccp needs to step up and face.
Right right right right right... and wrong.
Great post, but I have one qualm. Microthreading/tasklet models are not explicitly incompatible with SMP systems. Theres nothing inherent to microthreads that would prevent, say, eight separate hardware threads all working in tandem to run a single solar system & its batch of microthreads.
Classical concurrency coordination mechanisms like mutexes and locks are not ideal for microthreading environments, so perhaps scaling out with these concurrency primitives might make abandoning stackless a logical step. Something like an actor model or a message passing scheme may however work extremely well in a stackless environment. Particularly if all you are doing is processing messages, you still want that ability to context switch extremely quickly.
My understanding is the main hold-back for concurrent Eve servers is things like guns firing at a ship thats already blown up, but the local thread doesnt know the ships blown up (not possible in their present non-concurrent environment). You can deal with this either by holding mutexes on the target, or you can use message passing and simply have the blown up ship send a message back saying "sorry, you cant shoot me, i already asploded," and then deal with that failure message in an async fashion.
If I were CCP I know what path I'd be taking. But thus far, CCP has focused largely on platform wins like asynch IO (although given the CPU usage their IO USED to be taking up perhaps that was in order) and proxy servers. They've systematically been ignoring the question of real concurrency. Its a problem I'd love to take a crack at, although it sounds like another one of those things where I'd be locked in a tower for years unshaven half blind & three quarters crazy. Ultimately though, there is no choice for CCP: this is a path they MUST pursue if they want their game to ever work. Presently 400 person combat is miserable, and recent enguagements have crested far past that to over 1000 people in system. Single threaded execution will never work for a world without shards.
Eve is extremely well balance for incoming players
Theres been some talk about logarithmic advantage: training skills to level 5/5 takes far longer than 1->4 took yet provides the same boost as 1->2 or 2->3 or 3->4. As long as they're not 1v1 dueling older players (1v1 dueling... which _never_ _ever_ happens in this game), a new player will do fine with a scattering of level 3,4, & 5 skills.
The ships bear a similar diminishing rewards scheme. Old players with a crap ton of money fly Tier2 ships, which cost 8-16x as much but provide either a moderate boost in stats or are special purpose (long range jamming, tackling, space-priesting, &c). As a new player, this spells opportunity: you have a ship that costs very little and is possible insured, flying against someone with a marginal ship advantage flying an outrageously more costly ship. What I'm pointing out is that Tier2 ships are not overwhemlingly powerful: if you (and your friends) try and take down the T2 ship, you've got a decent chance & you'll've caused huge economic damage. If they tag you, your ship didnt cost that much to begin with. Its the cardinal rule of Eve: fly what you can afford.
I have a character with a sizable amount of XP, yet I fly mostly Tier1 ships: it largely frees me from having to make money, even though i'm constantly swinging into fleet battles, smashing as many T2 enemies as I can, and constantly losing shit. For the marginal advantage I'd gain flying Tier2, its a great trade off to be able to make.
I agree that a PvP spec character requires 6-9 months. But from there its only another 3 months to be fully specced on any one class of ship (T2 cruisers for a race). Once you get up and going with PvP, you're most of the way there. This is the logarithmic acceleration parent was talking about: you need a lot of skills to level 4/5, but only a couple to 5/5: it just so happens that 5/5 takes significantly longer than 1->4 took. Usually you need the 5/5 to use equipment, and not because the 5% energy capacity advantage is what it takes to keep up with the joneses.
Older characters just have more choice. And they can fly cap ships. But for really good PvP experience, I dont see either of these as particularly vital. If you dont mind flying light absolutely vital PvP ships, you can get well specced in interdictors in 6 months. T2 cruisers are 9 months.
why does it cost so damned much.
There are two and only two use cases for the current market of cloud computing. You either a) have highly elastic demands on some kind of periodic basis and you dont want to deploy/manage enough hardware to meet these infrequent spikes or b) you are not rich enough or competent enough to put together a team to handle your own operations.
The first one is a valid use case. The second one basically means your architects dont know enough to scale horizontally, and should be handed their pink slip.
I dont get what you want. You can either explain how it works, or explain it to the public: they start by explaining it to the public, then they tell you how they actually do it. The public facing stuff is mildly deceptive (doesnt mention their throttling severely breaks TCP) & the how they do it stuff is actually fairly acurate.
I just dont get what your ask is. To the average person TCP/IP doesnt mean a damned thing. How do you propose they discuss a TCP/IP centric topic in a way a "average person" will care about?
+5 Insightful? I'm sorry but way way overrated. This isnt a press release for the common person. Its the medias fault if they cant distill down the truth to an intersting and accurate account of what Comcast did.
This is a bollocks suggestion.
UDP requires clients to know how to throttle. If your clients and the clients you are connected to do not throttle correctly you will overload your pipe and there is no long term recourse except to continually drop packets.
Admitantly usually incoming data is not where people have problems-- its outgoing where its your client thats in control-- but I really think UDP is a poor choice for P2P protocols based on its complete lack of bandwidth control.
When the number of unidirectional upload sessions for any of the managed P2P protocols
for a particular Sandvine PTS reaches the pre-determined session threshold, the Sandvine PTS
issues instructions called âoereset packetsâ that delay unidirectional uploads for that particular P2P
protocol in the geographic area managed by that Sandvine PTS. The âoeresetâ is a flag in the
packet header used to communicate an error condition in communication between two computers
on the Internet. As used in our current congestion management practices, the reset packet is used
to convey that the system cannot, at that moment, process additional high-resource demands
without creating risk of congestion.
- comcast report
Their use of RST packets are exactly what ECN and ECN+ are for. The difference is ECN doesnt completely break TCP. Vista has ECN built in, but disabled. I'm not sure how ECN works in Linux or BSD.
I dont see how sun emission spectra & earth radiation levels are relevant to measured absorption capabilities of a photovoltaic cell. If this thing CAN get 500x more absorption than a current 35% efficient photovoltaic cell, which it might be able to, it's not doing it in IR and visible. Assuming this isnt just faulty reporting thats what has to be going on here.
tc with htb
Hey there.
What are your thoughts on ECN as a way for your system to control ingress?
Yes.
Eve obviously has a big player controlled world building aspect (galaxy building); I guess my qualm is there is the lack of ability to shape much besides sovereignty and a handful of special-purpose player owned structures. Yes its entirely player run but the extent of what in game influence lets you do is pretty limited.
Tabula Rasa has "control point" bases that the NPC's swarm and take over. To get the point back you've got to get some people together and go take back the control point. The "epic" virtue of the notion is lost, in that control points will change hands twenty times a day and that aside from access to a handful of NPCs theres no game impact at all. Still, its a mild version of the game world influence you are talking about, and its damned fun sitting inside a base mowing down hordes of advancing npcs.
Someone mentioned Shadowbane as having really sweet player controlled cities. As its free, I'll have to check it out.
Did Planetside have anything to offer here?
What else needs to go into the catalog of games that have history?
Are you familiar with any other games where players are involved in world building?