jfrisby

If you are any example, then the reservations are unreasonable and there's plenty of precedent for ignoring them.

We didn't ban vaccines because a handful of people are harmed, and we're not reconsidering their use because a bunch of mathematically illiterate loons think they're more dangerous than the alternative.

Frankly, there's more reason to ban PEOPLE from being able to drive a car than to ban AIs from driving them -- if only because AIs can be improved and people cannot.

All the ignorance of probability, moral philosophy, economics and law will not change the fact that the posture you are arguing from is one of preserving a status quo that costs dozens of people their lives every day.

We can't put a prematurely-worn brake line in jail either.

An algorithm cannot BE "careless", in the legal sense of the word. You are comparing apples and oranges. Carelessness (negligence) is a different problem than a design flaw.

An algorithm may be flawed, in which case blame lies with the companies involved in creating it and putting it in peoples' hands. Similarly, any mechanical component of a vehicle can be flawed -- and many can cause an accident if they fail. The companies responsible are legally liable already.

> In the end, we usually determine that the rights of individuals outweigh the utilitarian benefit

Cars. Airplanes. Vaccines. All of these benefit the majority at the expense of a few.

The idea that there is no liability here is absolute and utter NONSENSE. Minimally, Tesla can be sued for the flaw in their product and the harm it caused.

Wrong.

One in 1.2 million flights crash. This is literally a "known chance".

Planes take off anyway.

Not so much "a hoot" as "morally misguided", and "void of empathy for people outside his/her monkey-sphere."

Is your friend/loved one more valuable than the 90 other people who die in automotive accidents (in the U.S. alone) daily?

Your attempt at "humanizing" the situation is merely being dismissive of the values of others' lives.

Everyone who dies is special and important to someone. To wring your hands and rail against utilitarianism is to try and apply tribalism to moral reasoning.

Because this person matters more TO YOU, you're suggesting that we should treat them as if they matter MORE THAN OTHER PEOPLE.

That seems to me an intrinsically selfish -- possibly even narcissistic -- view.

And let's recall that this isn't a choice between "human drivers, no lives lost" vs. "AI drivers, some lives lost".

It's a choice between "human drivers, MANY MANY lives lost" and "AI drivers, fewer lives lost".

What would archagon have us do? Not have AI drivers until a perfect solution is possible? The "crash-unavoidable" scenario is an unavoidable reality as long as stopping distances/acceleration/reaction times are non-zero.

It sounds as if archagon would have us spend all our time looking at trees -- and none of it looking at the forest -- all while thousands of people die every year under the status quo.

I think perhaps the reason archagon is so aghast though is a combination of two things:

1) The illusion of [human] control and judgement. Implicit in archagon's reasoning is the idea that the outcome MIGHT have been different had a human been making a decision. Yet a human WAS in control here, and DIDN'T make a different decision. That happens. A lot. Archagon seems to be so distracted by the novelty of this situation that he/she has not noticed that.

2) The normalization of automotive deaths and safety engineering in the current industry. 90 people die per day in the U.S. due to errors made by human drivers. Every day human drivers are on the road, 90 more lives are snuffed out. If we follow archagon's hand-wringing, then how could we justify having cars AT ALL? Of course, the reality that many people would die because of the lack of cars makes even the abolition of cars a less than perfect solution with (according to archagon's apparent line of reasoning) a body count attached and all the moral implications thereof.

Not built in, but you can do this:

  CREATE OR REPLACE FUNCTION bitcount(i integer) RETURNS integer AS $$
  DECLARE n integer;
  DECLARE amount integer;
    BEGIN
      amount := 0;
      FOR n IN 1..16 LOOP
        amount := amount + ((i >> (n-1)) & 1);
      END LOOP;
      RETURN amount;
    END
  $$ LANGUAGE plpgsql;

PgCluster, BDR, rubyrep, and Postgres-XL all provide master-master (or analogous) replication schemes. I cannot attest to the robustness / production-readiness of any of them. And yeah, it really is a PITA to set it up with Postgres. I will note that I once[1] lost a whole cluster's data due to a combination of Slony's sharp corners and operational difficulty of Postgres.

