Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment The phone is just a small part. (Score 1) 546

The phone is just a small part of the puzzle for an investigation. You can't blow something up with *only* a phone. You have to move around, communicate across public networks, and physically acquire elements. Sure, having the data on a phone with documented communications might be handy, but it's not strictly necessary for any investigation of physical activity. Saying it is, is just being lazy.

Comment Re:the reason why (Score 3, Informative) 146

No you can't.

Wrong. You absolutely can use pre-generated keys for google's authentication services. They call them backup codes.

Authenticator runs on a phone or tablet. Without internet you can't even set it up.

Wrong again. You can absolutely setup accounts in Google Authenticator (And most other similar apps) without network access. You can even install the app itself without access in many cases, if you want to side-load from a PC or something.

Without perfect clock sync the codes generated by authenticator stop working.

Sorta wrong. The clocks don't have to be perfect, they just have to be close. Pretty much every service has the ability to deal with a certain amount of clock skew. Smartphones these days are pretty good at keeping time, even when not connected to the network, so this usually isn't an issue. But this is also dependent on if the service is using TOTP or HOTP. (Time based or Counter based codes)

The codes generated by authenticator have a very short shelf life, measured in seconds.

Here you got one right, every code has a 60 second lifespan. (:

But to the point of the original post (GGGP?) that brought up the autheticator... They should at least have HOTP/TOTP as an option for those with smartphones in this case. They probably can't drop SMS altogether because of the users that *don't* have smart phones, but no reason not to support both.

Comment Wrong (Score 4, Interesting) 151

I generate this data. I own this car. This is my data, not the company who made my car. If it's a rental, sure, go ahead and do what you want with that. But if I own the car, that data is MINE to choose whom I give it to, or don't give it to, and use as I see fit.

This isn't any different than any other appliance or device. I own my computer, The manufacturers that made it don't own the data that's created by using it. Tired of companies thinking they own what I do with the stuff they sell me. It's getting ridiculous.

Comment Re:Solution in Search of Problem (Score 1) 837

Electric vehicles and hybrids can't be the reason. Electric vehicles still represent a tiny portion of vehicles on the road. Hybrids don't really get much better fuel economy than the tiny econoboxes of the 90s.

This is pretty short sighted, and my hope is that you are not on any committees or groups planning for anything in the future, as you seem to not be able to think ahead. EV's are a small segment now, but it is growing fast, and there will be a point in the future where it will become an issue having EV's essentially free from any sort of tax that allows for maintenance on the roads they use. Oregon is simply experimenting with ways to work through that scenario, and working on a plan for the future.

Comment Re:Lennart Poettering is cancer on the face of Lin (Score 1) 347

You know the stupid Cloud rage going on right now, systemd allows Linux systems to be rapidly deployed there.

You lost all *your* credibility there. systemd has absolutely nothing to do with cloud deployment, if anything, it complicates existing tool sets that are already being used for cloud deployments, because it obfuscates underlying process making it even harder to debug mass deployments.

I guess the problem is that systemd is heavily dependent on Linux, whose "developers don't understand the arguments of simplicity, composability, and small programs that do one thing well", to quote you. These developers (Linux kernel and systemd) only understand the arguments of programs that just work, are robust, adaptable, coherent, fast and efficient, easy to use, difficult to break, the most secure possible.

Robust? Efficient? Easy to Use?Just Works? You might be talking about the kernel, but you're definitely not talking about systemd anymore. I would put good money on any kernel developer pissing in your coffee just for saying systemd architecture is anything even remotely comparable to the kernel.

If it ain't broke, don't fix it. The old init system worked just fine. So what if it was scripts, scripts are the heart of any unix system, and have been for years. So what if the more complicated your app was, the more complicated your init process was. Using systemd isn't going to make your special purpose Linux OS any simpler, it still has to do the same damn thing. It's only going to hide that complexity in yet another tool.

Comment Accountability (Score 1) 60

Something I've rarely heard discussed in any of the patent reform discussions is accountability. It would make total sense to hold the Patent office accountable for the patents they approve. Particularly when they are proven overly broad or killed off by prior art. Sure, you can't do it immediately, but if a patent is invalidated for legal reasons, then there should absolutely be blowback to the patent office that approve the thing in the first place. You would probably have to define some criteria for meeting guidelines on complexity, but at some point you have to hold Joe Blow accountable for rubber stamping a patent like this example that's so blindingly stupid. i.e. he's really bad at his job, get freaking rid of him!

Without proper accountability, I don't think there will ever be meaningful reform.

Slashdot Top Deals

If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy.

Working...