The Reciprocal Public License requires you to release all of your source code if you link to this library, even if your project is personal or used in-house only.
IANAL, but I read the intent as "if you improve macstl you have to publish your changes to macstl" not "if you link macstl you have to publish source to the entire project".
Obviously I can't say which one matches the legalese.
I dunno. The mini might change that cost issue somewhat. If only they could get the platform-unique games...
Good point, I forgot about that. Trouble is, though, the mini isn't 64-bit, and that's a uniqueness point the Mac does have - a good 64-bit user base on their newish machines.
But they're not going to get unique hardware nowadays - easiest to stay aligned with PC interfaces and share - and it's just not economic to make a platform-unique game for Macs.
DirectX is the same but its slower because you have to depend on libraries more.
Huh? Libraries for what?
Not the maths parts if that's what you mean - the whole point of DirectX and OpenGL nowadays is to encapsulate stuff that can be handed off to the video card, and since video cards support these transformations nowadays so does Direct3D.
Nice ideas, and had me thinking for a minute, but:
Trusted servers: solutions so far need to trust the client too. Wallhacks, fullbright skins, for example, are invisible to the server and very sophisticated aimbots could be too. The best solution really needs a Punkbuster-alike client checker and it'd be very hard to implement one of those with a free-as-in-freedoms game. The best you could do, I suppose, would be release the game as LGPL and have the punkbuster-clone link into that, but that's starting to get fairly nasty.
Proprietary graphics and maps - yes, that'd work, except there's almost no way you could copy protect them. Especially if source is available for the client that reads them.
but I do know the $50 price tag suggests they were released relatively recently.
No, limited market to exploit and little competition. The more games that get released, the faster turnover of titles, the more you'll start to see bargains.
Until there are games or video cards that gaming enthusiasts lust after that get released only on the Mac, they'll never gain market share because of gaming.
Um, never. You might stump up a couple of hundred bucks for a console because there's a must-have exclusive game but it's a whole new thing stumping up thousands for a Mac.
That's probably not far off. The problems are, AFAICS,
1. support burden; you're fighting a huge number of distros, half-assed drivers from companies who don't really care about Linux, and so on (related: QA burden: double the testing!) 2. cost of port in the first place 3. less of a framework to implement copy protection; it's even easier to drop stuff into the kernel, libs, etc. to fake it 4. commercial demand; OK, chicken and egg, but it's basically negligable right now
I think support is the real killer: even if evangelist programmers will do the port in their spare time, you can't try and sell a Linux version in small quantities unless you're willing to invest in supporting it - and who's going to buy a game if they can't expect support?
I prefer "A", but that's because I want to know as soon as possible that I will be upgrading at some point. Yes, exploits may be created sooner that way, but even if you go with "B", exploits can still be created.
Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.
The point is that in B Joe-Random-Sysadmin can just type "apt-get update" and get a fixed, QA-ed stable kernel which is supported by his vendor. Look back at the comments on the "Which Linux for Business?" story a few days ago - QA and support *is* a big deal for live servers.
The whole point of this new effort is quick disclosure after a fix and explicitly not with long embargo times c.f. Microsoft or vendor-sec. They're talking about four to fourteen days. Read the article.
Actually the namespace is 5.X (and thus Sol10 is 5.10) 2.x finished when Sun relegated "SunOS" to technical use and came out with the "Solaris" monkier for marketing purposes.
The way I heard it:
- SunOS 5.x is the kernel. - Solaris 2.x is the OS distribution (the name 'Solaris' marked the first time they bundled X, IIRC).
So this is Solaris 2.10 but they dropped the leading digit in marketing back at 2.7 (c.f. Emacs - Emacs 21 is version 0.21)
Full disclosure ensures the best security because it forces accountability.
But it gives the script kiddies chance to exploit whatever vulnerability first. Why is full disclosure a better model then a warning and delayed full disclosure?
An uninformed person will not only miss the advisory, but will likely miss the patch as well.
Huh?
Full-disclosure advisories are announced on one of a number of usenet groups or mailing lists. They're frequently written by folks with l33t names and poor grammar. Most are for XYZ-random PHP scripts so don't apply to you. They're a chore to wade through.
Patches are announced on very low volume vendor mailing lists and/or appear in automated update tools. You can often subscribe to these as you register your product with the vendor.
Am I missing something? How are patches harder to find?
the money takes so long to process that arrives too late
In this case, though, there won't be a "too late". Yes, a lot of money needs to be spent in the short term on food and medical relief but much will be needed long term to rebuild homes and businesses to get the economies back afloat.
I meant that it's using the "trusted third-party" model, expressing it in terms you'll see in Schneier's book, etc. Whether you trust it or not, of course, is up to you.
What do people refer to when they say "tin-foil hat"? Seriously, I don't know, and I found no definition of that jargon.
The idea is that if you wear tinfoil on your head you won't be susceptible to the mind-control waves transmitted by the government. Or something like that.
Hence it's associated with screwball conspiracy theories.
I'd be surprised if it wasn't in Wikipedia but I can't get to the site right now (!).
3) Companies did not want to hand over an important function of their business to a third party with little gain.
Huh? It's just outsourcing your basic account management. Lots of companies outsource stuff for many different reasons. The idea is you also get a ubiquitous UI so it's easy and reassuring for anyone who wants to use it - that has value too.
Let me have my 1000's of different logins as you can't imagine what happens when your only identity online get's compromised.
But can you remember them *all*? Or do you write them down somewhere, making a different single point of failure?
Most people just use the same set of passwords anyway. If you got hold of Amazon's passwords you'd probably have access to a huge number of eBay accounts, for example. It all comes down to convenience, and if the single point of failure is well secured and well administered then it's a good-enough solution for Amazon and eBay, etc. It's not a good idea for anything ultra secure like your bank.
Maybe MS Money 2005 won't force you to use passport. I'm still using MS Money 2001 for this reason.
No, I think it does. I suspect they're using it so they can cut off your access to the MSN financial feeds after however-many years you get. You can get a demo from Microsoft and try it if you want.
But Money *2004* definitely has a no-Passport 'I don't need to use online features' option.
The Redmond software company said Wednesday it would stop trying to persuade Web sites to use its Passport service, which stores consumers' credit-card and other information as Internet users surf from place to place."
Passport does not store your credit-card details any more. You had to opt in to passport's Wallet service to do this. Microsoft discontinued Wallet a long time ago.
You do not have to provide any personal details to Passport. If you do, you can refuse Passport permission to pass them on to other sites. In this case, all the end sites get is your 64-bit user ID.
End sites cannot store information in your Passport account. The API is one way only. To alter the details in your Passport you have to go to passport.net
Passport is a trusted third-party for authentication. You don't log into any passport-enabled site directly; they redirect you to a secure page on passport.net (often with some source-site branding) and Passport redirects you back to them once you've logged in.
Passport absolutely DOES NOT "store your passwords". A few people said this in the eBay story's comments (!). Come on people, we're supposed to be tech-savvy here.
I'm almost sorry to see it go - it was a usable, simple to integrate single-sign-on with a big name, money and a fair critical mass behind it. Shame the entry price was so high.
I realize that it's probably the fault of the implementer, and not the technology, but I can't tell you how many times I've supplied my password to a page that was rendered without https.
Huh? All logins are processed, AFAIK, are processed through passport.net on a secure page. The site you want to login to redirects you to a secure page on passport.net - with some branding from the original site - which redirects you back once you've logged it.
I was asking about the source for the bit about "not just an authentication system, evil plans".
A single sign in system will always hinge on security of the authentication system, whether it's a distributed network or not. I assume you're talking about Identity Commons. If eBay run validation through their own i-broker and I hack into their i-broker then I can do whatever I like on eBay. If PayPal route all their authentication requests through eBay's i-broker then by compromising the one system I've compromised PayPal too. OK, I don't automatically get access to Amazon's i-broker if they haven't agreed a trust exchange but I'm still inside the system. But if 2idi become the de-facto root i-broker and everyone trusts them then the whole exercise has gained nothing: there's still a single point for massive failure. Additionally in a distributed system there's scope for attacks on the traffic between i-brokers. I don't see how any of this is inherently more secure.
As an aside, I don't think you implied incorrectness - "people just think of it doing X" isn't necessarily bad, "foo does X, Y and Z but most people just think of it as doing X" parses equally well.
This is already possible using SSL client certificates, although I suspect it'd be less hassle all round for the server to sign/trust your cert locally rather than actually send you back a signed copy. Unless they do perform significant verification of you, that is, but that's generally infeasible.
But until card readers are on every desktop and every public terminal, you're stuck with soft keys and passwords. So you might as well just use a password over SSL.
If they promoted a system that was 100% decentralized (as opposed to the 100% centralized Passport),
But aren't you setting up ani-name registry to be the new central focus? Isn't that the same thing? I've just skimmed your site, maybe I'm missing something.
Stripped down the core, Passport is just a 64-bit user ID. There's no data sharing requirement at all.
Slashdot Mirror
How you ensure that the program memory (data segment, stack and heap) will all be in a consistent state after a load?
This is actually why Quake 2 saved games didn't work through game updates: it saved entity action state as a function pointer into the game code.
The Reciprocal Public License requires you to release all of your source code if you link to this library, even if your project is personal or used in-house only.
IANAL, but I read the intent as "if you improve macstl you have to publish your changes to macstl" not "if you link macstl you have to publish source to the entire project".
Obviously I can't say which one matches the legalese.
I dunno. The mini might change that cost issue somewhat. If only they could get the platform-unique games...
Good point, I forgot about that. Trouble is, though, the mini isn't 64-bit, and that's a uniqueness point the Mac does have - a good 64-bit user base on their newish machines.
But they're not going to get unique hardware nowadays - easiest to stay aligned with PC interfaces and share - and it's just not economic to make a platform-unique game for Macs.
DirectX is the same but its slower because you have to depend on libraries more.
Huh? Libraries for what?
Not the maths parts if that's what you mean - the whole point of DirectX and OpenGL nowadays is to encapsulate stuff that can be handed off to the video card, and since video cards support these transformations nowadays so does Direct3D.
Trusted servers? Proprietary graphics and maps?
Nice ideas, and had me thinking for a minute, but:
Trusted servers: solutions so far need to trust the client too. Wallhacks, fullbright skins, for example, are invisible to the server and very sophisticated aimbots could be too. The best solution really needs a Punkbuster-alike client checker and it'd be very hard to implement one of those with a free-as-in-freedoms game. The best you could do, I suppose, would be release the game as LGPL and have the punkbuster-clone link into that, but that's starting to get fairly nasty.
Proprietary graphics and maps - yes, that'd work, except there's almost no way you could copy protect them. Especially if source is available for the client that reads them.
but I do know the $50 price tag suggests they were released relatively recently.
No, limited market to exploit and little competition. The more games that get released, the faster turnover of titles, the more you'll start to see bargains.
Until there are games or video cards that gaming enthusiasts lust after that get released only on the Mac, they'll never gain market share because of gaming.
Um, never. You might stump up a couple of hundred bucks for a console because there's a must-have exclusive game but it's a whole new thing stumping up thousands for a Mac.
That's probably not far off. The problems are, AFAICS,
1. support burden; you're fighting a huge number of distros, half-assed drivers from companies who don't really care about Linux, and so on
(related: QA burden: double the testing!)
2. cost of port in the first place
3. less of a framework to implement copy protection; it's even easier to drop stuff into the kernel, libs, etc. to fake it
4. commercial demand; OK, chicken and egg, but it's basically negligable right now
I think support is the real killer: even if evangelist programmers will do the port in their spare time, you can't try and sell a Linux version in small quantities unless you're willing to invest in supporting it - and who's going to buy a game if they can't expect support?
I prefer "A", but that's because I want to know as soon as possible that I will be upgrading at some point. Yes, exploits may be created sooner that way, but even if you go with "B", exploits can still be created.
Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.
The point is that in B Joe-Random-Sysadmin can just type "apt-get update" and get a fixed, QA-ed stable kernel which is supported by his vendor. Look back at the comments on the "Which Linux for Business?" story a few days ago - QA and support *is* a big deal for live servers.
The whole point of this new effort is quick disclosure after a fix and explicitly not with long embargo times c.f. Microsoft or vendor-sec. They're talking about four to fourteen days. Read the article.
Actually the namespace is 5.X (and thus Sol10 is 5.10)
2.x finished when Sun relegated "SunOS" to technical use and came out with the "Solaris" monkier for marketing purposes.
The way I heard it:
- SunOS 5.x is the kernel.
- Solaris 2.x is the OS distribution (the name 'Solaris' marked the first time they bundled X, IIRC).
So this is Solaris 2.10 but they dropped the leading digit in marketing back at 2.7 (c.f. Emacs - Emacs 21 is version 0.21)
If you were a real proffesional you would build your own optimized linux distro.
Yeah, because you get good third party support for that. RTFQ.
Full disclosure ensures the best security because it forces accountability.
But it gives the script kiddies chance to exploit whatever vulnerability first. Why is full disclosure a better model then a warning and delayed full disclosure?
It's high time people stopped informing companies about security holes.
Why?
That's not what the guy here is being sued for. Check the timeline on his website - he never informed the vendor, he just disclosed to the world.
An uninformed person will not only miss the advisory, but will likely miss the patch as well.
Huh?
Full-disclosure advisories are announced on one of a number of usenet groups or mailing lists. They're frequently written by folks with l33t names and poor grammar. Most are for XYZ-random PHP scripts so don't apply to you. They're a chore to wade through.
Patches are announced on very low volume vendor mailing lists and/or appear in automated update tools. You can often subscribe to these as you register your product with the vendor.
Am I missing something? How are patches harder to find?
the money takes so long to process that arrives too late
In this case, though, there won't be a "too late". Yes, a lot of money needs to be spent in the short term on food and medical relief but much will be needed long term to rebuild homes and businesses to get the economies back afloat.
Yes, and I have a bridge in New York to sell you.
I meant that it's using the "trusted third-party" model, expressing it in terms you'll see in Schneier's book, etc. Whether you trust it or not, of course, is up to you.
What do people refer to when they say "tin-foil hat"? Seriously, I don't know, and I found no definition of that jargon.
Tin-foil hat article in Wikipedia.
What do people refer to when they say "tin-foil hat"? Seriously, I don't know, and I found no definition of that jargon.
The idea is that if you wear tinfoil on your head you won't be susceptible to the mind-control waves transmitted by the government. Or something like that.
Hence it's associated with screwball conspiracy theories.
I'd be surprised if it wasn't in Wikipedia but I can't get to the site right now (!).
3) Companies did not want to hand over an important function of their business to a third party with little gain.
Huh? It's just outsourcing your basic account management. Lots of companies outsource stuff for many different reasons. The idea is you also get a ubiquitous UI so it's easy and reassuring for anyone who wants to use it - that has value too.
Let me have my 1000's of different logins as you can't imagine what happens when your only identity online get's compromised.
But can you remember them *all*? Or do you write them down somewhere, making a different single point of failure?
Most people just use the same set of passwords anyway. If you got hold of Amazon's passwords you'd probably have access to a huge number of eBay accounts, for example. It all comes down to convenience, and if the single point of failure is well secured and well administered then it's a good-enough solution for Amazon and eBay, etc. It's not a good idea for anything ultra secure like your bank.
Maybe MS Money 2005 won't force you to use passport. I'm still using MS Money 2001 for this reason.
No, I think it does. I suspect they're using it so they can cut off your access to the MSN financial feeds after however-many years you get. You can get a demo from Microsoft and try it if you want.
But Money *2004* definitely has a no-Passport 'I don't need to use online features' option.
I'm almost sorry to see it go - it was a usable, simple to integrate single-sign-on with a big name, money and a fair critical mass behind it. Shame the entry price was so high.
I realize that it's probably the fault of the implementer, and not the technology, but I can't tell you how many times I've supplied my password to a page that was rendered without https.
Huh? All logins are processed, AFAIK, are processed through passport.net on a secure page. The site you want to login to redirects you to a secure page on passport.net - with some branding from the original site - which redirects you back once you've logged it.
I was asking about the source for the bit about "not just an authentication system, evil plans".
A single sign in system will always hinge on security of the authentication system, whether it's a distributed network or not. I assume you're talking about Identity Commons. If eBay run validation through their own i-broker and I hack into their i-broker then I can do whatever I like on eBay. If PayPal route all their authentication requests through eBay's i-broker then by compromising the one system I've compromised PayPal too. OK, I don't automatically get access to Amazon's i-broker if they haven't agreed a trust exchange but I'm still inside the system. But if 2idi become the de-facto root i-broker and everyone trusts them then the whole exercise has gained nothing: there's still a single point for massive failure. Additionally in a distributed system there's scope for attacks on the traffic between i-brokers. I don't see how any of this is inherently more secure.
As an aside, I don't think you implied incorrectness - "people just think of it doing X" isn't necessarily bad, "foo does X, Y and Z but most people just think of it as doing X" parses equally well.
This is already possible using SSL client certificates, although I suspect it'd be less hassle all round for the server to sign/trust your cert locally rather than actually send you back a signed copy. Unless they do perform significant verification of you, that is, but that's generally infeasible.
But until card readers are on every desktop and every public terminal, you're stuck with soft keys and passwords. So you might as well just use a password over SSL.
If they promoted a system that was 100% decentralized (as opposed to the 100% centralized Passport),
But aren't you setting up ani-name registry to be the new central focus? Isn't that the same thing? I've just skimmed your site, maybe I'm missing something.
Stripped down the core, Passport is just a 64-bit user ID. There's no data sharing requirement at all.