> I have told my sons that they are not under any circumstances to take part in massacres, and that the news of massacres of enemies is not to fill them with satisfaction or glee.
> I have also told them not to work for companies which make massacre machinery, and to express contempt for people who think we need machinery like that.
3rd party user tracking can slurp up a lot of unexpected data, and no one ever wants to disclose problems when a vendor loses things like this. MixPanel has a long history of problems/
I worked on Flowdock for a couple years, and noticed that the current team formally announced its shut down a few days ago. When I started work on it, it had been in stasis for a year or two after being acquired by Rally Software, and then having the initial team leave.
It was a thrill to regain access to all the parts of the service which had been orphaned, and to get them updated and working properly again, but the whole thing was haunted by Slack during my time working on it. One of the oldest users in the system was Stewart Butterfield, under an account for Tiny Speck. When we'd run into an issue, like people phishing using malicious links, we'd go look at how Slack was solving the same problem, and usually find that they had invested way more engineering time into solving the problem then we could afford to devote to the entire project: in that case, they had (have?) a service that front runs links before posting them to shared channels, and scans them for viruses and other bad content.
The hybrid flat/threaded messaging system was innovative and worked well for people who adopted it, but often caused confusion for people new to the product. When I was working on it, we reused parts of the existing API to allow for dragging and dropping messages you had written between threads, which is something I miss in other threaded chat tools today.
Ultimately, I think it was doomed by tech debt, organizational mismanagement, and its owners being serially acquired by other companies. It was bundled with other Rally/CA/Broadcom products for enterprise sales, and that means that even when it had 100,000+ users, the monthly revenue was assigned to other products in the bundle, and it was treated as making very little money, and given staffing to match. I think Rally likely acquired it to compete with Atlassian's Hipchat, but when Atlassian lost interest in Hipchat, Rally/CA also questioned their decision.
At one point under Rally's ownership, the choice was made to move from the original Finnish team's host of choice, Hetzner, to AWS. The monthly cost of running Flowdock's systems went from ~$1k to ~$50k, which was untenable for a product that size. Costs were able to be reduced with careful management of storage classes in AWS later, but the size of the MongoDB clusters meant that expenses never again made sense for the revenue that Flowdock brought in.
It was a blast working on Flowdock, and I'm sure there are quite a few people who managed the product over its decade long lifespan who wonder if they could have been Slack if they had only made a few choices differently. Live and learn!
This is great news for people like rsync.net, anyone using zetaback, or people using znapzend. I suspect cloud storage via ZFS will see the most benefit, as they'll be sending full datasets over lower bandwidth links. The zfs backup solutions will have less benefit (except with restores) as most backups end up being incremental.
/usr/bin/sed on Solaris 10 and earlier does not support -i. I don't know if OpenIndiana / Solaris 11's sed support -i, but OmniOS uses gnu sed by default, so OI might also.
As I recall, AIX's default sed also does not support -i, but I no longer have access to AIX systems to test against.
This can also lead to DOS issues, as I understand it, the Apache server-status pages are very computationally intensive to produce, and it requires stopping and polling every child.
Something like
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from 10.0.0.0/24
</Location>
(where 10.0.0.0 is your local network range) will prevent external requests. This is mentioned in the linked through Apache documentation.
Maryland's speed cameras are only active in school zones (which are not school zones outside of school hours) and work zones (which are usually not work zones on the weekend).
> I have also told them not to work for companies which make massacre machinery, and to express contempt for people who think we need machinery like that.