The schema visibility thing seems like it might be solvable with row-level security in 9.5? (I.E. apply constraints to the system catalogs, perhaps?)

The UPDATE one is good to know. Did you work around it by doing `SELECT ... ORDER BY id FOR UPDATE`?

[1] - Slony had a problem where global transaction IDs rolling over caused it to do Very Bad Things and we had had to turn vacuuming off because performance during a peak period -- but we forgot to turn it back ON and... So yeah, a combination of sharp corners in Slony and Postgres + user error == our cluster systematically ate itself.

So I cloned the WordPress git repo and noticed immediately that neither the size of the `.git` directory nor the total size (working copy + `.git` directory) was as large as the article claims.

Instead of 32,647 commits, the number at the time I cloned it was 37,304 (`git rev-list --all | wc -l`), or 34,165 reachable from HEAD (`git rev-list HEAD | wc -l`), yet the total size was 162M (`du -hs .`) -- a bit smaller than the 169.7M cited in the article.

Further, if I re-compress everything (`git gc --aggressive`) then the total size decreases to 117M. That is a sizable difference to begin with -- and doubly-so given that it represents more commits than either of the repositories in the original comparison.

If they did indeed immediately release an update that ceases asking for these permissions, then I'd say this is an entirely reasonable explanation regardless of their history.

I had a similar sense with the app. Despite the very slick UI, it just felt awkward and inconvenient in all sorts of little ways. I couldn't quite get at the info I wanted -- or couldn't do so fluidly. I couldn't quite do what I needed -- or couldn't do so fluidly.

I gave up on it in under an hour, which is kinda record time for me. I gave SourceTree a couple days, GitX/GitY/etc each got multiple hours, etc.

Only if the columns are stored on-page with the index, which is not guaranteed -- it depends on what other columns exist in the table, etc.

Until Docker is more robust, I would avoid RancherOS -- although I quite like the simple appeal of it.

Docker still has issues where the supervisory process can be badly behaved and having user-level services in a docker supervisor within Docker doesn't fully insulate you from that.

Further, much of the functionality of Systemd is actually quite interesting in the context of a large cluster of machines and it remains to be seen if Rancher will fill the gap as well.

