The PDF export feature sounds great - but even something simpler like a CSV, JSON, heck even XML would give others a lot more freedom to handle the data however which they choose.

> Users who do "Ctrl-S" to do fast save are certainly a minority.

My first reaction: How else do you save?! You mean you actually take your hands off the keyboard, and click the floppy icon in a toolbar? Or even.. click on File > Save? Seriously?

I think this assumption as a very strong population bias.

With the people I work with.. it's all about keyboard shortcuts. If you don't know your basic keyboard shortcuts, you're too slow. But then again, I work around people with super customized Vim and EMacs configs and people who live in Photoshop/Illustrator all day. You just can't be productive in those environments without keyboard shortcuts.

For me, users who don't do "Ctrl-S" to save are certainly a minority.

Agreed. I also used ctrl-shift-p to preview Github comments with similar frequency while composing, and get frustrated when I get print dialogues in my mail window.

It's about intent. If they can prove you manufactured data you fed to the dongle, then you're probably in for some trouble.

However, you can have a similar scenario where maybe I work at an office 5 minutes from home over the time I was carrying the dongle, I quit and go to a job 60 mins from home that crosses a few nasty neighborhoods, etc.

Is it my burden to report this to the insurance company so they can jack my rates because my risk rating surely went up?

Right now.. it likely isn't. I fear for the day when it is.

It's not just the visuals either - they have a bunch of the apps down really really well.

Finder, Calculator, Calendar, the top menu, etc. All really spot on.

I'm playing around in it still. Managed to find my way to the Terminal, and I'm poking around the filesystem.

It is Linux, and seems to be based on a stripped-down version of RedHat (going from some of the remnants of certain man pages).

The UI is a modified/themed KDE.

They did a really good job with the apps - for example, the calculator app is "Calculator.app", which is really a directory with a Contents/Resources, etc directories inside it; the same way OS X does it.

It would seem like they used Red Hat for the SE Linux implementation(?) but should have just used BSD.

It's just good security practice.

Even if the code path is never intended to be executed, there are bugs in code that could lead to it.

Yes, it's a P2P protocol, but when you're managing a bunch of servers, you don't use it as such.

You set up one server in your environment (time.example.com) and have all your boxes sync to that.

Why would appserv.example.com EVER need to be able to accept NTP connections from anyone else?

You are looking for ntpdate executed regularly from a scheduled task. Its a sawtooth drift/snap pattern but it seems to be good enough for MS.

That said, a slightly configured ntp doesn't ever accept ntp connections from anyone else. Thats not like a requirement or anything.

Run it in client only mode and it won't

There is still a lot of crypto out there that works off of using the current timestamp as a seed.

Being able to control he time could theoretically let you control any PRNGs that rely on it.

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.

You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server.

There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.

Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.

It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

> The much bigger issue is with hardware that doesn't have a local clock/battery.

Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway.

> Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).

The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually.

Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.

If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.

Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.

Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).

Group threads are done over MMS. They absolutely do exist out of iMessage.

I had never heard about them. Are they standard'

Not part of standard SMS, but it is a standard: http://en.wikipedia.org/wiki/Multimedia_Messaging_Service

I actually meant group threads.

Group threads have been implemented as MMS on all major smartphone operating systems. Unfortunately, Android didn't get it until Android 4.2 or something.

The key is that the recipient list is sent with the message, so the other clients know who else is participating in the group, and can also thread and send outgoing messages accordingly.

There is a difference between the USPS tracking mail to ensure it does not get lost and the USPS giving that information to the FBI or other law enforcement agencies.

IBM has its place, especially in the big enterprise. However, more and more I'm seeing that's not the case.

Working for a big insurance co., we're seeing a big shift toward a "devops-like culture", and a lot of the time that means less IBM.

IBM not only needs to refresh their offerings, they need to refresh their image. The common feeling around here is IBM products are slow, buggy, and pieced together quickly from a ton of other acquisitions who are then "IBM-ized" together.

They look beautiful on paper, in a way that speaks to both execs and real tech people alike. But once you build it out and start trying to support it...

WebSphere, calling it a bloated, buggy, outdated, overpriced pice of shit would be a compliment. I'll do PHP before I do WebSphere. I'll go jobless before I do WebSphere.

> They look beautiful on paper, in a way that speaks to both execs and real tech people alike. But once you build it out and start trying to support it...

To be fair, you just described most enterprise software systems. :)

I think you mean "most software systems", period. :-)

I don't know about that. Most software can be bad, but enterprise software tends to be a special kind of bad. The big problem with enterprise is that the buyers are not the users. Therefore, the incentives are not aligned and the result is extremely poor quality software.

I agree with most of what you just said, but that doesn't really contradict what I said. I guess I could have been more verbose, but I meant to reply to:

"But once you build it out and start trying to support it..."

which suggests that the topic is something like "systems that start out elegant, pristine and pure, and slowly accrete functionality and complexity, and become brittle, unstable, and hard to maintain and support". And I posit that this applies to pretty much all software, not just "enterprise software".

I mean, there's a reason we have aphorisms and memes like Greenspun's Tenth Rule[1], Zawinski's Law of Software Envelopment[2], the Turing Tarpit[3], the Inner Platform Effect, etc.

[1]: http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

[2]: http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...

[3]: http://en.wikipedia.org/wiki/Turing_tarpit

[4]: http://en.wikipedia.org/wiki/Inner-platform_effect

Yup. The ship can be saved (and probably will - they have many smart people), but it's not clear how yet. Currently they have a major brand problem among the young generation.

I grew up when IBM still had a cool factor with Team OS/2, etc., but other than BlueMix there's not much left.

The Python script is a bit unnecessary.

Go to System Preferences > Spotlight. Uncheck items you don't like to have searched and displayed for you.