Big Tunnel: A tunnel to somewhere. This requires, as you note, a machine acting as a multiplexer somewhere.
Microtunnels. Many client machines using VPN tunnel software. This does not require that close machine, but DOES require installing VPN on many clients.
Microtunnels are possible, and definitely recommend a vendor who does that. You're basically just getting a package deal on 2345235 little VPN accounts.
The Big Tunnel could just be 3 lines of ssh and cron, but you do need a box on your side and a remote box.
It seems to me that what the OP really should use is a mature framework e.g. Drupal rather than rolling your own regardless of language choice.
BUT since this thread has evolved into a language choice I'm going to respond to that. I'm also going to come right out and say that this post will be very unpopular on Slashdot. [Hopefully I won't get sunk by too many mods saying -1 "opposite of my fanaticism." ] ColdFusion has a pretty narrow applicability, but it's ideal for the OP.
Con: ColdFusion per se is not free in source or beer. (allthough there are ports) BUT shared hosting is only infinitesimally more expensive, so this is an issue only if you'relocked into a certain host or you are goign to have aan armada of servers. [The local dev version IS free.]
Con: ColdFusion is not very popular. There's still a LOT more usage than most people seem to perceive, but it's obviously not up there with e.g. PHP. [Commercially ColdFusion missed its window. In ~1998 database driven web applications were relatively novel and it was awesome. In 2001 it was comparatively unstable at higher traffic values. In 2002 they threw out the underlying server product and now it's an interpreter plugin that runs on any J2EE server you want it to.]
Pro: CF is a mature, modern flexible, powerful, rapid development toolchain for making websites. Especially as a novice in web apps it's going to support you. It'll let you worry about your app and not the minutia and has automatic capabilities for all sorts of things. It does the right thing by default but lets you override if it you need to. [Aside: These advantages are rather similar to what's advertised for RoR which IS free... If anyone can tell me some awesome thing RoR does for a website that CF doesn't beyond the two "cons" I've listed above I'd really like to know -- so far no one has been able to give me a good one. I'm excluding outdated concerns e.g. that the 1999 version of CF wasn't OOP.]
Pro: CFML is a pretty ideal language for generating HTML because as a markup language the flow of your HTML remains obvious and readable. [PHP eventually adopted the ability to use a similar paradigm.]
I've heard some people say that CF is what Java Server Pages should've been.
Pro: CF IS Java. (server) You're running on a Java server and the things you already know about running that remain true.
Pro: CF IS Java. (language) Even moreso, you can literally inline Java code into CF code (much like old school ASM into C). In my time writing CF I've done this literally twice:
a. to use Java's sleep() [Note: I do not recommend using "sleep" when generating a webpage, but it was an exceptional circumstance.]
b. to use Java's image manipulation libraries from CF templates.
I'm not saying CF is ideal for all circumstances. Merely being non-free rules it out of a lot! But it really is -- at least in my opinion -- "how to build a web app on a Java server" and that has a lot of suitability as a platform for the OP.
I realize you asked for a ruggedized laptop. However, that everyone else replaces theirs regularly points to the idea that you should consider that as a serious alternative and not discard it out of hand. I called this 'out of your box' because they're all doing it, and you're rejecting it a priori. I see basically three legitimate issues with this solution:
a) maintaining a consistent interface for you to be used to b) providing easy data migration to the replacement device c) total cost of multiple non-ruggedized devices compared to the realistic lifespan of ruggedized ones.
I'm not suggesting that my parent post had the right thoughts in mind, but Apple does provide surprisingly good, quick and easy solutions for a&b in OS X and the iPhone; I would expect the iPad to continue this.
Apple is not historically great about 'c', but that sand environment is hard even on the modestly ruggedized ones so it's not impossible.
Of course, I imagine their are.e.g Linux distros with good solutions to a & b and other laptop vendors who tend to have a consistent interface.
Of course you might need to account for shipping, purchasing, processing, or environmental costs in 'c', but even on the environmental front it's not a given that one device is better than 3, esp if it gets recycled well (many parts of the sandworn one will still work, and it'll be early enough that those, minus your HD, are reasonable used replacement parts in the right shop...)
I'd go further and say that in my opinion, and especially at these dataset sizes that are only small multiples of physical drives these days, RAID5 is a hinderance not a benefit to price-performant backup, because it requires validity of all-but-one of the drives in your array... typically, in the CORRECT array, so swapping mirrors in/out may be quite a headache.
Don't use any data level striping; break your data into a couple chunks drive-sized in the filesystem. Keep mirrors of each chunk on drives, both onsite and (one or more) offsite. Bit-compare the drives occasionally to look for loss.
I recommend at least 3 drives for any dataset; at least one onsite and at least one in your lockbox; that leaves one to be in transit at a time.
Replace the drives with newer versions every few years. Use a variety of brands/models.
Archival quality printing is also not cheap, but at least it's a fairly solved problem.
Personally I don't think you can do much better than printing it for an option that doesn't involve frequent migration - density isn't great, but I'm confident there'll still be optical scan devices at least for historical works, so if you print out all your bits in an OCR-friendly font, it won't be TOO much work for someone else to read them (if they really want to!) You should also include in the same format the source code for the decoder - even if that's not directly compilable in the future, it'll be a relatively clear indicator of how to do it, to the limits of what's possible.
You could probably do even better by e.g. punching holes into gold sheets a la The Baroque Cycle. Or stone tablets, etc. But those are all questions of "what's the most resilient format for PRINTED text" which is a topic at least we have a bunch of data on.
Actually, MS has tried to implement some Trusted Computing pieces that would do exactly that - restrict what will run so any DRM-broken content can't possibly be played.
Perhaps we could amend your sentence to: "never SUCCESSFULLY locked down..." - because they can't manage to have backward compatibility with all the terrible niche Windows apps and also do things like that.
I have no idea what this Orange Goo does, and I haven't read TFA. But I want to comment on your comment:
1) Most electronics are not made with incredibly strong surfaces and shells. If you were to encase your electronics in a perfectly fitting thick walled steel cradle, you'd reduce all events (esp a floor hitting a corner) into only the shock (G force) leaving out the impact (concentration of force on the surface of the device) Both of these parts of an impact are damaging. The fundamental momentum-limit you discuss only applies to the shock, which is most likely to damage internal parts.
2) Some crazy materials can do a surprisingly good job of momentarily pretending to be that idealized steel case. I presume the egg-video above shows that.
3) Typical elastic padding will not spread the momentum distribution out EVENLY over the time it takes to decelerate that 1/8". So even the shock part can be improved.
4) Don't forget that in addition to momentum, you must satisfy the conservation of energy equation, too. The most common way to do this is to bounce, and at least some of this energy gets converted to heat in each material that compresses. Dissipating more energy is also valuable.
Wow, you're amazingly not good at following plot points. Maybe there are holes in the plot, but they sure aren't the ones you listed.
As much as I want to rebut everything in great detail, it turns out I don't care quite enough. So a few... and I'll endeavor not to add any spoilers you didn't already give, and I'm dekarmaing this post to help.
6. Worker Prawns lack initiative. Definitely said early in the movie.
5. is because of 6.
3. If you PROCESS some material/chemical, it probably has different effects/uses than it had before you processed it. Otherwise why would you process it? Did you miss that whole bit of the movie?
2/3. That part about "powering the command module" - you made that up. At no point is powering a command module ever anything any characters are aspiring to. In the interest of avoiding spoilers, I'll leave it to you to figure out which part of those 4 words you might've gotten wrong.
I was going to say this, but of course you beat me to it. District 9 is one of the most legitimate serious science fiction / extrapolative fiction movies I've seen in a long, long time - things you usually only get in books. A limited number of fantastical assumptions, and then the exploration of the very rational ramifications of those assumptions.
And it was made on a relative shoestring, and the effects are perfect -- and the acting is amazing. But if you're expecting a 100% crazy action/effects movie, District 9 isn't it. (Neither is Inglorious Bastards, which is also awesome)
I appreciate the OP's concern, but really, any minimum wage peon at a credit or collection agency can look up any SSN in a couple minutes. The people who you need to sue are not the ones using SSNs for IDs, but the credit reporting agencies themselves and anyone else who skipped doing any actual verification of who you are in favor of the much cheaper use of your SSN as a password in direct violation of all the government documentation about how it was NOT secret.
You're right about this - you can distribute it as long as the source is available. The GPL was never and will never be about free as in beer, it's about being able to verify, to persistently use, and to extend the software you have.
You can charge $1,000,000 for the first copy, if you want - and if you can get someone to pay. But they'll be free to take the source you give them and redistribute copies for $50,000... or for $0.
--
Even if the App Store might now allow a clone app from your source, they would certainly (as certainly as any other App Store submission) allow an app with new levels, or one targeted at blind users (somehow!) or etc. Or maybe someone wants to make it into a psych test. More likely, if you vanish and someone wants to take advantage of iPhone 4.0 features when they come out.
The PRIME scenario is that users are never encumbered by the lack of source or lack of permissions, EXCEPT that they have to pass that forward.
That's what it's about, guaranteeing innovation and stability.
--
Oh, and everyone ELSE's opinions about the GPL should be based on the text. It was carefully constructed so that you could violate the "spirit" of it without violating the letter of it. So if you and he can find an attorney you both trust, the letter of the GPL DOES tell you the spirit of it.
The only big advantage of the externals is that the connectors are a bit more robust, so if you're going to plug/unplug them a LOT, you're a bit better off.
But for maximum longevity you should take 'vibration free' seriously. That is, you shouldn't lay a drive on a hard table, because when you set it there there's a surprisingly large impact. Set it on a layer of bubblewrap or foam, instead.
If you have humidity issues, I believe you can collect desiccant packets from other things and bake them on low heat to 'refresh' them (bake out the existing humidity) Ideally do this baking with good ventilation.
Well as TFA gives several examples of, there are good uses of such frames. That's the problem... there IS some value here in many cases.
But reading this I think it's clear that we need a browser feature here. That is, something between an extension and straight HTML.
It could even just be that they use the code they already have for backward compatibility but add some kind of hint like 'toolbarframe=true' (ok, that's terrible, but you get my point) It has to identify in the frameset which part is a toolbar and which part is a 'main' page.
If that's present, the browser realizes this frame is supposed to behave like a toolbar. So it: a) Adds some kind of display of the toolbar URL and an 'x' to close the toolbar 'frame' and automatically go to the main site.
b) Uses the right 'target' URL for the main forward/back/refresh/navigation bar etc., without dropping the toolbar... Basically be aware that it's using frames as a persistent wrapping, not as some other part of layout.
c) Becomes a feature you can explicitly disable in your browser preferences to have no frame toolbars.
Then shame any providers who don't use the hint. Google will figure out how to PageRank the right internal sites with those hints pretty fast, I'd say. Content providers will have no more to complain about than they do with any other toolbar.
A camera is something that can take photos, not something with some parts that could have made a camera. So:
a) pierce the lens if you really want to be crazy, screwing up some nice camera innards. This is relatively risky.
b) Sand the lens and surrounding area a bit.
c) Get some good 2 part epoxy and apply over the camera.
Voila, you no longer have a camera.
Obviously they won't warranty YOUR CAMERA, but you don't have to open it up. If you skip step a, you're not even 'breaking' anything... but if b/c is right you won't ever be able to use that camera again, because you'll have to break apart the body of the laptop along with the lens to.
Basically, as long as each virtual node isn't doing any WORK, you don't need any special hardware. And even if they are doing some work, but just not a lot. We have 5 Linux Xen VMs in production on a 1600Mhz Celeron with 768MB of RAM, works fine, no problems.
The CPU is almost irrelevant - you'll need whatever CPU you'd need to do all the things you're doing, plus some overhead, but it's not like it falls apart.
RAM is the only critical thing. You need at least 96 MB for the host and 24MB for each additional live Xen VM, as I recall (That's probably not precisely right) But you'll naturally be swapping a ton if you do that. A more reasonable VM has 128M - 256MB of RAM itself, so you need that for each active VM. But again, that's only for each one running at a time.
Or if you are going to swap a bunch, get better disks:)
In any case, I definitely wouldn't climb the price curve of equipment to do this; don't buy anything on the bleeding edge - look at arstechnica and just max the RAM on a value box - or maybe upgrade the MB to something that takes more RAM.
Used, commodity computer equipment is usually not price effective compared to the cheap end of what's still available new. But pay attention to the price point where it's cheaper to get (and power, while they're on) TWO value boxes than to pump up the one box you've been thinking of higher.
I agree both with the parent's GENERAL point and with the other replies that say it's too confusing. That is, for actual, and probably rural users, your proposed system is way too complex. In addition, the POST itself is complex.
OP's goal seems to clearly be to be nice about this. As the parent suggests, the key to trying to be nice about this without paying for a bigger pipe is to properly encourage users to use off-peak downloads. You need a simple, fair system, that just works with users who aren't thinking about it. And I agree, filtering by traffic type is lame.
So from a bulk-downloader point of view you want a system that limits everyone's bandwidth during peak times only - and you want to publish when the offpeak times are so that aggressive downloaders can choose to download stuff during those times if they so desire.
The peak limits should be stiff enough that you aren't quite pegged in either upload or download (separate limits) so everybody gets a relatively low latency connection. Feel free to add more than one tier of "peak" if you need to, especially internally. Or if you're really cool, it will automatically detect when you're about to be at 100% and throttle based on that... so you're not actually 'setting' peak times, you're just publishing guidance on what times tend to be peak.
This kind of traffic shaping - limiting everyone's bandwidth fairly when there isn't enough - is basically good for your users as a whole.
Another key thing to do is HOW this bandwidth is limited. What you want to do is not, really: no more than 200 kb/s. What you really want is more like no more than 12000 kb/min, and no more than 2000 kb/s. There are more complex algorithms for this... but the important thing is to average their bandwidth over a modest time period. Somewhere between 5 seconds and a couple minutes is probably right. Because most typical web users who AREN'T bulk downloading need a lot of bandwidth for very short periods, and to keep the interactive web experience fast you need to give it to them.
The 2.6 kernel does this pretty easily; 2.4 might but I can't remember. Of course, I don't have a clue whether you're using a linux router. TrafficControl or tc, I think the module was called. But I haven't had to adjust mine in a good long time.
Microsoft doesn't deserve slack on this. Maybe the UAC or Windows 7 teams deserve slack, but that development ecosystem is Microsoft's fault - because it's difficult to install a useful, nontrivial Windows program without being an Administrator.
In Vista they made this WORSE, to my understanding, by adding a UAC prompt for anything that looked like an installer. So a worm installing in less-privileged locations might not trigger UAC, but any normal installer is going to.
That IS the problem, right there. Userland programs should be installable not as root, and the ecosystem encouraged to make them that way. Maybe W7 is better, but in Vista they went _backwards_ on this issue. Linux has always done this. OS X has always done this (since there's been OS X, which isn't as long)
I get that pulling that off with a registry and DLLs is going to be a bit messy, but that's the real problem, in my opinion.
Actually almost all people have 4 colors, and some have 5.
RGB are the 3 you think of, and the exact wavelength moves around depending on the person. Many (men, usually) are RG colorblind - their R and G are very close together or identical. Many (women, usually - often mothers of the RG blind men - usually called tetrachromats) get a 5th receptor somewhere.
But the _4th_ receptor that everyone has is basically ultraviolet. Most light in this spectrum is blocked by the fluid in our eyes, so we get very, very little of it. But it's why those deep violet LEDs look so neat - they're not in the 3 receptors we get the most use of.
My 'usually' above might be 'always'; I can't remember.
Flash support for Linux has not always been great. An earlier version was so behind they SKIPPED it. But the RECENT versions are coming out for Linux very quickly; they made a decision to make Linux more supported. (And that's why they skipped a version; the new one was now on a respectable timeline.)
So, yes, it has good Linux support. Also, keep in mind that Adobe acquired Flash (as part of Macromedia) right in that time period; Adobe's track record with Flash on Linux is strong.
- Compiled Flex applications run in Flash Player; it's not an additional plugin.
- Flex applications use ActionScript 3, which is the same programming language that the newest versions of Flash use. It's structurally Java-like, but it's very easy to get powerful things done - for instance dynamically loading and playing a remote video stream can be accomplished in a few lines.
- Flex doesn't require the 'timeline' paradigm with binary source files that Flash had, replacing it with a solid and powerful layout language, making Flex a tool for app programmers rather than for animators. But there's huge crossover - and some workflows involve both tools because it trivially can include assets and videos from Flash.
- Flex Builder isn't free (unless you're a student) But the compiler IS free. So "Builder" is really like buying "Dreamweaver for Flex" more than like buying Flex. (Flex Builder is actually based on Eclipse, not on Dreamweaver, though)
If you're buying a Mac to put Linux on it, you're probably wasting money. (Unless you're buying a zillion of them and getting a discount) OS X is like that Lenovo one, maybe... except for me the OS X vs Windows difference just dwarfs anything else.
IANAL, but it seems to me that someone who purchased a Kindle2 prior to this announcement with the expectation that it would TTS everything would be able to sue. Or at least publicly demand a refund for their Kindle2, all titles purchased, and any shipping they paid for. (A refund I imagine Amazon would not normally allow).
I agree that the right way to fight this is not to buy DRM products, and I know several people not buying a Kindle just for it's DRM issues.
Your problem isn't with 'webapps' - which can do EXACTLY what you've just described, and we do it all the time in Flex and Flash. Your problem is with 'terrible webapps'
Oh, and as long as you bother to twiddle with the paths so it knows where to look, those apps DO run locally if you want them to - OR on the web. But voila, no platform issues, and the local disk access is optional.
Any "IE-only" web app is not a good web app, in my opinion.
Slashdot Mirror
I see two basic ways to do this, not just one.
Big Tunnel: A tunnel to somewhere. This requires, as you note, a machine acting as a multiplexer somewhere.
Microtunnels. Many client machines using VPN tunnel software. This does not require that close machine, but DOES require installing VPN on many clients.
Microtunnels are possible, and definitely recommend a vendor who does that. You're basically just getting a package deal on 2345235 little VPN accounts.
The Big Tunnel could just be 3 lines of ssh and cron, but you do need a box on your side and a remote box.
It seems to me that what the OP really should use is a mature framework e.g. Drupal rather than rolling your own regardless of language choice.
BUT since this thread has evolved into a language choice I'm going to respond to that. I'm also going to come right out and say that this post will be very unpopular on Slashdot. [Hopefully I won't get sunk by too many mods saying -1 "opposite of my fanaticism." ] ColdFusion has a pretty narrow applicability, but it's ideal for the OP.
Con: ColdFusion per se is not free in source or beer. (allthough there are ports) BUT shared hosting is only infinitesimally more expensive, so this is an issue only if you'relocked into a certain host or you are goign to have aan armada of servers. [The local dev version IS free.]
Con: ColdFusion is not very popular. There's still a LOT more usage than most people seem to perceive, but it's obviously not up there with e.g. PHP. [Commercially ColdFusion missed its window. In ~1998 database driven web applications were relatively novel and it was awesome. In 2001 it was comparatively unstable at higher traffic values. In 2002 they threw out the underlying server product and now it's an interpreter plugin that runs on any J2EE server you want it to.]
Pro: CF is a mature, modern flexible, powerful, rapid development toolchain for making websites. Especially as a novice in web apps it's going to support you. It'll let you worry about your app and not the minutia and has automatic capabilities for all sorts of things. It does the right thing by default but lets you override if it you need to. [Aside: These advantages are rather similar to what's advertised for RoR which IS free... If anyone can tell me some awesome thing RoR does for a website that CF doesn't beyond the two "cons" I've listed above I'd really like to know -- so far no one has been able to give me a good one. I'm excluding outdated concerns e.g. that the 1999 version of CF wasn't OOP.]
Pro: CFML is a pretty ideal language for generating HTML because as a markup language the flow of your HTML remains obvious and readable. [PHP eventually adopted the ability to use a similar paradigm.]
I've heard some people say that CF is what Java Server Pages should've been.
Pro: CF IS Java. (server) You're running on a Java server and the things you already know about running that remain true.
Pro: CF IS Java. (language) Even moreso, you can literally inline Java code into CF code (much like old school ASM into C). In my time writing CF I've done this literally twice:
a. to use Java's sleep() [Note: I do not recommend using "sleep" when generating a webpage, but it was an exceptional circumstance.]
b. to use Java's image manipulation libraries from CF templates.
I'm not saying CF is ideal for all circumstances. Merely being non-free rules it out of a lot! But it really is -- at least in my opinion -- "how to build a web app on a Java server" and that has a lot of suitability as a platform for the OP.
Wish I had mod points!
Anyway I agree -- Adobe made an excellent toolchain to do what you're asking, in the form of Adobe AIR.
I realize you asked for a ruggedized laptop. However, that everyone else replaces theirs regularly points to the idea that you should consider that as a serious alternative and not discard it out of hand. I called this 'out of your box' because they're all doing it, and you're rejecting it a priori. I see basically three legitimate issues with this solution:
a) maintaining a consistent interface for you to be used to
b) providing easy data migration to the replacement device
c) total cost of multiple non-ruggedized devices compared to the realistic lifespan of ruggedized ones.
I'm not suggesting that my parent post had the right thoughts in mind, but Apple does provide surprisingly good, quick and easy solutions for a&b in OS X and the iPhone; I would expect the iPad to continue this.
Apple is not historically great about 'c', but that sand environment is hard even on the modestly ruggedized ones so it's not impossible.
Of course, I imagine their are .e.g Linux distros with good solutions to a & b and other laptop vendors who tend to have a consistent interface.
Of course you might need to account for shipping, purchasing, processing, or environmental costs in 'c', but even on the environmental front it's not a given that one device is better than 3, esp if it gets recycled well (many parts of the sandworn one will still work, and it'll be early enough that those, minus your HD, are reasonable used replacement parts in the right shop...)
I'd go further and say that in my opinion, and especially at these dataset sizes that are only small multiples of physical drives these days, RAID5 is a hinderance not a benefit to price-performant backup, because it requires validity of all-but-one of the drives in your array... typically, in the CORRECT array, so swapping mirrors in/out may be quite a headache.
Don't use any data level striping; break your data into a couple chunks drive-sized in the filesystem. Keep mirrors of each chunk on drives, both onsite and (one or more) offsite. Bit-compare the drives occasionally to look for loss.
I recommend at least 3 drives for any dataset; at least one onsite and at least one in your lockbox; that leaves one to be in transit at a time.
Replace the drives with newer versions every few years. Use a variety of brands/models.
Archival quality printing is also not cheap, but at least it's a fairly solved problem.
Personally I don't think you can do much better than printing it for an option that doesn't involve frequent migration - density isn't great, but I'm confident there'll still be optical scan devices at least for historical works, so if you print out all your bits in an OCR-friendly font, it won't be TOO much work for someone else to read them (if they really want to!) You should also include in the same format the source code for the decoder - even if that's not directly compilable in the future, it'll be a relatively clear indicator of how to do it, to the limits of what's possible.
You could probably do even better by e.g. punching holes into gold sheets a la The Baroque Cycle. Or stone tablets, etc. But those are all questions of "what's the most resilient format for PRINTED text" which is a topic at least we have a bunch of data on.
Actually, MS has tried to implement some Trusted Computing pieces that would do exactly that - restrict what will run so any DRM-broken content can't possibly be played.
Perhaps we could amend your sentence to: "never SUCCESSFULLY locked down..." - because they can't manage to have backward compatibility with all the terrible niche Windows apps and also do things like that.
I have no idea what this Orange Goo does, and I haven't read TFA. But I want to comment on your comment:
1) Most electronics are not made with incredibly strong surfaces and shells. If you were to encase your electronics in a perfectly fitting thick walled steel cradle, you'd reduce all events (esp a floor hitting a corner) into only the shock (G force) leaving out the impact (concentration of force on the surface of the device) Both of these parts of an impact are damaging. The fundamental momentum-limit you discuss only applies to the shock, which is most likely to damage internal parts.
2) Some crazy materials can do a surprisingly good job of momentarily pretending to be that idealized steel case. I presume the egg-video above shows that.
3) Typical elastic padding will not spread the momentum distribution out EVENLY over the time it takes to decelerate that 1/8". So even the shock part can be improved.
4) Don't forget that in addition to momentum, you must satisfy the conservation of energy equation, too. The most common way to do this is to bounce, and at least some of this energy gets converted to heat in each material that compresses. Dissipating more energy is also valuable.
Wow, you're amazingly not good at following plot points. Maybe there are holes in the plot, but they sure aren't the ones you listed.
As much as I want to rebut everything in great detail, it turns out I don't care quite enough. So a few... and I'll endeavor not to add any spoilers you didn't already give, and I'm dekarmaing this post to help.
6. Worker Prawns lack initiative. Definitely said early in the movie.
5. is because of 6.
3. If you PROCESS some material/chemical, it probably has different effects/uses than it had before you processed it. Otherwise why would you process it? Did you miss that whole bit of the movie?
2/3. That part about "powering the command module" - you made that up. At no point is powering a command module ever anything any characters are aspiring to. In the interest of avoiding spoilers, I'll leave it to you to figure out which part of those 4 words you might've gotten wrong.
I was going to say this, but of course you beat me to it. District 9 is one of the most legitimate serious science fiction / extrapolative fiction movies I've seen in a long, long time - things you usually only get in books. A limited number of fantastical assumptions, and then the exploration of the very rational ramifications of those assumptions.
And it was made on a relative shoestring, and the effects are perfect -- and the acting is amazing. But if you're expecting a 100% crazy action/effects movie, District 9 isn't it. (Neither is Inglorious Bastards, which is also awesome)
I appreciate the OP's concern, but really, any minimum wage peon at a credit or collection agency can look up any SSN in a couple minutes. The people who you need to sue are not the ones using SSNs for IDs, but the credit reporting agencies themselves and anyone else who skipped doing any actual verification of who you are in favor of the much cheaper use of your SSN as a password in direct violation of all the government documentation about how it was NOT secret.
You're right about this - you can distribute it as long as the source is available. The GPL was never and will never be about free as in beer, it's about being able to verify, to persistently use, and to extend the software you have.
You can charge $1,000,000 for the first copy, if you want - and if you can get someone to pay. But they'll be free to take the source you give them and redistribute copies for $50,000... or for $0.
--
Even if the App Store might now allow a clone app from your source, they would certainly (as certainly as any other App Store submission) allow an app with new levels, or one targeted at blind users (somehow!) or etc. Or maybe someone wants to make it into a psych test. More likely, if you vanish and someone wants to take advantage of iPhone 4.0 features when they come out.
The PRIME scenario is that users are never encumbered by the lack of source or lack of permissions, EXCEPT that they have to pass that forward.
That's what it's about, guaranteeing innovation and stability.
--
Oh, and everyone ELSE's opinions about the GPL should be based on the text. It was carefully constructed so that you could violate the "spirit" of it without violating the letter of it. So if you and he can find an attorney you both trust, the letter of the GPL DOES tell you the spirit of it.
The only big advantage of the externals is that the connectors are a bit more robust, so if you're going to plug/unplug them a LOT, you're a bit better off.
But for maximum longevity you should take 'vibration free' seriously. That is, you shouldn't lay a drive on a hard table, because when you set it there there's a surprisingly large impact. Set it on a layer of bubblewrap or foam, instead.
If you have humidity issues, I believe you can collect desiccant packets from other things and bake them on low heat to 'refresh' them (bake out the existing humidity) Ideally do this baking with good ventilation.
Well as TFA gives several examples of, there are good uses of such frames. That's the problem... there IS some value here in many cases.
But reading this I think it's clear that we need a browser feature here. That is, something between an extension and straight HTML.
It could even just be that they use the code they already have for backward compatibility but add some kind of hint like 'toolbarframe=true' (ok, that's terrible, but you get my point) It has to identify in the frameset which part is a toolbar and which part is a 'main' page.
If that's present, the browser realizes this frame is supposed to behave like a toolbar. So it:
a) Adds some kind of display of the toolbar URL and an 'x' to close the toolbar 'frame' and automatically go to the main site.
b) Uses the right 'target' URL for the main forward/back/refresh/navigation bar etc., without dropping the toolbar... Basically be aware that it's using frames as a persistent wrapping, not as some other part of layout.
c) Becomes a feature you can explicitly disable in your browser preferences to have no frame toolbars.
Then shame any providers who don't use the hint. Google will figure out how to PageRank the right internal sites with those hints pretty fast, I'd say. Content providers will have no more to complain about than they do with any other toolbar.
A camera is something that can take photos, not something with some parts that could have made a camera. So:
a) pierce the lens if you really want to be crazy, screwing up some nice camera innards. This is relatively risky.
b) Sand the lens and surrounding area a bit.
c) Get some good 2 part epoxy and apply over the camera.
Voila, you no longer have a camera.
Obviously they won't warranty YOUR CAMERA, but you don't have to open it up. If you skip step a, you're not even 'breaking' anything... but if b/c is right you won't ever be able to use that camera again, because you'll have to break apart the body of the laptop along with the lens to.
Basically, as long as each virtual node isn't doing any WORK, you don't need any special hardware. And even if they are doing some work, but just not a lot. We have 5 Linux Xen VMs in production on a 1600Mhz Celeron with 768MB of RAM, works fine, no problems.
The CPU is almost irrelevant - you'll need whatever CPU you'd need to do all the things you're doing, plus some overhead, but it's not like it falls apart.
RAM is the only critical thing. You need at least 96 MB for the host and 24MB for each additional live Xen VM, as I recall (That's probably not precisely right) But you'll naturally be swapping a ton if you do that. A more reasonable VM has 128M - 256MB of RAM itself, so you need that for each active VM. But again, that's only for each one running at a time.
Or if you are going to swap a bunch, get better disks :)
In any case, I definitely wouldn't climb the price curve of equipment to do this; don't buy anything on the bleeding edge - look at arstechnica and just max the RAM on a value box - or maybe upgrade the MB to something that takes more RAM.
Used, commodity computer equipment is usually not price effective compared to the cheap end of what's still available new. But pay attention to the price point where it's cheaper to get (and power, while they're on) TWO value boxes than to pump up the one box you've been thinking of higher.
I agree both with the parent's GENERAL point and with the other replies that say it's too confusing. That is, for actual, and probably rural users, your proposed system is way too complex. In addition, the POST itself is complex.
OP's goal seems to clearly be to be nice about this. As the parent suggests, the key to trying to be nice about this without paying for a bigger pipe is to properly encourage users to use off-peak downloads. You need a simple, fair system, that just works with users who aren't thinking about it. And I agree, filtering by traffic type is lame.
So from a bulk-downloader point of view you want a system that limits everyone's bandwidth during peak times only - and you want to publish when the offpeak times are so that aggressive downloaders can choose to download stuff during those times if they so desire.
The peak limits should be stiff enough that you aren't quite pegged in either upload or download (separate limits) so everybody gets a relatively low latency connection. Feel free to add more than one tier of "peak" if you need to, especially internally. Or if you're really cool, it will automatically detect when you're about to be at 100% and throttle based on that... so you're not actually 'setting' peak times, you're just publishing guidance on what times tend to be peak.
This kind of traffic shaping - limiting everyone's bandwidth fairly when there isn't enough - is basically good for your users as a whole.
Another key thing to do is HOW this bandwidth is limited. What you want to do is not, really: no more than 200 kb/s. What you really want is more like no more than 12000 kb/min, and no more than 2000 kb/s. There are more complex algorithms for this... but the important thing is to average their bandwidth over a modest time period. Somewhere between 5 seconds and a couple minutes is probably right. Because most typical web users who AREN'T bulk downloading need a lot of bandwidth for very short periods, and to keep the interactive web experience fast you need to give it to them.
The 2.6 kernel does this pretty easily; 2.4 might but I can't remember. Of course, I don't have a clue whether you're using a linux router. TrafficControl or tc, I think the module was called. But I haven't had to adjust mine in a good long time.
Microsoft doesn't deserve slack on this. Maybe the UAC or Windows 7 teams deserve slack, but that development ecosystem is Microsoft's fault - because it's difficult to install a useful, nontrivial Windows program without being an Administrator.
In Vista they made this WORSE, to my understanding, by adding a UAC prompt for anything that looked like an installer. So a worm installing in less-privileged locations might not trigger UAC, but any normal installer is going to.
That IS the problem, right there. Userland programs should be installable not as root, and the ecosystem encouraged to make them that way. Maybe W7 is better, but in Vista they went _backwards_ on this issue. Linux has always done this. OS X has always done this (since there's been OS X, which isn't as long)
I get that pulling that off with a registry and DLLs is going to be a bit messy, but that's the real problem, in my opinion.
Actually almost all people have 4 colors, and some have 5.
RGB are the 3 you think of, and the exact wavelength moves around depending on the person. Many (men, usually) are RG colorblind - their R and G are very close together or identical. Many (women, usually - often mothers of the RG blind men - usually called tetrachromats) get a 5th receptor somewhere.
But the _4th_ receptor that everyone has is basically ultraviolet. Most light in this spectrum is blocked by the fluid in our eyes, so we get very, very little of it. But it's why those deep violet LEDs look so neat - they're not in the 3 receptors we get the most use of.
My 'usually' above might be 'always'; I can't remember.
Flash support for Linux has not always been great. An earlier version was so behind they SKIPPED it. But the RECENT versions are coming out for Linux very quickly; they made a decision to make Linux more supported. (And that's why they skipped a version; the new one was now on a respectable timeline.)
So, yes, it has good Linux support. Also, keep in mind that Adobe acquired Flash (as part of Macromedia) right in that time period; Adobe's track record with Flash on Linux is strong.
To clarify Flex a bit:
- Compiled Flex applications run in Flash Player; it's not an additional plugin.
- Flex applications use ActionScript 3, which is the same programming language that the newest versions of Flash use. It's structurally Java-like, but it's very easy to get powerful things done - for instance dynamically loading and playing a remote video stream can be accomplished in a few lines.
- Flex doesn't require the 'timeline' paradigm with binary source files that Flash had, replacing it with a solid and powerful layout language, making Flex a tool for app programmers rather than for animators. But there's huge crossover - and some workflows involve both tools because it trivially can include assets and videos from Flash.
- Flex Builder isn't free (unless you're a student) But the compiler IS free. So "Builder" is really like buying "Dreamweaver for Flex" more than like buying Flex. (Flex Builder is actually based on Eclipse, not on Dreamweaver, though)
And the license for OS X!
If you're buying a Mac to put Linux on it, you're probably wasting money. (Unless you're buying a zillion of them and getting a discount) OS X is like that Lenovo one, maybe... except for me the OS X vs Windows difference just dwarfs anything else.
Maybe IBM did it first, I have no idea - but I know the Macbook Pros, at least, have been doing this for a while now, too.
IANAL, but it seems to me that someone who purchased a Kindle2 prior to this announcement with the expectation that it would TTS everything would be able to sue. Or at least publicly demand a refund for their Kindle2, all titles purchased, and any shipping they paid for. (A refund I imagine Amazon would not normally allow).
I agree that the right way to fight this is not to buy DRM products, and I know several people not buying a Kindle just for it's DRM issues.
Your problem isn't with 'webapps' - which can do EXACTLY what you've just described, and we do it all the time in Flex and Flash. Your problem is with 'terrible webapps'
Oh, and as long as you bother to twiddle with the paths so it knows where to look, those apps DO run locally if you want them to - OR on the web. But voila, no platform issues, and the local disk access is optional.
Any "IE-only" web app is not a good web app, in my opinion.