My experience with FullContact was one of constant duplication of data (at both record and field level for both exact and inexact matches. I.E. two contacts representing the same person with say, differences in first name -- Jon vs. Jonathon for example -- would often result in two contacts with a combination of fields from each of the originals. Didn't have to be name. Address, for example. "Road" vs. "Rd" confused the hell out of FullContact routinely...), totally useless features to resolve (in particular) non-exact duplicate matching, and an absolute contempt for any manual curation at all.

Essentially it made mash of my contacts, wouldn't let me correct them either in their UI (with features built exactly for that), and or in any native apps, more than a year on I'm still nowhere near cleaning up the mess.

All they had to say about it was that "synchronizing contacts is a hard problem", or something to that effect. No effort to repair/undo the damage, no suggestions on how to avoid future problems -- sorry we ate your data, sucks to be you.

Well, there's a "Report vulnerability" link right on the front page of nexmo.com as of right now...

I had a coworker recently whose behavior became problematic, leading me to discover a similar situation.

For example: I introduced a style / complexity checking tool into various repos, including his. When I ran it, it flagged a couple methods as too complex. We got into an argument over whether this was a fair assessment or not. The end result was that I left things where they were and moved on to something else until I could coordinate with the CTO on how to achieve my objectives in this context. (My role involves security...)

It's worth noting that at that point the tool was optional and out-of-band. It wasn't failing CI, it wasn't required as part of any other workflow, etc. At that point it existed solely for my own use and he could have ignored it for the time being.

At the end of the very next day, he brags to me about how he's "fixed" the complexity issues in the code. Based on my previous interactions with him, I decided to check this out. His "fix" was to put meta-comments in that disabled the relevant rules for the code violating them. Except he put the meta-comment to disable each rule several statements earlier than needed, and didn't include any meta-comments to re-enable the rules after the relevant code. And he had changed the config file comments I had made, reflecting that the exceptions from the company standard configuration were done to accommodate his needs (I felt it was important to have that context present for future maintenance efforts).

His bragging to me about "fixing" the complexity issues (and yes, he used the word "fix") struck me as being either deeply dishonest, or representative of a truly breathtaking lack of understanding.

Between this and several other incidents (most of them I merely observed, some I was entangled in), I decided to dig into his background a bit.

I found a few things that I could chalk up to simply not understanding the very domain-specific meaning of some general-sounding terms in particular contexts. For example: On his FounderDating profile he listed himself as having been a "mentor" to TogetherSoft / Borland. That just seemed... beyond implausible to me. So I read deeper and it seems his role at TogetherSoft (acquired by Borland turing his tenure) involved mentoring coworkers.

Ok, I'll chalk that up to an innocent mistake.

Then I get to the startup he co-founded. Except... wait. The dates here don't fit with those on his resume? Hrm. Start-date was some 6 months after the company was founded.

I tracked down the main founder's email and sent him a brief inquiry, with a fairly vague wording, asking about the time discrepancy, and asking if perhaps this was some unusual situation and that he was in fact a founder. I got an initial response asking for clarification, to which I responded. No response to that. So the founder didn't even want to say "yeah, he was a (co-)founder."

At my employer, he had taken a truly beautiful codebase written by ThoughtBot and absolutely wrecked it in the space of 2 months: He refused to gain any significant understanding of Ruby, Rails, or Angular. He ripped out Angular in favor of his own templating library. He reinvented ActiveRecord associations, incorrectly because he didn't like that the column name had to have `_id` at the end. And all the while he would rail in front of the entire company during demos about how "stupid" various tools were. "HighCharts is such a broken library -- you can't even remove a series from a chart once you've added it!" / "Wait, that seems ridiculous. Are you sure?" / "Yeah, I scoured the docs and found nothing. Googled it and found loads of other people having the same issue. I'm gonna have to blow away the whole chart and recreate it whenever there's a change!" / "... I just found the method right here while you were talking about it, and here's a jsFiddle showing that it works as expected."

I also found out he'd introduced his templating library without clarifying that it was created by him (he just announced it as a good tool he'd "found"), and had done so at at least one other company.

Given the damage done, here and apparently elsewhere, I'm seriously inclined to blog about it publicly -- name him, so that any potential employers who google him will have access to some very relevant information.

Perhaps you could write a blog post that makes a point of outlining who the founding team is? A "founders" page doesn't help because one expects that a departed cofounder would be scrubbed from it, but a blog post may raise alarm flags for more people. You wouldn't even have to name him explicitly -- just not include him, or mention him indirectly ("we hired a contractor to do X").

Daly City. Westlake Village Apartments. You can get a crummy but livable apartment reasonably close to BART for ~$1800.

If it were just features, I'd probably agree with you, but Mail.app in particular (doubly so on desktop) seems to have serious issues with syncing of mail, handling of connections when there's non-trivial packet loss, maintaining its internal database consistently/correctly, etc. Some of this may only be an issue if one has many accounts and/or large inboxes but for those of us with, say, an iCloud account, a normal GMail account, and a handful of Google Apps accounts -- and email history stretching back many years -- it's a serious problem.

No, they're vastly friendlier, by and large -- as demonstrated by the project maintainer of text being nice acceding to your demands despite having precisely zero legal obligation to do so, and despite you being an utter jackass about it.

I, on the other hand, am seriously considering taking Metaphone3.java and reimplenting it in several languages, then making those publicly available.

1) It's not a "legally castrated copyright", it's a tool that we use to enforce a behavioral pattern that encourages growth of the commons.

2) Why should we feel "happy" when you've pulled a bait-and-switch, and acted as a bully? Your behavior and mindset are grossly at odds with the purpose of open source. Your effort was a trojan horse that's disruptive to the community. In short: You literally missed the point of "open source" entirely.

