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.

He didn't say he wasn't informed of _what_ he was going to do, risks, etc. He just wasn't informed of WHY he was going to do it.

IRB doesn't generally require that.

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.

Here in the US, we have government issued IDs. And they're required for plenty of things, especially in person. We don't have the Post Office as part of the system you're referring to, but that's not the biggest problem.

The problem is that there's no possible way to even reasonably verify whether a moron is who they think they are online without having already laid some groundwork. (Like mailing something to prove address) Anything they can know, someone else can know. And as a parent mentioned, the skip-tracing people have AT LEAST as much information as a major credit card you just applied for - available for a couple $.

And the credit reporting agencies and credit companies here want you to be able to get drunk and call up and apply for a credit card and get instant gratification for it with no verification whatsoever...

They ought to have to at least mail you something at the address on your credit report and call you at the phone number on your credit report. If the credit reporting agency wants to do that and setup a secret PIN with you, you could share that secret with a credit card company...

They DO mail your PINs out, so you can't take too much direct cash from a fraudulent app - you can only buy an infinite quantity of goods. So that proves they know how to keep it safe - they just don't value ensuring that you're the right person to give credit to... because the incentives aren't in place.

Flash has issues, but there's no superior product it beat out. Java is CONCEPTUALLY superior, but it didn't pan out - partially Sun's and partially MSFT's fault. ActiveX is more powerful, but is even conceptually a total lack of security and has no crossplatform support.

Since I haven't used it, hypothetically Silverlight could possibly be better, but I personally, based on their long track record, just don't trust MSFT to be even reasonably secure or to play nicely with others.

Flash video does tend to take 100% of your CPU... no matter how fast your CPU is. But youtube plays on pretty modest CPUs, so it doesn't require an especially fast CPU... it just uses what CPU it can find to make your experience better. And it's better in each version of FP. I agree, that's an issue if you're playing video on the web in the background. For some reason. Although, there are plenty of players for FLV and MP4 that aren't Flash Player... like Quicktime.

As for overlays, there's no reason to do that. That is, while you might not believe it, Flash Player isn't a video plugin like Quicktime - it's a full fledged OO programming environment. So you can put whatever you want over your video whenever you want, with a little programming. If you want to create a standardized overlay spec in XML so it's shared by a lot of players, you could do that. So the only thing you're missing is the ability to create overlays IN your video editing software, instead of in Flash... which would have to be a much more limited functionality than the complete programming language that ActionScript is.

I'll take being able to program truly interactive video over supporting overlays, any day.

I think the previous poster is on target - it takes a long time to build a clientele where they keep coming back, so you're consistently busy instead of just occasionally busy.

But if you're good (or anyone else reading) we might be interested; we definitely mange independent part time remote developers, and I think we're going to be a bit shy in Java.

Let's say dev-slashjava@xig.net for this. Send what you can in terms of resume portfolio.

arete