Never happier than the day we got a VIC-1541 and put the days of pressing play behind me.

I never really questioned it. Mainly because I started with Basic, but quickly moved into 6502 assembler on the C64. Really stupid example that creates a 30 element array on the zero page with the set [1, 4, 7, 10, .....]

        Array = $00

        LDX #$01
        LDY #$00
loop:
        STX Array,Y
        INX
        INX
        INX
        INY
        CPY #$1E
        BNE loop

If I started my index in the Y register with 1 my first element would have been placed in memory location $01 and the array would have been 29 elements long. Instead I start it with 0 and my array goes in $00 through $1D and consists of 30 elements. It had always been my assumption that 0 indexed arrays were a carry over from this.

There's no reason that a high level language can't use indexes that start with 1. It just feels really strange to me using a language that does.

It gets taxed via AMT (alternative minimum tax) in special cases. If your company gives you ISO stock options (as my wife's company did), you have a strike price and a vesting period. Once your stock option vests and you exercise it, you realize an on paper gain in wealth of current value of the stock less the strike price. You owe the AMT on this paper gain, which is treated as a pre-payment of any cap gains you'll owe when you sell it. So you hold it a year and then sell for cap gains long. If cap gains taxes are more than what you paid in AMT, you pay the difference. If it's less, you don't get a refund for a year. Since we're not rich, we did a straight sale when the option vested and paid income tax. :P

It would have been more money in the long run if we'd had the money to do it the right way. We could have swung the strike price, but the AMT would have killed us. Plus we just decided to go with easy as the headache for the difference was just not something we'd want to deal with anyways.

I've given up on wondering. The kleptocracy always takes over.

At this point I only wonder when they'll manage to pull off our own extinction level event.

From their terms of use:
"We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."

So yes you can view and fork, but you don't get clone rights. The instant you do that, you infringe the copyright. So if you have no license that allows you to put out on your machine and use it, how useful is it? Until copyright or the Berne convention are changed, this is the world we live in.

So if your system clock is off by more than 5 minutes, does Kerberos disappear?

Yeah, my first thought was, "giant douche tries to explain why he isn't a turd sandwich."

Regarding the 'thousands of patents claim ours as prior art'.... Yeah, it's so broad that to do just about anything near audio and the web, you'd need to cite it too. That's become the main problem. They claim not an invention, but the entire domain of the invention and several others at the same time.

Seeing the work load that patent examiners are under, that the examiners do not appear to be skilled in the modern art of computers, the fact that granting patents is the way for the USPTO to get its funding, that it's just cheaper to pay the troll than to try to get a re-examination or go to court, and companies that are more than willing to just keep amending a patent until the examiner caves..... The system is just broken and it's beginning to seem easier to throw the whole stinking pile out and start again.

The only thing in 4.0 that I could agree with you on is that 4.0 added a face detection API (in fact it was the only API change in android.hardware for 4.0). As far as a wrapper being not fun/onerous.... That might confuse a Java 101 student and yeah, wrappers aren't glitzy, but you do it everywhere. Any time you need to account for hardware or OS options you have to do something (this goes for iOS and Android). In this case you do everything you would have done and if the version is less than 4.0 don't do the face detection or offer the option. Someone above claimed 3.0 made marked improvements in the Camera API. The ability to use an OpenGL ES surface instead of a SurfaceHolder for the preview window is certainly nice, but... If you want to use it with fallback support it is as simple as detect version of Android and inflate the SurfaceHolder layout for 2.x devices or the SurfaceTexture layout for 3.x+ devices. SurfaceTexture is where you need to add all sorts of code actually displaying the preview. The SurfaceHolder version doesn't need any code.

Hey it's their app and I'm not saying that they shouldn't go ahead and make their own decisions on support. I will say that for what this app does, the no 2.x/3.x support makes me question the skill of the team behind this. Could they be planning to go back and add back support? Sure, but it's much easier to just bake it in from the beginning.

Almost the point I was going to make. I'd hate to see the code behind this. First of all, if you are supporting the rear camera, the front camera support is all of 5 minutes (button in the UI, and passing the constant for front or rear camera based on the button state).

Then I read that they are only supporting 4.0+. Seriously? You can do everything they're doing there with the support jar and include all the way back to 2.0. If you want to do it nicely just pull in ActionBarSherlock and PageIndicator.

How in the hell do you figure that? Fork has fuck all to do with the definition of multi-tasking, true or otherwise. Fork is a C language construct that has been carried up into other languages that is only one way to spawn a new process. But even if it were the definition, I can call fork from Android JNI or NDK code (severely frowned on, but doable).

In android I can spawn services and use broadcast receivers to do exactly the same thing as fork()ing a child and communicating across a pipe. Same semantic, different implementation.

Multi-tasking is the ability of the OS to run more than one process at a time. Whether it is preemptive or cooperative, time slicing on a single CPU or multiple CPUs. If the OS allows multiple processes to be launched, regardless of whether those processes can fork() children, it is a truly multi-tasking OS.

And how do you figure this? WebOS has true multi-tasking as does Android. iOS has multi-tasking for Apple's apps and a limited multi-tasking for everyone else.

Or do you mean multiple windows on the screen at once? On phones that's just silly (screen size makes it impractical). On tablets it's a decent idea and Samsung(?) has done that with Android. The one thing is, how many times do you really need two windows up side by side? Plus since the devices are mobile and power is at a premium, showing only the app the user is interacting with is a really good indicator of which apps need to be quiesced. Any time I'm writing an Android app and I need to do something power intensive that does not need to be long running, I immediately start thinking about how I'm going to implement onPause().

And if not fail2ban, a good first step is updating the firewall rules to have a rate limiter on sshd. Mine allows only 2 attempts to connect a minute.

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --set
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 2 -j DROP
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

It is and it isn't. Java is just convenient because so many programmers knows it. What runs on Android is very different than the JVM. Dalvik is register based (therefore faster even though the code size ends up bigger) than the JVM, which is stack based. The toolchain is that the java is compiled to java bytecode with javac. That bytecode is translated to Dalvik's bytecode.

There is absolutely nothing stopping you from writing a compiler to turn any language you want to use into Dalvik bytecode. At that point you'd be able to use that language with never any java code visible.

Unfortunately, he didn't go full out and say they weren't. He said in some cases they MAY be copyrightable, but not in this case. What we need is a clear precedent that says the name, arguments, and behavior is not copyrightable. The implementation is. So it is a fact that Hashtable lives in java.util. It's member methods and their arguments are facts. Key and value not being able to be null is a fact. Put all the facts together and create your own implementation.

Saying that behaviors and facts are somehow subject to copyright is a really bad idea for compatibility, but perfect if you want to go back to vendor lock in.

Disable WPS or if your router doesn't allow you to do that, buy one that does.

Change to WPA2 and use a long, random key (a non-sense sentence will work too). Yes, it's a pain to have to set your devices up again, but it's the only way to take away their access.

Hiding your SSID, MAC filtering, etc. will do nothing if the script they are using is somewhat intelligent or if they have a more than a passing knowledge of what they are doing.

And if you don't want to just foist this issue off on someone else, help your neighbors to do the same.