This isn't your average widget company. People don't invest in companies like SpaceX just because of the profit potential, they do it because they desperately and fervently want to see us get our bald monkey asses off this rock. Having a CEO that unabashedly shares this passion is heartening to investors like those. If anything, I expect this "outburst" will help SpaceX more than harm them.
Valve picked up our latest, and people are vocally split into two camps -- "This is fun despite the simple graphics" vs. "This looks like crap, so I won't play it." It's still been good for us, but it's absolutely received less attention for not being both fun and pretty at the same time.
I haven't played it, but from both the screenshots and the description, it looks like a Katamari Damacy clone... is it?
That's what I did. If you live in an largish apartment building, chances are good you have free access to a treadmill already.
I got a plastic tray from Ikea and tied some elastic around the back so I could mount it on the control panel and read a book while I walked. This way I didn't feel like I was "losing time", rather it was a chance to get in a solid block of reading while getting some exercise. And it really makes the time fly faster.
They're just being polite by pointing out there's no shame in failing to prove the Riemann Hypothesis, since it has frustrated the attempts of many a prominent mathematician so far.
Stallman suggests to add a feature to the browser allowing a user to say: "When you get URL X, use the Javascript from URL Y as if it came from URL X." If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%.
The AGPL already covers this and requires that the source to the server-side code be made available.
Implementing this sounds wildly impractical to me. Suppose I sign up with a service that makes a web app available to to me, and stores my data. At some point I decide I want to modify the behavior of the application by modifying the server-side code. So what do I do now? I sign up for a webhosting account for, say $40/mo. I configure the new server. I migrate all my files. I continue paying $40/mo indefinitely for the new server, and I continue maintaining my forked version of the application forever. Ouch -- this is nothing like the zero-cost, zero-configuration, zero-maintenance setup that was the original lure of the web app. In the world of ordinary open-source apps, the possibility of forking helps to keep users from getting abused or neglected by the developer. If the developer is thinking about changing the license, or making it into adware, or abandoning the software, or making it intro crippleware, or not providing bug fixes, or not making it compatible with new libraries and operating systems --- in all those situations, he knows that if he makes his users too unhappy, someone may fork the software and users may vote with their feet. The barrier to forking is pretty high, and it seldom happens, but the theoretical possibility is always there. In the setup proposed by the article, the barriers to forking are just way too high for it to be a plausible threat. Basically the forker not only has to start maintaining the fork, he also has to start up his own internet-based business to cover his new webhosting costs (or just eat the monthly cost of webhosting for the sole purpose of continuing to be able to run this one app).
Honestly, I fail to see why this is so wildly different than modifying traditional offline programs. Sure, there's a burden of maintaining your own changes, but that's always the case. And sure, it's not for everyone, but most people don't tinker with their normal programs source either. Of those inclined, many people already have server space, and you're not going to have to pay $40/month unless you're looking to serve it to other people.
Yes, it's more of a burden, but there are already plenty of websites run by a community or a small company. And bandwidth and server costs are only likely to get cheaper in the future.
Stallman suggests to add a feature to the browser allowing a user to say: "When you get URL X, use the Javascript from URL Y as if it came from URL X." If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%.
The AGPL already covers this and requires that the source to the server-side code be made available.
Another problem is that part of the allure of web apps is that they require zero configuration, and can be invisibly upgraded at any time. It's hard to see how you'd maintain that benefit while having users run a forked version of the client-side code. What happens when the provider wants to modify the server-side code in a way that breaks compatibility with the forked client-side code?
The same thing that happens if you make your own modifications to a traditional open source program. It's up to you to maintain your own branch and keep up with the upstream version. If you don't want to upgrade, you can stay on the current version. Likewise, for the web application case, you can run your own version of the web app and leave it pegged to the current version, ignoring the new versions.
Hopefully, a programmer who creates an Clipperz-style (for lack of a better name for this proposal) application will understand and support his users desires to be able to modify the program, and seek to create a relatively stable interface between the server-side and brower-based code. In case of an non-backwards compatible change, he might continue to run an older version of the service at an alternate location, for those users who don't want to or cannot currently switch.
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it?
Well, first off, with an open infrastructure, that service could be run on YOUR server, in which case, you pay your own bills. But even if it's on someone else's...
Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads.
Right, but the ad-free version will not run itself. You'll either have to host it on your own server or find some other company willing to support an ad-free version by some other means.
They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
You can set up a funding scheme with where the application doesn't keep user information. For example, you could have a third-party subscription broker that generates cryptographic tokens that indicate you paid for service. It's like buying ride tickets an amusement part; none of the individual ride operators needs to know (or care) anything about your billing information.
No model number, no sub-name, nothing easily differentiates the various animals that are called an 'iMac'. True, cars have been doing this for years, but people are used to including the car year or age to differentiate it. That's not entirely true. Most products do have a model number, usually something like M??????LL/A. They aren't advertised as such, though, and even in technical references they aren't always used. A few examples: iMac (Early 2006), MacBook Pro (Late 2007, 2.4/2.2GHz), Xserve (Early 2008), Mac mini (Early 2006).
The iPods/iPhones don't seem to have model numbers listed on the Apple specs pages, but if you add an iPod to your cart in the Apple store and then view your cart, it shows a model number.
Mind you after the crap rip-quality of the In Rainbows interweb release and the volte face of the cd release following, I have less sympathy than I once would have done despite the quality of the work. I think you were perhaps misinformed. It was always clear that an eventual CD release was to come, even if the precise when and how were initially uncertain. For example, see this Pitchfork news item from Oct 1, 9 full days before the online release. But I do agree with your other point, they really should have provided a better quality rip for those who took the plunge.
Slashdot Mirror
Nowadays I've found most utilities will waive installation feeds if you sign up online.
Congrats. Now imagine that you don't know which window of a dozen well-known webpages has the malicious ad hidden in it.
The official site seems to be slashdotted, but there's plenty of info at the Board Game Geek entry for the game.
NASA has released a diagram detailing the planned trajectory.
Glad to see I'm wasn't the only one scratching my head about the claim that FAT32 doesn't support the read-only attribute.
Damn kids these days, don't remember having to use ATTRIB...
Ugh, he may be a great researcher, but those are some terrible slides. Did he say anything that wasn't on a slide?
This isn't your average widget company. People don't invest in companies like SpaceX just because of the profit potential, they do it because they desperately and fervently want to see us get our bald monkey asses off this rock. Having a CEO that unabashedly shares this passion is heartening to investors like those. If anything, I expect this "outburst" will help SpaceX more than harm them.
Valve picked up our latest, and people are vocally split into two camps -- "This is fun despite the simple graphics" vs. "This looks like crap, so I won't play it." It's still been good for us, but it's absolutely received less attention for not being both fun and pretty at the same time.
I haven't played it, but from both the screenshots and the description, it looks like a Katamari Damacy clone... is it?
I can see the headline now: "We're not spamming you (really)"
I was wondering why I being spammed with such a seemingly innocuous message, I thought perhaps it was just a filter poisoning attempt.
I foresee a black market in Linux system restore discs...
A good engineer always has a backup. Including of their own ashes.
That's what I did. If you live in an largish apartment building, chances are good you have free access to a treadmill already.
I got a plastic tray from Ikea and tied some elastic around the back so I could mount it on the control panel and read a book while I walked. This way I didn't feel like I was "losing time", rather it was a chance to get in a solid block of reading while getting some exercise. And it really makes the time fly faster.
Or perhaps it's fish vs. spaghetti.
It is legal in most states in some form or another.
I have to say that i personally would enjoy watching the sport with human players.
In that case, you're in luck!
Also, has a senator ever made a good president?
Um, JFK? Truman?
German newspaper Die Zeit has an article online with a gallery of images from the recovered print.
They're just being polite by pointing out there's no shame in failing to prove the Riemann Hypothesis, since it has frustrated the attempts of many a prominent mathematician so far.
Implementing this sounds wildly impractical to me. Suppose I sign up with a service that makes a web app available to to me, and stores my data. At some point I decide I want to modify the behavior of the application by modifying the server-side code. So what do I do now? I sign up for a webhosting account for, say $40/mo. I configure the new server. I migrate all my files. I continue paying $40/mo indefinitely for the new server, and I continue maintaining my forked version of the application forever. Ouch -- this is nothing like the zero-cost, zero-configuration, zero-maintenance setup that was the original lure of the web app. In the world of ordinary open-source apps, the possibility of forking helps to keep users from getting abused or neglected by the developer. If the developer is thinking about changing the license, or making it into adware, or abandoning the software, or making it intro crippleware, or not providing bug fixes, or not making it compatible with new libraries and operating systems --- in all those situations, he knows that if he makes his users too unhappy, someone may fork the software and users may vote with their feet. The barrier to forking is pretty high, and it seldom happens, but the theoretical possibility is always there. In the setup proposed by the article, the barriers to forking are just way too high for it to be a plausible threat. Basically the forker not only has to start maintaining the fork, he also has to start up his own internet-based business to cover his new webhosting costs (or just eat the monthly cost of webhosting for the sole purpose of continuing to be able to run this one app).
Honestly, I fail to see why this is so wildly different than modifying traditional offline programs. Sure, there's a burden of maintaining your own changes, but that's always the case. And sure, it's not for everyone, but most people don't tinker with their normal programs source either. Of those inclined, many people already have server space, and you're not going to have to pay $40/month unless you're looking to serve it to other people.
Yes, it's more of a burden, but there are already plenty of websites run by a community or a small company. And bandwidth and server costs are only likely to get cheaper in the future.
One big reason this won't work is that a web app consists of two separate pieces of code: one that runs on the server, and one that runs on the client. I wouldn't call it open source if I get to modify 50% of the code, but not the other 50%.
The AGPL already covers this and requires that the source to the server-side code be made available.
Another problem is that part of the allure of web apps is that they require zero configuration, and can be invisibly upgraded at any time. It's hard to see how you'd maintain that benefit while having users run a forked version of the client-side code. What happens when the provider wants to modify the server-side code in a way that breaks compatibility with the forked client-side code?
The same thing that happens if you make your own modifications to a traditional open source program. It's up to you to maintain your own branch and keep up with the upstream version. If you don't want to upgrade, you can stay on the current version. Likewise, for the web application case, you can run your own version of the web app and leave it pegged to the current version, ignoring the new versions.
Hopefully, a programmer who creates an Clipperz-style (for lack of a better name for this proposal) application will understand and support his users desires to be able to modify the program, and seek to create a relatively stable interface between the server-side and brower-based code. In case of an non-backwards compatible change, he might continue to run an older version of the service at an alternate location, for those users who don't want to or cannot currently switch.
The paradigm they're talking about is one in which users get a service from someone running a rack full of servers. For instance, if I write a letter in my web-app word-processor, somewhere there's got to be a server that's storing my document. The person running the service needs to pay their elecric bill. How are they going to do it?
Well, first off, with an open infrastructure, that service could be run on YOUR server, in which case, you pay your own bills. But even if it's on someone else's...
Well, they could make their users look at ads, but that won't work if the app is really user-modifiable, because someone will come out with a version that doesn't show the ads.
Right, but the ad-free version will not run itself. You'll either have to host it on your own server or find some other company willing to support an ad-free version by some other means.
They could charge the user a monthly fee, but that won't work, because the article proposes to set up the service so that the provider knows absolutely nothing about the user, not even his username.
You can set up a funding scheme with where the application doesn't keep user information. For example, you could have a third-party subscription broker that generates cryptographic tokens that indicate you paid for service. It's like buying ride tickets an amusement part; none of the individual ride operators needs to know (or care) anything about your billing information.
Scientists have released an interactive computer simulation demonstrating how the new system would work.
The iPods/iPhones don't seem to have model numbers listed on the Apple specs pages, but if you add an iPod to your cart in the Apple store and then view your cart, it shows a model number.