I don't think you are going to reach an accord on Powershell syntax. I personally find it tedious, and frankly the Verb-Noun thing is backwards (Noun-Verb would have worked better, I don't need to know all the things I can 'Get', I need to know the things I can do to a Disk). That said, there is a convention, which is something that cannot be said for the more diverse set of shell commands.

In general the two camps need to recognize the situation for what it is. Empowering Microsoft shops to manage Linux workloads. It isn't going to win over a Linux shop to start using Windows if they don't already.

Powershell works that way because MS controlled the development of the vast majority of components that normal people interact with. It delivers a framework to let third parties do it 'the right way', but there's a lot of missing stuff and when you interact with the few CLI friendly executables that existed, you are right back there.

Basically, you could use 'python' as a shell and have the same benefits, complete with the awkwardness of interacting with non-python executables. In MS world, this is less disastrous because non-python executables were pretty rare anyway and they did a good job of chaining instead to .Net stuff.

This is pretty misleading. OMI is Microsoft's pet 'standard'. They know the politics of DMTF to get things the 'standard' rubber stamp, but it has no bearing on actual applicability to the general environment. Basically going OMI means a pretty crappy set of flaky abstraction/instrumentation has to be put on the target that doesn't actually provide any more value than the open source competitors. CIM/WBEM has long languished for lack of anyone wanting to do it, and MS is trying to force the issue by doing OMI.

The 'article' is an editorial presented as something to be taken as representative of the community at large. My impression is that Canonical is losing mindshare quickly to Mint on the desktop, that Canonical really doesn't care that much about desktop anyway as they pin their business hopes and dreams on servers and embedded (where it also is failing to get much traction business wise).

Note that none of this has to do with the parents referenced points: Gnome 3 (which is largely defined by Gnome Shell, which Ubuntu doesn't even use by default) and systemd (I'm sympathetic, but not sure it's making much of a difference either way in the desktop distribution selection right now).

I suspect that the situation is more complicated than that. Multiple recording labels, multiple interests. All the licensing of the music would revert to square one, with all the current copies having to be disposed of.

The world of intellectual property is too complicated for this sort of thing to be easy, sadly. I also never used Grooveshark. I'm still mostly a broadcast radio kind of person when it comes to music.

Yes, in that scenario, you aren't restricted by firefox's proposed BS. Disabling https would break mozilla browser access, but not such software.

I still think it's an inadequately thought out concept (I also question the wisdom of 'the only network protocol is http' mentality in the world), but out-of-browser development shouldn't be hurt too badly.

Now I won't go that far. 'everywhere' is a pretty gigantic scope. There are many scenarios where there are no viable debug capabilities on either end of the connection (either because no such capability is implemented *or* you are dealing with some 'clever' appliance that blocks you from access.

Besides, wireshark's dissectors are incredibly useful, and usually beyond other things ability to decode. In the case of *browsers* specifically it's not true these days, but plenty of networking things aren't at that level.

While TLS *could* be secure, I've been in too many discussions where it is assumed to be the only way to be secure and that it is secure in spite of the current state of CAs and the practical behavior of internal servers with respect to certificates.

There really needs to be more critical discussion along this front, as I see quite reasonable security strategies that fare well in the *real* world torn up and replaced with TLS because of an idealized view of how it could be implemented.

Wireshark is a useful debugging tool. The ability to snap off encryption to analyze things at the wire is a lifesaver.

That said, if I'm debugging something a browser is doing, the developer console is usually better anyway. There remains the case where you are trying to debug a tester's experience without access to their browser, but the scenarios where that is true *and* it would be a good idea to disable TLS are limited. Being able to disable encryption is more important for clients that aren't so developer-enabled.

I agree that the more intelligent thing would have been for the site branding to be used for legitimate service rather than trying to shame the users while pointing out other services and hoping for the best.

However, the likelihood that they could have modified it 'slightly' while 'not pissing off the listeners' is pretty slim. The music selection would have had to be torched and started over from scratch (too many content owners without an agreement between them) and something would have had to give to actually extract revenue.

They didn't quite get to 'just walk away'. They were given a choice, an impossibly high fine to pay or hand over all their patents, copyrights, infrastructure, software, basically everything while very publicly scraping the ground about how wrong what they did was.

Essentially, they had something of value that was interesting to the plaintiffs that was bigger than their realistic chances at getting actual money out of them.

Owncloud is not a cloud *service*, but a platform for creating your own (I actually prefer Seafile incidentally).

Ditto for K-9 mail, not a service, but an app.

I would go further and say that while before some projects would feel some pressure to do cleaner packaging and deploy better alongside other applications and into 'OSes', many are starting to say 'here, just take a container' and never fix packaging issues because... container! What is a good workaround for some fundamental limitations has become a crutch to be extraordinarily lazy in packaging.

If you get a *better* offer while working at one place, sure an H-1B has at least that ability.

However if they get laid off/fired, things can get very rough fast. So an H-1B holder has a lot more to lose if they can't survive a layoff or get fired. Sure there is a grace period, but depending on the circumstances, that grace period isn't nearly enough to be confident you can go from surprise termination to accepting another job.

The playing field is distorted by the current H1-B system.

For a citizen, the employer has not much more leverage over the employee than they should have (I think health insurance managed by the employer is something that should be changed, but that's beside the point).

For an H1-B, an employer can pretty much deport the employee. That is not a level playing field. That is an entirely different power dynamic that favors the employer unreasonably so.