Gimp uses dbus to do a named pipe to the running instance if you launch it from the CLI and there is already an open instance under the current users context that tells it to open the new file within the existing instance, and dbus is now part of systemd. There are alternative ways to package Gimp that don't use dbus since it also run on Windows and other platforms, that just happens to be the simplest way with the current Gimp source tree. A LOT of what systemd is about is easing thing on package maintainers.

If Google fixes it in AOSP then you can at least grab a fixed version with Cyanogenmod or other custom builds. At least for tech folks the main thing holding them back from moving up may be device drivers for the newer kernel.

It's not in the current builds yet.

Have you tried delivering the same level of automation to your Mac users that most corporate Windows users get?

Honestly, no, because it's ~2% of our user base so you would never get an ROI on the tools or the time to learn them. Now for an F-25 2% of the userbase might be enough justify a team to purchase and learn Mac specific tools, but for those of us in the SME space there's no way it works out. Now, the MDM angle is interesting, I'll have to look into what support Maas360 offers for Mac, but it doesn't change things like no GPO equivalent to manage settings and the fact that Apple does things like ban older versions of JRE from running (we have a handful of systems that require ridiculously old version of the JRE, under Windows I can just whitelist them for those sites)

Huh? I bought my Galaxy S5 Developer Edition directly from Samsung and use it on Verizon with no issues, we also buy iphones from Apple and use them on Verizon without any problems. The main issue with Verizon is that you need a phone that supports their bands, which until recently was only available through them as they tended to be one offs, now Qualcomm is including almost all bands in universal chips and the 2g/3g chips tend to have support for both GSM and CDMA. Now I will grant you, before LTE brought SIM cards to Verizons provisioning process the only way to effectively get a phone activated was to buy it through them so the IMEI was in their supported database, but these days it's rather easy.

The only job I've ever been drug tested for was one requiring clearance.

The other thing is that they are also freeing up a tremendous amount of tax dollars from the general fund by not arresting, trying, and housing non-violent drug offenders. My guess would be those savings absolutely dwarf the tax revenue. Also there's a societal benefit, fewer people labelled as criminals means more people able to access gainful employment outside menial entry level jobs which should lead to a higher GDP.

Uh, Windows 10 uses the same driver model as Vista, 7, 8, and 8.1. It even comes in a 32bit version (8.1 was supposed to be the last 32bit Windows, but MS must really want Enterprises with broken legacy crap to move up) so as long as your printer has a Vista+ driver you should be fine.

Actually, it's going to be a bit cooler than that, if you have a touch device then metro apps will by default work like they do in 8, if not they'll be windowed, and if you have a convertible like the Surface Pro line then it will change behavior depending on the current configuration (again, by default, MS has heard the masses and will allow you to tweak the behavior).

Windows 10 is where the enterprise is going. I literally just got out of a meeting where we were discussing our goals for the year and Office 2013 and probably Windows 10 (depending on launch date and apparent buginess) are on the list. As far as your MBP, that's fine for you if you work in IT, but if you think most businesses are going to give every worker drone an expensive Mac with about 5-10x the support cost (as in I have numbers that show our Mac users cost that much more depending on their level of competence/IT independance) you're delusional.

Most apps use MMS which does include the equivalent of To: headers so all the parties can see who's in the conversation and you can do a reply all.

DMCA is evil, all of it.

Not at all, the compulsory licensing parts of it are why many services are available in the US and not in other countries and the safeharbor provisions are probably the only reason we still have search engines.

Uh, no from the paper they are hijacking an existing challenge/response session with a valid signed SAML assertion but exploiting a weakness where the code that validates the assertion and the code that reads the claim token are not necessarily checking the same part of the response and so they can insert a bogus claim ticket with a valid assertion. This would require intercepting the assertion response and modifying it, and since the whole conversation is within a TLS session it requires some kind of MitM attack.

But thinking on it further, you could use it as a privilege escalation attack, use a compromised user account to receive a valid assertion but modify your response to include the bogus claim ticket to login as a more privileged account, that's a lot more concerning as it's a lot easier to compromise a single account then pull off a MitM attack.

That's cool, and I appreciate the security researchers and their work to strengthen both protocols and implementations, but in the real world the entire conversation happens inside a TLS stream so it's not that easy, not only do you have to insert yourself into the communications path between the user and the resource, but you have to break TLS in realtime. It does increase the scope of attacks like BEAST/CRIME/POODLE a bit, but since that paper is almost 3 years old you would hope that at least the major providers have patched frameworks in place.

SAML has all authentication happen at the IDP (user organization side), not at the relying party/service provider so any login attempts are at your SAML endpoint. In theory you could even not allow passwords at the SAML point at all (if you have all your machines Kerberos joined you could use the Kerberos claim ticket to generate the SAML assertion and not have an alternate fallback authentication method, but for convenience and interoperability that isn't usually the case and there's generally a forms based login, in our case we have 3rd parties that use our cloud resources and have accounts in our authentication realm but not machines supplied by us so a forms bases login is a requirement). If an attacker wants to try to brute force one of your logins they have to do it at your SAML endpoint which you can and really should monitor tightly with all your normal tools, in fact since it's a single source of failure for security (the flipside of single signon) it should be better monitored than your average server.