3) You explicitly stated that the algorithm is "not in the public domain", so falling back to a position that one can merely use Metaphone3.java is disingenuous. Java source is not useful or suitable to those of us in the Ruby world. We don't want to have to deal with the added overhead of a JVM.

4) Don't expect to be welcomed when you act like a bully, because you didn't know what the hell you were doing. It's not our job to teach you what the BSD license means, or what the difference between a copyright and a patent is.

5) Don't let the door hit you on the butt on your way out!

I've moved on from the company in question, but as technical co-founder of Cloudability -- yes, I am proud of their blog. I just wish the brilliant folks there would WRITE MOAR!

... can I bear your love-child?

Not only that, but if you push a pre-existing repo to github, you'd lose all information about actual authorship.

Strongly suggest a service like Cloudability to help find out about such things as soon as possible...

If they are prohibiting (or even DISCUSSING the possibility of prohibiting) you from creating repos under your personal, non-work-related Github account I think it's safe to say it's time to go elsewhere.

As someone who's spent some 17 years doing almost nothing but startups, allow me to add my $0.0296 ($0.02, adjusted for inflation1)

Some combination of #1, #4, and #6.

#6 is the one where you don't truly respect the process of management works (in much the same way we all get frustrated at managers who don't understand how the process of software engineering works), and are oblivious to the challenges and concerns involved.

This is an easy trap to fall into and most engineers I know have fallen into it at some point in their careers. Good management is often virtually invisible, but bad management sticks out like a sore thumb -- or so the conventional wisdom goes. Remember:

1. Management is a skill, just like coding. It's deep and complex and multi-faceted and you're only seeing the surface of it. 2. In startups, many entrepreneurs are getting their first taste of a completely different world. It's a learning process even for an experienced manager/executive. Imagine being a career web developer and say, cutting over and doing 3D game development on a console system in C++ for the first time. Only it's not a hobbyist thing, it's your job and people are counting on you. 2. Startups are not like normal environments. Inaction is usually worse than a bad action, because at least with a bad action you've learned something and narrowed the search space a bit.

You should EXPECT that in a startup, seeing management trip up and make "mistakes" will be a common, everyday occurrence. Oftentimes the right decision will look, externally, like the wrong decision. If you want a well-oiled machine in a well-understood problem domain, go work at Cisco.

Startups are about discovery. Product-market fit, paths of least resistance, etc.

I'm personally inclined to this form of myopia myself, so as a rule, I only work within my personal network at this point because I have a group of entrepreneurs, executive-level programmers, and so forth who I trust implicitly. I may not understand a given decision, and any given decision may be a mistake but I'm entirely comfortable leaving their domain in their hands while focusing on doing my best in my domain. I find it's less stressful, and more rewarding whether the venture succeeds or fails.

(1 - Yeah, I looked it up on WolframAlpha. I'm bored, what I can I say.)

Because the group not being demonized are mostly comprised of people who are trying their best but in circumstances that make it impossible to live up to their obligations and the group being demonized are mostly comprised of people who are breaking the law.

Stop and think about this for a second: If someone intends to not pay, abusive language isn't going to change their minds.

If someone cannot pay, then abusive language has no value either because, well, they cannot pay.

The only case where abusive language is beneficial is if someone is actively trying to pay down their bills, but they have more bills than they can pay all at once and a debt collector wants to get their bill paid before every other debt collector's bill. And gee, that's exactly what happens when someone loses their job / suffers a major medical crisis / etc.

tl;dr: Abusive behavior is useless if someone is NOT going to pay their bills, and only does anything if someone is TRYING to pay their bills: It's a means for collectors to try and jump the line to get their own debt paid first.

And frankly, anyone who thinks that two wrongs make a right is a terrible person.

"more aggressive"? So you feel bullying and abusive tactics are justifiable means of collecting a debt.

That's pretty fucked up.

... except the collection agencies -- but good riddance to them.