Forgot your password?
typodupeerror

Comment: Risks vs benefits and tradeoffs (Score 1) 170

by Dr. Manhattan (#47851303) Attached to: NYPD Starts Body Camera Pilot Program

However I think there is a real danger of honest mistakes being abused, and like I said most of the abuses I know about used those.

If the cameras are only under the control of the people they are supposed to be monitoring, they will wind up being used only to clear, never to convict. I don't want the police getting any access to the videos that the accused doesn't have.

Honest mistakes are already 'abused' in our legal system. Cameras add nothing to that. But they can - if the system is set up properly - reduce a whole host of other abuses.

Comment: Nope. (Score 1) 170

by Dr. Manhattan (#47836617) Attached to: NYPD Starts Body Camera Pilot Program

Let's be clear, does the policeman misremembering and event change what actually happened in anyway?

Doesn't change the event itself, no - but a pattern of errors can speak volumes about intent and state of mind. And many crimes (and torts) depend on intent and belief. So, note, do many defenses.

What is being unsaid is that you are accusing either side of lying to cover up and thus the lying person must be a bad person worthy of punishment for that reason

No. I am, in fact, relying on the deterrent effect of the video. I am trying to prevent lying, not catch someone in a lie. If you know your actions are being monitored, you will behave differently and note what happens more carefully. I'm not trying to 'trip people up'. I am trying to help make it so that testimony is actually accurate. If people are given the opportunity to slant their narrative, they will - this a human thing, hardly limited to police. By reducing the opportunity for this, by requiring people to more carefully examine their memories and words, I'm hoping to make "our justice system" better.

Comment: Re:Who gets access to the video? (Score 4, Insightful) 170

by Dr. Manhattan (#47835251) Attached to: NYPD Starts Body Camera Pilot Program

Why, have you never remembered an event wrong?

Sure I have. So what? If police misremember the event, is that somehow not relevant?

The behavior of everyone will be plain to see on the video

That was actually caught on video, that is. As I explicitly pointed out. I spoke - direct quote here - about the ability "to craft a story that fits what was recorded, and leave out or invent things that weren't picked up". What happened before, or just offscreen? Police are known to claim that someone was "reaching for a gun" - even when it didn't happen. But if the camera angle is bad, they will know they can claim that regardless of what they actually remember.

every lawyer knows the trick of picking out one detail someone got wrong and spinning that into proof that everything they say is a lie

But... but... if "The behavior of everyone will be plain to see on the video", how could a lawyer get away with that?

Frankly, I consider that a feature, not a bug, anyway. Eyewitness testimony really is ureliable. 'Bout time juries learned that applies to police too.

Comment: Who gets access to the video? (Score 4, Insightful) 170

by Dr. Manhattan (#47834479) Attached to: NYPD Starts Body Camera Pilot Program
Is it the police only? Defense lawyers with a subpoena? The public? There's this:

Officers would be permitted to view video they recorded before making statements in cases where their conduct was questioned

I would vastly prefer they make statements without access to the video. Seeing the video allows them to craft a story that fits what was recorded, and leave out or invent things that weren't picked up. If they don't know exactly what the cameras saw, they have to stick much closer to the truth.

Comment: Also, Palm OS Companion (Score 2) 170

Documentation put out by Palm that covered most of the API and such. Still available here: http://www.cs.uml.edu/~fredm/c...

The main difference in OS5 was the addition of "PNOlets", chunks of native ARM code. Chapter 14.

It's still tricky. When I ported Palm's OS4 emulator to Android, I had to do some library coding and tracking down sample source code was... nontrivial. Definitely look for open-source Palm programs, like pssh, and learn from them.

Comment: Re:Bigger phone batteries would be nice. (Score 1) 119

What the FUDGE are you doing in the woods where you want a Cell phone on all the time?

Staying available in case my wife or any of my kids who aren't on the trip have a medical emergency? I apologize for having purposes that don't meet up with your approval, or enjoying myself in ways that you frown upon. I will re-evaluate all my life choices in light of your preferences immediately.

Feature phones work better in areas of sketchy cell service. Their battery life is very long. The battery requires less power.

I agree. But that means I have to have multiple cell phones for different purposes. Which brings us back to... Modern phones do a lot more, and a lot faster, than older tech... but I admit I miss the battery life of the old Palms. One month on a couple of triple-As. Not having to charge my phone every single night would be pleasant. Wise words indeed.

Comment: Re:Bigger phone batteries would be nice. (Score 1) 119

Solar battery takes care of the problem.

Not in Michigan woods. Not even in the middle of summer, with several days of clear skies, using this. And yes, I speak from experience. Especially when you're in areas with poor signal that drain the battery faster.

Leaving aside issues of unexpectedly not being near your chargers for too long even in day-to-day life, etc.

Clearly you're happy with your battery life. Congratulations, felicitations, mazel tov, and so forth. That doesn't mean that people who are not satisfied are wrong, however.

Comment: RAM (Score 1) 236

by Dr. Manhattan (#47476179) Attached to: Nearly 25 Years Ago, IBM Helped Save Macintosh

My own 486 had extremely dissappointing performance when compared to a even mere 68000 until RAM prices became low enough to adequately equip a PC.

True. I was astonished when I invested a decent chunk of change and bumped my 100MHz 486 from 16MB to 64MB of RAM. Multitasking actually became practical, especially running Mozilla alongside something else. Of course, the 68K Macs of the day weren't that much better at supporting 'a browser and something else'. The cooperative multitasking of the Mac OS helped reduce overhead, but it still took RAM.

Comment: I always wondered about M68K. (Score 1) 236

by Dr. Manhattan (#47474203) Attached to: Nearly 25 Years Ago, IBM Helped Save Macintosh

And the 68k platform seemed to be neglected by Motorola.

It sure seems like the M68k architecture could have been pushed forward more. Yeah, it was CISC, not RISC, but it was a very clean CISC. Modern x86 chips are really RISC machines internally, they just have a bunch of translation from the CISC instruction set to the 'real' ISA inside. If nothing else, that approach could have worked for M68k, right? Probably better, since the basic M68k ISA isn't so crufty and ugly like x86.

Comment: Actually, it needn't be a technical issue. (Score 1) 230

by Dr. Manhattan (#47179559) Attached to: Intel Confronts a Big Mobile Challenge: Native Compatibility
As I just got done saying in a comment above: Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.

Though I do agree that JNI is a serious pain. On the other hand, I've developed for Netware and Palm OS, so my standards for pain are probably artificially high.

Comment: Not useful to me, but I'll support Intel anyway. (Score 5, Interesting) 230

by Dr. Manhattan (#47179509) Attached to: Intel Confronts a Big Mobile Challenge: Native Compatibility
I made an app for Android - ported an emulator written in C++. (Link in sig, if you're interested, but this isn't a slashvertisement.)

So the core of the app, the 'engine', is in C++ and must be natively compiled, while the UI and such is in Java. Naturally, the binary's compiled for ARM first. This actually runs on a lot of Intel Android tablets because they have ARM emulators. But, thanks to a user finally asking, I put in some time and now I can make an Intel version. (Heck, the original source was written for Intel anyway, so it wasn't a big stretch.) The existing tools are sufficient for my purposes. And it runs dramatically faster now on Intel.

However, for the developer it's mildly painful. The main issue is that you have a choice to make, with drawbacks no matter which way you go. You can include native libraries for multiple platforms, but that makes the APK larger - and according to a Google dev video I saw, users tend to uninstall larger apps first. In my case, it'd nearly double the size. So instead I'm putting together multiple APKs, so that ARM users get the ARM version and Intel users get the Intel version - but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.

Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.

1 + 1 = 3, for large values of 1.

Working...