436 karma · joined April 5, 2011
I believe there are a few states/jurisdictions that restrict off duty officers from working in uniform w/police power, but that's probably a minority. With budgets being cut everywhere, officers being able to earn an extra 50% or more of their normal salary working off duty gigs is a "free benefit" the department can offer, or like in NYC where the NYPD charges a 10% admin fee ($1.18m earned in 2011) it's extra income for the dept.
For example, if Facebook was located in San Jose, they could just pay $46.50/hr for as many officers as they wanted, in unform, per http://www.sjpd.org/PDF_Forms/SEU_Secondary_Employment_Emplo... .
"1.2 Traffic Exchange Ratio. The ratio of the aggregate amount of traffic exchanged between the Requester and the VERIZON Internet Network with which it seeks to interconnect shall be roughly balanced and shall not exceed 1.8:1."
Their equal traffic ratio has been in every tier 1's peering policy since the 90s. The issue is that Cogent (One of Netflix's ISPs) is used almost exclusively by content providers, and thus traffic ratios are going to not going to be balanced. Traditionally peering was only free between those with similar traffic ratios, and it was free as payments to each other would cancel each other out anyway. Verizon, you could say legitimately, believes Cogent is not a peer and should either pay them for the interconnection, or purchase transit from someone who is a peer.
This is not new with Cogent. At one time they were practically giving away IP transit to any eyeball heavy ISPs to help balance their ratios. They muscled themselves into Tier One-ish status by buying cheap fiber after the bubble burst and sold transit for cheaper than anyone to build up traffic. Rather than paying settlement fees to make up for the traffic inbalance, Cogent has played hard ball and went through numerous de-peerings where Cogent's customers were unable to access the other network.
Peering is a messy world. It used to be the content providers and the eyeball networks both had to pay the national Tier 1s for access and the Tier 1s interconnected for free. Now the ma bells ended up buying the Tier 1s. (Verizon bought MCi/UUnet, SBC/BellSouth bought ATT) and so the eyeball networks are the Tier 1s. And the Tier 1s also own cable networks that compete with one Cogent's customers (netflix). This is a newer development and so while Verizon's network team may rightly be suggesting Cogent should pay them, this ignores the bigger picture. The old peering paradigms may need adjusting now.
However, when we had consistent outages and horrible service, I eventually gathered enough evidence to give to the HOA of what the problem was, and when the HOA contacted the ISP, they looped me into an email chain with their account rep and we got immediate service. If we all had to choose Comcast or ATT individually, neither would really care about individuals. But the HOA is in a much larger bargaining position and our ISP cares about losing the whole building.
From my experience and friends in the area, those in condo buildings with the exclusive ISP arrangement tend to get better/faster service than those in condos with the standard cable/telco choice. Since condo buildings are managed by the residents who mostly use internet, usually enough percentage care about the quality of internet access to hold the exclusive ISP accountable or replace them. Of course in Apt buildings, mgmt just views internet as an expense and it's a different scenario.
I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ .
A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git.
Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not.
It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.
Encryption requires everyone in the thread to support it. Need to CC in the C-Level exec on something? Good luck getting them to setup it up in their outlook and use it properly. Even with my help, it took a good 30 mins to set my dad up with GPG on Windows/thunderbird. Have to figure out which software you need, the nomenclature for key generation etc is different in each program.
Encryption breaks search, at least in thunderbird. You can't search through the encrypted messages and they aren't indexed. This makes sense if you're sending very sensitive data perhaps, but for general business correspondence it's reduces productivity. There's an open bug in EnigMail by a user who saves every email in plain text to use regular file search tools. That's useless.
There's the aforementioned webmail. Tons of people only use webmail, and there's no way to interact with them. More importantly in my book, encryption breaks mobile access. Sure, there are addons for gpg on android, but I don't trust my private key on my phone. In the near future there may be some way to use a yubikey with NFC for passing in the private key, but that brings in it's own set of problems.
Lastly, it's the cost/benefit that really keeps encryption use from being wide spread. It costs you time in getting each contact you use to use it, time dealing with being unable to search, time setting up your phone to securely access mail, unable to use webmail at all, and for all this you really only get two benefits: Prevention of e-mail interception by intelligence agencies or internet backbones and access to your mail by your e-mail provider. If I'm not concerned about these, just using proper TLS access for IMAP/SMTP prevents anyone I'm actually worried about (wifi interceptor, bad ISPs) from reading the mail. For mail inside an organization with their own mail server, mails are never anywhere unencrypted than company owned equipment, TLS in transit.
Doing encryption right is hard, for 99% of email the threat model just doesn't justify the expense in time and headaches so the NSA doesn't know there's a conference call at 11am tomorrow or that you should call grandma tomorrow because it's her birthday.
If you're interested in underground structures, you should check out limestone mines converted to office space or storage like subtropolis. They mine the limestone of a solid horizontal layer leaving pillars to support the "roof", creating an entire underground building millions of sqft and acres in size. Subtropolis is over one thousand acres.