Abandoning Gitflow and GitHub in favour of Gerrit - <AUTHOR> http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/ <comment><USER5> Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA.

The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either.

The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. It's a dirty solution to have to amend your commits to make changes.

Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

<comment><USER6> > if you push multiple dependent commits to Gerrit, and one of the early ones > gets merged, all of the later ones now have to be rebased because Gerrit > created a merge commit in the middle.

Someone didn't spend time configuring gerrit or configured it wrong for your use cases. You can solve this in one of two ways: you either fast-forward when possible (gerrit can attempt a trivial rebase) or you commit a change set, create your own merge commit, and then your early ones won't get merged until your last commit. Gerrit will wait to merge the early commits (and vice versa if dependant commits are ready) until everything is good, then merge them all in one shot.

I used gerrit heavily for a few years (and still do, passively, with golang and other public google projects) and I miss it dearly. Sure it's not perfect, but I'd take it over the github fork/make pull requests model any day of the week.

It does not encourage monolithic commits. You need developers to understand what they are doing, care about commit history and be disciplined during development. In my experience, developers who just want to hack shit together, cut corners and love squashing commits or throwing away history hate gerrit. Developers who care love it. It's definitely possible and easy to produce Agile software.

Like anything else, you should use the right tool for the right job. If you're not willing to suck it up and learn something new, then it's not going to have a chance to be the right tool.

<comment><USER7> Your argument would be better received sans-ridicule.

I think the OP's point was that Garret hides a lot of features that are built into git and then attempts to paper over that fact by re-implemting those features within its own system.

In your first paragraph, you defend Garrit's rebasing procedure and then you implicitly accuse the OP of not being willing to "suck it up and learn something new".

Why should we learn a new tool that makes (arguably poor) attempts at re- implementing the features of a tool that we already know and love?

<comment><USER8> There's nothing ridiculous in xyzzy_plugh's argument.

The discussed tool is not "Garret" or "Garrit", it's Gerrit, which makes me wonder if you used it before commenting.

As far as I know, Gerrit doesn't reimplement git's features. Rebasing is done using git rebase.

Gerrit is a system for code review, just like GitHub's PR, but with a different approach.

<comment><USER7> "Look at this guy mispelled the name of something. He must not know how to identify ridicule"

</comment></comment></comment></comment></comment><comment><USER9> The article isn't particularly well written or argued, but it does have a core of truth to it: serious code review in GitHub is painful. However jumping straight to Gerrit to solve that problem seems like overkill to me. Sure, you get a really powerful and extremely configurable code review system, but you have to retrain for a new (and honestly a little long in the tooth) UX and spend time administrating the system.

A lighter-weight SaaS like [https://review.ninja](https://review.ninja), [https://omniref.com](https://omniref.com), or [https://reviewable.io](https://reviewable.io) (disclosure: this one's mine) might be a more appropriate solution. Specifically to the article's points, Reviewable has a nice reviews dashboard and will show inter-commit diffs within a PR (whether you're rebasing/amending or not), hiding any files with no changes since you last looked. Its default review completion criterion is that all files have been marked as reviewed by at least one person and there are no unresolved discussions still going on, but you can customize this to your team by writing a snippet of code to run against the review's state, e.g. to implement LGTM approval or even a voting system. Reviewable will also update a status check on the PR so you can enforce review completion before merging if that works best for your situation.

Best of all, because both systems integrate tightly with GitHub, there's no need to learn a new workflow or mess around with new git commands. Gerrit still has its place but I don't think it should be the tool of first resort.

(Edit: added mention of Omniref.)

<comment><USER10> Just use Phabricator! It's the best code review system I've used so far. Many large open source projects and companies have adopted it.

Someone neatly wrote up the main advantages:

[http://cramer.io/2014/05/03/on-pull-requests](http://cramer.io/2014/05/03/on- pull-requests)

Phabricator's issue tracker is also an excellent choice over GitHub's simplistic issue tracker.

Also, Gerrit isn't that hard and I've seen small teams get productive with it within a 1-2 weeks.

No need to reinvent the wheel!

By the way: I live in Europe and I haven't worked for one single company which would allow their developers to host proprietary source code with a third party SaaS provider.

<comment><USER9> Phabricator is nice, but it's more of a full-featured replacement for GitHub as a whole. Some people want to keep most of GitHub and just improve on the code review aspects.

> By the way: I live in Europe and I haven't worked for one single company > which would allow their developers to host proprietary source code with a > third party SaaS provider.

Fair enough, companies vary widely in their acceptance of SaaS -- though Reviewable has plenty of European customers too. But to clarify, neither Review Ninja nor Reviewable (not sure about Omniref) actually host code themselves: they just access it through GitHub APIs without storing it. You can also deploy Review Ninja (and soon Reviewable) on-premises, though of course that means you're on the hook for administrating the system again.

<comment><USER11> > Phabricator is nice, but it's more of a full-featured replacement for GitHub > as a whole. Some people want to keep most of GitHub and just improve on the > code review aspects.

That's the nice thing about Phabricator, you can switch off all features you don't need, and it integrates with GitHub. You can definitely use it just for code reviews, with users logging in using their GitHub accounts and the repositories being hosted by GitHub.

> You can also deploy Review Ninja (and soon Reviewable) on-premises, though > of course that means you're on the hook for administrating the system again.

That would work! Third party SaaS probably includes Github.

</comment></comment></comment></comment><comment><USER12> Nothing about what was wrong about gitflow.

One small correction I would like to make to gitflow is that the default branch for developers should be 'master'. If you want to deploy another branch, use a 'production' branch. This means people don't have to manually change branches everytime they clone, that type of repetitive work should be outsourced to a computer ( your deployment scripts ). If you have full access to the repo and you are on github, atleast you can change the default branch ( which for a repo I contribute to, I don't )

Anyone know the need for a seperate 'develop' branch ?

<comment><USER13> > Anyone know the need for a seperate 'develop' branch

The HEAD of _master_ should always be production-ready code. It is your most- stable branch.

It's necessary to have a less-stable, separate, _develop_ branch where features, bugfixes, etc, that were developed off on their own sandboxed branches can be merged and integrated as part of a development phase.

Even with the most disciplined testing of isolated feature branches, it's not known whether integrating different ones will always work, so it is not even guaranteed that the HEAD of _develop_ will always be stable, let alone production-ready. Even if it is stable, it could not be production-ready for the simple reason that it so far only contains features X and Y, and the next release cannot go out without Z there too, where Z is not merged yet.

As you point out, having _master_ as the most stable branch appears to just be a convention, and it would be perfectly possible to branch a _production_ branch from _master_ and swap the roles at the start of the project too.

I think the convention is like that so that one can immediately build and run the latest production code after cloning the repo, which in my opinion is nice. Besides, with the number of branch switches you do every day as part of normal development, it doesn't seem too horrible to have to do it once, to start working off of develop after you clone the repo - at the end of the day how often do you do that, and how annoying or arduous really is it?

<comment><USER14> > It's necessary to have a less-stable, separate, develop branch where > features, bugfixes, etc, that were developed off on their own sandboxed > branches can be merged and integrated as part of a development phase.

I don't think it's _necessary_ by any means. e.g. We auto-deploy the HEAD of master, assuming tests pass and don't use any special integration branch. If you have some set of features that need to ship together, that is just a feature branch like all others. Multiple people can work on a feature branch and test their integrations there.

> Even if it is stable, it could not be production-ready for the simple reason > that it so far only contains features X and Y, and the next release cannot > go out without Z there too, where Z is not merged yet.

I think largely your assumptions are based on a slow moving release cycle, not everyone operates that way. We regularly release multiple versions a day in most of our repos.

<comment><USER13> Within gitflow it _is_ definitely necessary to have an integration branch - <USER2> doesn't really matter if you call it _develop_ , or you progressively merge different features branches down together, or group them into one feature and just develop them all on one feature branch from the get go, the result is the same - you end up with all your code integrated on one, not necessarily always stable, branch.

The idea in gitflow is that you then isolate a snapshot of that integration branch, whatever form or name it takes, as a release branch, and only when that release branch produces a build passing all tests is it then merged to _master_ (and probably tagged).

You mention you auto-deploy from HEAD of _master_ after tests pass - does that mean that code at the HEAD of _master_ may not pass tests, or that you merge code to _master_ only if it has passed tests. If it's the former, then you're not using gitflow, and I was just explaining the use of separate _master_ and _develop_ in gitflow, not implying that this is the one true branching/release strategy. Using something other than gitflow can work equally well. If the latter, then you are using an integration branch - the one you run the tests on before merging to _master_.

As to the point about release frequency, having a set of features to release in batch was just an example - if you're in any situation where other developers may commit things to the branch that will ultimately be released from between the time you create your feature branch and the time you merge it, then gitflow is useful - be that on a scale of minutes, hours, days or weeks.

</comment></comment></comment></comment><comment><USER15> I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complicated things, it's much more preferable to use a handful of related commits, all of which should get reviewed and merged as a batch. Does Gerrit not support this?

<comment><USER16> Phabricator[0] is awesome. Diffs (like PRs) contain several commits, but are reviewed, discussed, and "landed" as a unit with an auto-generated commit message referring to the Diff description and a link to read its history, but "master" is a linear sequence of Diffs being landed. You can also configure all kinds of rules like "X person must sign off on any changes to this file" or "do not merge code to master unless it is approved by N people other than the author." The UI is a bit clunky but I love it, and it's open source and very flexible.

[0] [http://phabricator.org/](http://phabricator.org/)

<comment><USER15> When you say a linear sequence of Diffs being landed, do you mean it commits squashed merges, or does it create actual merges (so the history of master includes all the commits in each Diff)?

<comment><USER16> AFAIK this is configurable. We did squashed merges, which I quite liked, because "git log" for master read nicely but you could go look up the more granular history if you wanted to.

</comment></comment></comment></comment><comment><USER17> "If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request."

You don't have to do this with Github. Just clone directly to your local machine. Also, you don't have to use git flow when using Github. I think git flow seems to be the real culprit of the symptoms you have identified.

<comment><USER18> > You don't have to do this with Github. Just clone directly to your local > machine.

If you use this model, your local clone isn't "backedup" by github until the pullrequest is merged, correct?

One reason I like my teammembers to have their own local fork, is so they can have github exist as a backup.

<comment><USER19> Team members can also work in their own private branches that are pushed to a single repository - that's usually sufficient as a "backup".

<comment><USER18> That requires push-access. Not all team members have push access to all our source repositories.

<comment> brown9-2 Allowing someone to push branches to the "central" repository versus requiring them to have forks of it is functionally the same thing, assuming you set up branch protection for master.

<comment><USER18> > assuming you set up branch protection for master.

Bad assumption. However, branch protection sounds cool. Will investigate it.

</comment></comment></comment></comment></comment></comment><comment><USER20> I don't see anything in the article that goes against gitflow. Is it just me?

They don't want to use Github for the code review and prefer to use Gerrit? Good for them, I don't either and actually prefer GitLab or BitBucket for git in general. But hey! thanks for the Gerrit introduction.

But gitflow?

I've been using the gitflow way of working for ~5 years (although not always the gitflow extension) and I don't see anything there that clashes with that way of working. You want to work on a feature, perfect: Branch from develop and work away.

After you are done and before you merge with develop again, you push your feature to Gerrit and do the code review/changes. And then merge back to develop.

Really, I don't see the issue between Gerrit and gitflow and still think that gitflow is a very sane way of working in a team, specially if you have people that are not used to work with [distributed] version control systems and you probably wouldn't believe how many developers are out there like that.

</comment><comment><USER21> This is way more complex to me than GitFlow with pull requests. As a matter of fact, if you use something like SourceTree for most of the initial steps it's a few mouse clicks. Also, try Gitlabs for your reviews; it's pretty good!

The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get insulted and you breed discontent and mistrust. Too high and everyone stays happy until code quality drops. People will either use this as an opportunity to diminish other's, show off or suck up. Sad, but that's human nature.

I know in-person code reviews aren't always possible but adding this disconnect just seems like a bad idea. Would love some honest feedback from people who have actually used it in medium-large scale production.

<comment><USER22> What appeals to me about the voting scale is that it's well-defined: a -2 means "don't merge yet", a 1 means "looks good to me but I'm not sure that it's ready to merge". More of an enum than a voting mechanism.

It sounds like it removes the ambiguity of when you leave a few comments on a PR but aren't explicit about whether you think it should be merged or not.

</comment></comment><comment><USER23> We tried Gerrit. We ran as fast as possible away. It seemed to hate merge commits, and would hang up often. I'm not sure if it's changed at all, but I think the only option was to review every commit individually inside of a branch. It seemed to really be pushing us towards squashing a branch and pushing that up.

<comment><USER24> Gerrit does favor rebasing over merging but that's hardly a reason to run away from it

<comment><USER25> Rebasing is great for version history but is hell for collaborating on a feature. If anything is the Achilles' heel of Git (aside from the groundbreaking levels of inconsistency in the CLI) it's this.

the moment someone creates a new version control system that has most of what Git does but fixes parallel histories, I'll switch. And I don't mean that the way people say "if Bush wins again I'm moving to Canada." I say that as someone who has administered CVS, SVN and Perforce repositories on behalf of my teammates but wants nothing to do with administering Git.

<comment><USER26> Would you care to elaborate what you find wrong/bad about "parallel histories"? I'm curious.

<comment><USER25> This is related to the conversation about squash that happened last week.

Basically, the moment two or more people try to work on something outside of the trunk line of code (trunk/master/whatever), there is no version of their commit history that will be pretty, and so squashing the branch at the end seems like a good idea, even though it produces objectively worse code over the long run.

To wit: There comes a point where the branch and merge structure of the code N months ago is no longer relevant to my day. However, the contents of 'blame' could contain code from years ago every time I use it. [edit] How it was merged is irrelevant. When it was merged, by whom and with what commit message is what survives into the future. By squashing the who and the message are lost. But we think that's okay because it's a lesser evil than having a bunch of commits in trunk. Which is bullshit.

What's hard to stomach is a bunch of merge commits back and forth and back again, and so I sympathize with people eager to sweep those under the rug. But at the same time I know that one of the most common ways a bug makes it into the code is via a bad merge. Keeping them is more honest even if we don't want to think about all the little human things we do that make our code worse.

I want to tell one little white lie with the code: I want to pretend like Joe and Tim wrote their entire feature after my bug fix and before Steven's, even though they worked on it all week. I want them to be able to commit it as a single transaction but with all the intermediate steps.

When I say 'parallel history' I mean I want Joe to be able to rebase the branch on top of my changes, without having to go apologize to Tim for making his snapshot into mincemeat.

Or, I want us to stop pretending like feature branches fix all of our problems, with no serious consequences. Maybe we should just go back to the roots of Continuous Integration and merge on every commit, and rely on things like feature toggles and test automation to control the reach of our in- progress changes.

I think the real issue at hand here is the one-size-fits-most mentality we maintain. As a maintainer of a FOSS project I want to reserve the right to reject contributions out of hand. If I don't like your code I tell you no and you go away. I will also enjoy getting medium units of work that were a team effort without ever having to coordinate with any of those team members. As a volunteer effort, this scales like nobody's business. But just because it's working great for open source doesn't mean it's the rational answer for commercial code.

In commercial code, all changes can be tracked to either human error or a requirements change, and knowledge of the project often is locked in someone's head because archived public forums aren't the dominant form of communication or negotiation. When, how, and why every line changed matters because every fix I undo while making another one alienates a paying customer. So verifying why the code is the way it is now is fairly important.

And let's be perfectly honest here. If, as your dev lead, I don't like the quality of your contribution, guess what, it's going in anyway. I can push back and make you do it better, but 9 times out of 10 your change is going in. Maybe not today, but soon, unless I'm in the process of getting you fired for incompetence. So being able to drop it on the floor at no cost to me isn't really a useful feature. For Linus that and an insulting email are how he 'fires' bad contributors. As coworkers our relationship would be a little more complex.

Pretending that these constraints fit the exact same development pattern as what works for Linux, NPM, Mocha, or probably even Docker is just nuts. We can share a lot of tools, but we can't use exactly the same development process. And Git bends in one direction but has no give in the other.

<comment><USER27> > By squashing the who and the message are lost. But we think that's okay > because it's a lesser evil than having a bunch of commits in trunk. Which is > bullshit.

Well, don't erase the message when squashing. My policy is that we take the pull request and use the message title and description as the actual message of the squashed commit, which works great.

Having a bunch of commits IS really bad. One idea = one commit is so much better than some bullshit three commits of "refactored" "made mistake" "back to normal" those are just as worthless to keep in the history as recording your typos+backspaces+fixes into the history.

</comment></comment></comment></comment></comment></comment><comment><USER28> There's a Gerrit service that integrates with GitHub:

\- [Gerrit Code Review for GitHub]([http://gerrithub.io/](http://gerrithub.io/))

<comment><USER29> If only it was only code review. This is basically another GitHub git hosting service using gerrit, and it syncs to github for open source projects.

I don't want a new hosting service, I just want a code review process on top of GitHub.

<comment><USER9> Try [https://reviewable.io](https://reviewable.io) then. Just code review, runs on top of GitHub, no extra repos to manage. (Disclosure: I'm the founder.)

</comment></comment></comment><comment><USER30> I use gerrit daily. It's a good tool once you learn it but as an end user I find it has some usability issues. I would very much recommend it though for teams. You'd need someone to instill good code review culture in your team. It dictates the +1/+2 review flow so you have to adhere to that for it to be a natural fit.

</comment><comment><USER31> What I miss in article is for how long they are on it. Is author after peak of inflated expectations?

I have used Gerrit in my previous team and it did not worked so well. Hanging vetos on -2 are not that nice when you have to push feature forward, like instead of blocking it someone else could just fix it, by the time you talked person who put -2 to change it to -1. But maybe with more mature team it would not be a problem.

<comment><USER32> I think there's something amiss in your development process if you feel you can merge changes that have -1. What's the point of a review in this case?

There's always hurry, but skipping reviews (and often unit testing too) is a sure way to make sure you'll keep busy fire-fighting in the future.

</comment></comment><comment><USER33> Without fail, every single one of these "Git Flow sucks!" or "GitHub sucks!" posts has a fundamental misunderstanding about one or the other.

An example of this is my own team, where we currently have a list of "release/*" branches in our GitHub, because "git flow doesn't deal very well with hotfixing a release".

Fundamental misunderstandings.

</comment><comment> brown9-2 _Gerrit is being used by many large open source projects,_

It should be worth noting that those large open source projects have very, very different needs than a small development team working on a product together. The open source project likely isn't doing weekly releases (which require some sort of manual QA process, in the source article). A large open source project has hundreds of contributors, where reviewer time is scarcer than contributor time (and the pool of people to approve and commit a change is much smaller than the contributor pool).

I think the OP's real problems are that:

\- an increased release frequency requires them to do _more_ QA

\- their time spent in code review seems to be a function of how often they are "releasing", not how often people are making changes

If the difficulty of making a release increases as you increase your release rate, you might be doing "agile" in a poor way.

</comment><comment><USER34> > As soon as someone added changes to their pull request – either by rebasing > in the new changes or making it as a new commit – you lost track of the > comments in the code and viewing what had actually changed since the last > update became really hard (almost impossible if the new push was rebased > with the new changes).

We use github at work with a feature branch workflow (as opposed to gitflow). We've adopted a system where pull request comments are addressed through the use of "fixup" commits.

For example, when a pull request is submitted for a feature branch that contains 3 commits, and a comment is made regarding part of the change, the person who submitted the PR will add a commit that addresses the comment with a commit title of:

>> fixup! Title of the commit to update

>>

>> An explanation of what this commit does and why

>> ...

This, incidently, is exactly what git commit --fixup <commit_ref> does.

Then the person responds to the comment saying that it was addressed in <commit_sha1>.

As a reviewer, it makes it easy to see that my comment has been addressed and exactly what change was made to address it (by clicking on the link that github autogenerates from the sha1 in the comment).

Once the review process is complete, the person will run git fetch origin and then git rebase -i --autosquash --keep-empty origin/master to actually reduce the set of commits down to the original clean set of commits. They then run a git diff <original branch head sha1>.. to verify that there are no differences and then they merge the PR using the merge button in the web interface.

This way, you end up merging a clean set of commits for each PR, and it's still relatively easy to keep track of comments and incremental code changes addressing those comments during the PR.

In fact, multiple developers can collaborate using the same branch by pushing up "fixup!" commits. Though they need to make sure that they fetch/merge or pull before they push to avoid unwanted merge commits within the branch.

</comment><comment><USER35> Blech. I have to use Gerrit at one of my current clients, and I fucking hate it.

Github's workflow is easy. You have a repo, you can fork it or create a feature branch, you can add multiple commits, and then open a PR. That makes sense. And the interface is pretty.

In Gerrit, I still do commit-as-you-go, because __that 's the entire fucking point of Git __. If I wanted SVN semantics in my repo, I 'd use SVN. Then, we have to squash all the commits (I'm very anti-history-revision, but I know that's an opinion) and push up to a different origin. And god forbid if you want to work from that code point in a new branch while you wait for a review. Oh, and if you want to fix some issues found in review? Yeah, let's edit the history again... Oh, and there's a change id created that causes all kinds of other headaches.

I have tools to manage and make sense of my git history. I absolutely hate things that force me to modify history. It might as well be voodoo magic when stuff goes wrong. It's often easier to blow it all away and start over.

I do like the things it can help you enforce -- a good build and +1/+2 code review etc. But that's not enough to deal with all the little annoyances in gerrit. Especially since it's available in a much better tool -- gitlab.

Gitlab is what comes after github has run its course for your team. It's got the same predictable and useful feel, it integrates great with CI tools, and it allows a similar GHPR-style way of merging. There's also BitBucket Server and other stuff.. but Gitlab has my vote in the strongest way possible.

</comment><comment><USER36> "At the time we had consultants working with us to speed up the development process..."

Mistake #1.

</comment><comment><USER37> > As soon as someone added changes to their pull request – either by rebasing > in the new changes or making it as a new commit – you lost track of the > comments in the code and viewing what had actually changed since the last > update became really hard (almost impossible if the new push was rebased > with the new changes).

Why are they all rebasing in their PR branches if it obviously makes the PR unreadable?

</comment><comment><USER38> I don't really see what's different. Both github and gerrit have voting and you're still creating a pull request like in github. The only difference is that this pull request is restricted to a single commit.

Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features..

<comment><USER39> > Not very flexible, I see a lot of churn of invalid pull requests with this > design if they aren't allowed to grow into complete features..

Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in.

Once done, you have a clean "Add support for use of XYZ by ABC" commit - <USER4> not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests"

<comment><USER40> > > Not very flexible, I see a lot of churn of invalid pull requests with this > design if they aren't allowed to grow into complete features..

> Actually, Gerrit really encourages growing a patchset ("pull request") into > a complete feature. It allows you update your change over and over, > addressing review comments as they come in.

> Once done, you have a clean "Add support for use of XYZ by ABC" commit - <USER4> > not a pile of half baked commits - I cringe when I see things like this: > "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add > tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests"

I don't like commits like that either. But almost all real pull requests require more than one commit (so future generations can bisect the repo properly without then needing to bisect patches as well). A nice pull request is something like this:

server: add statistics monitoring framework

server: component a: hook into statistics monitoring

api: expose statistics monitoring

integration: add tests for statistics

Each commit works as intended and does exactly one thing. I tried to do something like this on Gerrit (was contributing to the TWRP recovery) and it was such a pain that I collapsed everything to one commit. That's not how things should be dealt with (I needed to improve the pattern decryption to support N*N patterns and it required a bunch of UI, internals and other changes that all got squashed together).

I also didn't like the fact that anybody could overwrite your PR's commit with their own crap. Why is that a feature?

</comment></comment></comment><comment><USER41> What I got from this article is idea to squash every pull req into a single commit. I think this is valuable idea.

<comment><USER38> I agree, which github now does for you

[https://github.com/blog/2141-squash-your- commits](https://github.com/blog/2141-squash-your-commits)

<comment><USER41> thank you for pointing this out for me

</comment></comment></comment><comment><USER42> Anyone know of a good hosted gerrit solution?

One of the largest problems I've had getting gerrit adoption on smaller teams is that they can just pop up a private github team easily, whereas finding hosted gerrit solutions that actually make it easy to convert from other source control tooling has been very difficult.

<comment><USER43> try gerrithub

</comment></comment><comment><USER44>
      The process might seem more complex initially but think
      of it like this: If you add a new member to your team,
      they would have to fork the repositories on GitHub, clone
      them locally, make the changes, push to their own fork
      and then create the pull request

Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing.

In addition, the new GitHub code review tools address most (if not all) of the stated reasons for this switch. And in my opinion, GitHub's ease-of-use, alongside it being an incredible single point of reference, far outweigh any clunky other tools I've used (like Gerrit).

<comment><USER45> Github isn't exactly a utopia of UX.

Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to:

      $ cd ~/src
      $ mkdir github
      $ cd github
      $ git clone myfork
      $ cd myfork
      $ git remote add up upstream
      $ git pull up master
      $ git push origin master

Or something like that. I think I got lost somewhere along the way trying to checkout the upstream branch (is it "up/master" or "up master"? It depends) but it took 5-ish minutes.

Github may be pretty-ish, but I tend to avoid them these days. They're expensive, and they remove useful features. Fool me once, shame on you, fool me twice can't get fooled again.

<comment><USER46> You can create a PR from the upstream to your repo, then accept that PR. (I know, that's not immediately intuitive, but at least you can do it without pulling a local copy.)

<comment><USER47> I tried that once but ended up with a merge-commit with my name on it in the history of my "fork". Is it possible to not end up with such merge-commits?

<comment><USER46> I don't think so -- you'll need to do something like a git rebase, and there's no way to do that via the GitHub UI.

I know many don't like the 'dirty' history, but I like knowing exactly how the updates made it into my repo.

</comment></comment></comment></comment></comment><comment><USER8> Exactly why I'm frustrated with GitHub's PR:

> As soon as someone added changes to their pull request – either by rebasing > in the new changes or making it as a new commit – you lost track of the > comments in the code and viewing what had actually changed since the last > update became really hard

</comment><comment><USER48> Out of the frying pan and into the fire. I don't like Github but, from the sound of it, Gerrit is more complicated which is what I don't want.

</comment><comment><USER49> I would never ever recommend gerrit to anyone.

</comment><comment><USER50> +2

<comment><USER51> ... still waiting for someone to workflow+1

</comment></comment><comment><USER52> One word for Gerrit: UGLY! :P

<comment><USER53> It is fairly ugly, but it also allows you to drop in your own css file. It's not a 100% solution, but you can go a fairly long way towards making it more usable.</comment></comment>


Jobloft.com (Dragon's Den drama) acquired by OnTargetJobs  - <AUTHOR> http://www.startupnorth.ca/2007/10/29/jobloft-makes-an-exit/

<comment><AUTHOR> If you remember the entertaining jobloft.com saga: <http://news.ycombinator.com/item?id=54937>

This is where it ended up. (No amusing youtube video this time).

</comment><comment><USER2> The Dragon's Den is the worst 'VC' situation in the world. They are hilarious though.

A friend got on the show just because she is an attractive girl, she didn't even have a business idea when she applied.</comment>


Farm 432 - <AUTHOR> http://www.livinstudio.com/farm432/ <comment><USER2> I talked to my kids about eating insects the other day with the expected results in the form of 'ew' and such. We've spent so much time in modern society associating insects with disease it's hard to dissassociate. For some reason shrimp which are essentially bugs are no problem because (I think) they come from the ocean, so there's an obvious mental line that can dissassociate them from other bugs.

This is a great idea if you look at the math, but almost impossible to get over the emotional response. Maybe processing the grubs/flies into something less recognizable would help, but at some point you read the ingredients and you're back at square one.

Disgust seems to be one of the more irrational and risk averse emotions, which makes sense - guessing something is disgusting when it's not has little risk, but guessing something is not disgusting when it really is dangerous carries great risk.

Interesting problem especially when recoginzing what damage our current meat production is causing, plus the base inefficiencies of it.

<comment><USER3> These guys are working on cricket bars as a protein source:

[https://www.exoprotein.com/](https://www.exoprotein.com/)

(No affiliation, they were a few desks over at a coworking space)

<comment><USER4> Chapulines[1], a form of fried grasshopper, are already a popular dish in Oaxaca. I've had them, they're tasty, a bit like salty, earthy, not very meaty crab I guess. In fact, there's already a cricket bar based off of this dish[2]. Americans in general are pretty squeamish about their food, but this is not true in many other parts of the world. See tripe, chocolate meat (dinuguan), balut, etc.

1 [http://en.wikipedia.org/wiki/Chapulines](http://en.wikipedia.org/wiki/Chapulines) 2 [http://chapul.com/](http://chapul.com/)

<comment><USER5> Ok, having seen balut, I'd starve before I ate that.

</comment></comment></comment></comment><comment><USER6> At first I was totally grossed out by the though of the entire process. It's tough to see how the sausage is made, tougher still with the cultural aversion to eating bugs. Then I watched the video where they are frying up the bugs in the pan, and though "How can they be so thoughtless to use metal on a non- stick pan"! So perhaps I'm past my aversion to eating bugs! Maybe not.

<comment><USER7> And, then eating out of the non-stick pan with a metal fork! Absolutely disgusting. I couldn't look away.

</comment></comment><comment><USER8> The key to successfully introducing insects into the western diet is processing. Processing to remove the chitin exoskeleton (which can be saved and used for making non-edible objects), and processing to remove the product from the direct image of an insect. If you scatter some fried cockroaches over a salad you'll get a some brave souls who will say "eh, crunchy, but not bad"; if you process cockroaches to a 'meat patty' or sausage or 'protein bar' then the large majority would give it an honest try enough to become regular customers.

</comment><comment><USER9> I've realized this breaks a willful ignorance I have over animal-based food. Coming from afar, I can put aside the realities of meat eating and imagine chickens and cows dancing hand in hand in a lush green field enjoying their short lives.. (and yes, I can do this, otherwise I'd be a vegetarian.)

With Farm 432 in my kitchen, however, the idea of life multiplying to keep my belly full is right in my face. How sickeningly first world.. :-) I actually wondered if it was a project designed to evoke such reflection.

<comment><USER10> I have gone flexitarian for this reason. As someone concerned with global warming, I found it troubling to eat meet regularly. Couple that with industrial agriculture and that did it for me. If its at someones place I won't make a big deal, but I basically won't buy meat unless its particularly hard to get around. Even then its pretty much only fish and chicken...

<comment><USER11> I've always found this fish-is-holier-than-red-meat take a bit confusing. Overfishing is a huge problem worldwide. Eating responsibly farmed beef, while expensive, seems less impactful than eating many (most?) types of commonly consumed fish.

<comment><USER10> [http://www.washingtonpost.com/blogs/wonkblog/wp/2015/01/07/w...](http://www.washingtonpost.com/blogs/wonkblog/wp/2015/01/07/why- the-governments-new-dietary-guidelines-could-be-a-nightmare-for-the-meat- industry/?tid=pm_business_pop)

Responsibly farmed usually refers to ethical treatment and has nothing to do with CO2. That being said, I am totally in agreement that eating fish has pretty substantial problems. The thing is that fish more wholistically face problems resulting from global warming including coral bleaching and ocean acidification to name a few. Overfishing and harvesting of marine life in nonsustainable ways is just that, but if you are selective about the species and the source it makes a big difference.

</comment></comment></comment></comment><comment><USER12> This is so weird. Are people really so set on eating animal protein that they'd rather eat insects than just eat plants?

Yes, this is incredibly more efficient than eating most animal products, but so are plant-based foods, which already exist, taste pretty good, and most importantly, are not completely and utterly revolting.

<comment><USER13> People in developing countries don't have the luxury of access to the variety of different plants you need to make a vegetarian diet work.

<comment><USER14> What gave you that idea? The overwhelming majority of India is vegetarian

<comment><USER15> Yeah, no: [http://en.wikipedia.org/wiki/Vegetarianism_by_country#India](http://en.wikipedia.org/wiki/Vegetarianism_by_country#India)

31% isn't an overwhelming majority. Plus you're saying that India should be the standard for scarcity of vegetables, which it clearly isn't.

</comment></comment></comment></comment><comment><USER16> What about taste? While bugs are a great source of protein, we don't eat foods primarily based on nutrition, we eat food based on taste.

I know Huhu or Witchetty grubs taste similar to peanut butter. And while peanut butter is nice and all, I want me some rich (but sustainable) beefy taste.

<comment><USER17> [https://edibug.wordpress.com/list-of-edible- insects/](https://edibug.wordpress.com/list-of-edible-insects/)

There are a couple of bugs listed, I couldn't find anything about beefy tastes though. Perhaps, it can be achieved with artificial flavors?

<comment><USER18> I've gone to a couple vegetarian restaurants where they've made some pretty convincing "beef", "chicken", "duck", and "pork" out of tofu, so why not insects?

<comment><USER19> But how were the insects raised, farmed and killed? Was it insectane?

<comment><USER20> I think the idea is that insects are so far down on the animal scale. For example, they don't really have pain [0]. At some point we have to relate animals to robotics. And insects are so low on the scale of intelligence it might as well be below our currently technology (Watson merely being massive specialized application of our current technology).

Where as animals like cows have emotions, can feel pain, have memory, personalities, relationships, etc. They are better than our current AI software in many ways.

[0] [http://relaximanentomologist.tumblr.com/post/51301520453/do-...](http://relaximanentomologist.tumblr.com/post/51301520453/do- insects-feel-pain)

</comment></comment></comment></comment></comment><comment><USER21> Reminds me of the movie Snowpiercer, where there is a scene with an industrial size device that creates protein bars from insects.

<comment><USER22> Geez, spoiler aler... never mind...

</comment></comment><comment><USER23> For those in the Bay Area, I highly recommend checking out Don Bugito. They've done a great job of making insects palatable for the uninitiated. Everyone I've taken to their food stand at Off the Grid has ended up trying some bugs (despite insisting they would not). You can also buy them pre-packaged at the Ferry Building. [http://www.donbugito.com/](http://www.donbugito.com/)

</comment><comment><USER24> Seems like a great source of protein for animals. Would be interesting way to feed chickens.

<comment><USER25> EnviroFlight is trying to do exactly that (create animal feed):

[http://www.inc.com/magazine/201406/bernhard- warner/envirofli...](http://www.inc.com/magazine/201406/bernhard- warner/enviroflight-turns-black-soldier-fly-larvae-into-food.html)

</comment></comment><comment><USER26> Definitely makes me think of the scene from Snowpiercer (spoiler alert) when they discover the protein blocks they eat are made of cockroaches.

</comment><comment><USER27> Austin, TX is at the cutting edge of the edible insect trend in the states. I had the pleasure of grabbing some mead and enjoying some snacks with a bunch of the companies down there.

Anyone doing anything with cricket-based foods in the US is likely supplied by World Ento (which recently merged with Aspire International). They're building a massive cricket farm in ATX to try to keep up with the demand.

</comment><comment><USER28> Why not just let the animals pasture and eat grass instead of feeding them grain? Factory farms are the big problem.

<comment><USER29> >>Factory farms are the big problem.

Is it wrong to say that factory farms are efficient and therefore less of a strain on resources?

<comment><USER30> They're cost efficient, not "resource efficient".

<comment><USER31> how is there a difference? less cost = less capital = less resources.

<comment><USER32> Human capital. Fertile ground is better used for food crops rather than animal feed crops. Marginal land is most efficient for grazing livestock. But hill farmed livestock is labour intensive and skilled dirty uncomfortable work to boot. Labour is expensive.

<comment><USER33> > skilled dirty uncomfortable work

Grew up on a farm on marginal land. Actually liked it.

</comment></comment></comment></comment></comment></comment><comment><USER34> One thing people often miss is that besides not looking very appetizing, some bugs don't really taste that great either. Well, it's more to do with the fact that they're just very bland or bitter. But, some animals are exactly the same. The reason that lamb, beef and chicken tastes "good" to us is because a: we've grown accustomed to the taste, and b: they've been _farmed_ to be palatable (breeding, diets etc).

In Japan, some fish are given special diets to alter their flavour. I don't see why we can't do the same with insects and worms.

[http://en.rocketnews24.com/2013/10/28/a-little-citrus-for- yo...](http://en.rocketnews24.com/2013/10/28/a-little-citrus-for-your-sushi- japan-producing-fish-with-the-natural-flavor-of-oranges-and-herbs/)

</comment><comment><USER35> If you're concerned about your CO2 footprint, one thing you can do without going as far as eating bugs is eliminating beef from your diet and eating only poultry. Minimal impact on your diet and about twice as efficient.

</comment><comment><USER36> I am pretty into high-end foodstuffs and really anything that tastes good, so I am somewhat surprised that my inner self says "bring on the bugs!". I think it would be kinda cool to eat an entirely new source of protein and know that I'm being just a tiny bit more sustainable.

Plus once in a while I get some pang of guilt about factory farming. Not gonna happen with cockroaches; I'm pretty sure there is no possible world where I develop sympathy for an insect.

</comment><comment><USER37> The widespread irrational disgust shamelessly expressed here, without regard for how expressing that disgust out loud is enforcing the status quo and contributing to the prevention of this ever being accepted in the mainstream, is exactly how I imagine the pervasiveness of homophobia in past generations.

...Which I think is a good thing, because it means it _can_ be eliminated through a cultural shift assisted by mass media.

<comment><USER38> Homophobia has not been eliminated and nearly everyone here expressing disgust has also stated that they realize their disgust is irrational.

</comment></comment><comment><USER29> Is insect protein better or more nutritious then protein directly from a plant?

</comment><comment><USER39> Are we considering this more humane because the creatures are smaller? You're still trapping hundreds of living beings into a tiny container. Don't get me wrong -- I eat meat and consider it ultimately a natural part of life. I just don't understand why flies are somehow okay to trap and confine, but cows aren't.

</comment><comment><USER40> Obviously more of an art project than anything else, but a brilliant direction to focus our thinking on. Insect protein really is a good direction to grow our meat consumption in, and if at first "toy" projects like this mostly provoke disgust, I hope in 25-50 years they will be in a very different position.

</comment><comment><USER41> "Farm 432" would be a great title for a dystopian science fiction novel. I'm imagining a fictional future Soviet Union where the citizens are fed with insect products from collective farms simply named "Farm #".

<comment><USER42> Maybe because of Fahrenheit 451?

<comment><USER43> I think it's more about the idea of grouping humans together by a generic number.

</comment></comment></comment><comment><USER44> "Why Not Eat Insects?" published by Vincent M. Holt in 1885, including recipes and menu suggestions:

[http://bugsandbeasts.com/whynoteatinsects/](http://bugsandbeasts.com/whynoteatinsects/)

</comment><comment><USER45> The "Farm 432: Function" video is good. What raised my eyebrow is two larvae from the harvest trap are selected for the next generation.

How do you know which gender the larvae will be? Would the inbreeding cause issues?

</comment><comment><USER46> I could see myself buying and using the device, but not eating the worms myself... The worms would feed pets and aquaponics fishes. Cats an dogs have little in a way of yuck factor. Fishes even less.

<comment><USER47> My cat will eat spiders and flies and then will say yuck when I serve her up some gourmet fish in jelly. "I had this exact same flavour last week!"

</comment></comment><comment><USER48> The impending insect protein era, for some reason reminds me of Peak-oil. Unless there is some marketing genius that makes eating insects sexy and drinking them cool, we will not usher into that era.

<comment><USER49> Oh, please, foraging for plants around cities has become trendy among the foodies.

A little marketing, a famous chef, and _presto_ instant delicacy.

</comment></comment><comment><USER50> I love that this is being discussed. I've often spoken to friends of the cultural cognitive dissonance Americans exhibit in being repulsed by eating terrestrial bugs, but loving shrimp, crab and lobster. Many Americans never see a whole shrimp and don't even realize that they have a bunch of antennae, legs, a head and would be considered completely horrifying to eat if they lived on land. Eating insects such as crickets is quite common in Mexico. Personally, I will stick to kidney beans and rice.

<comment><USER51> I think it may be because we don't eat the crab or lobster shell and all (although some eat shrimp shell). It may help widespread acceptance if there was a process where the meat was separated and made into some type of insect hamburger that could be texturized and flavored.

<comment><USER52> Crabs are eaten whole, shell and all, in the US - just only right after molting when they are called "soft-shell crabs." Come to Maryland during soft shell season, and you'll see them on every menu.

</comment></comment></comment><comment><USER53> If you're down with eating disgusting things and only interested in nutritional value why bother with insects and not skip directly down to algae/bacteria - my guess is since these are simple organisms they can be genetically engineered for mass production with low maintenance and "tweaked" for desired nutritional values. Risks of disease sound much lower too.

</comment><comment><USER54> At an earlier point in our evolutionary history we no doubt ate plenty of insects. Grubs, grasshoppers, crickets, ants, termites... pretty much whatever we could get our hands on.

This practice was generally discarded by humanity except for niche pockets here and there.

Why? I mean... there must be a reason humans (for the most part) stopped eating insects.

<comment><USER55> Insects are eaten in most of the world. [http://en.wikipedia.org/wiki/Entomophagy](http://en.wikipedia.org/wiki/Entomophagy)

</comment></comment><comment><USER56> Even if they just ground up so they are unrecognizable and added into other foods, that would be a huge accomplishment. Imagine getting 5% of your calories from insect sources, without knowing, an it replacing something like starch. It could be added to virtually anything.

<comment><USER57> Maybe as an ingredient for breakfast cereals, muesli bars and things like that?

</comment></comment><comment><USER58> The article mentions killing by freezing. Does freezing change the texture of the bugs?

<comment><USER59> It might just be an efficient way of killing them that everyone can use. According to 'Insects Are Food': [http://www.insectsarefood.com/recipes.html](http://www.insectsarefood.com/recipes.html)

"Prior to preparing your crickets for a meal place them inside a plastic container or storage bag and keep them in the refrigerator at least for an hour or until you are ready to use them. This will not kill the crickets, but rather slow down their metabolism, inducing a state of hypothermia, in other words, prohibiting their movement when removed from container. If you prefer however, as many people do, feel free to place them inside the freezer for an hour or two as this will definitely kill them, guaranteeing their immobility.

After removing from refrigerator or freezer, place them in a pot of boiling water sized to hold the specific amount of crickets you're using. Add a few pinches of salt. Boil for about two minutes. This ensures cleanliness. Once boiled, remove from water and let cool. Crickets at this time can be placed in storage bags and kept in the freezer or used right away for any number of recipes. All crickets should be prepared in this manner prior to eating."

There also appears to be discussion of what the most human way to kill farmed insects is: [http://en.wikipedia.org/wiki/Welfare_of_farmed_insects](http://en.wikipedia.org/wiki/Welfare_of_farmed_insects)

<comment><USER58> Right, but I am wondering if the taste or texture is noticeably different.

</comment></comment></comment><comment><USER60> Horrified at that second video. You can't use a metal fork on a nonstick pan!

</comment><comment><USER61> Yup not eating insects anytime soon :) The device looks cool though.

</comment><comment><USER62> I'll keep waiting for cultured meat, thank you very much. Now excuse me as I attempt to use needles to purge the sight of those 'meals' from my retina.

</comment><comment><USER63> I would totally buy this. I don't mind eating insects.

<comment><USER59> Here are some protein bars made form Cricket flour for you to munch on in the meantime: [https://www.exoprotein.com/](https://www.exoprotein.com/)

</comment></comment><comment><USER64> With fish stocks and aquifers fast depleting, it seems inevitable that it'll become normal for citizens of the developed world to dine on bugs.

</comment><comment><USER65> The funny thing for me — it is less the insects that are off putting and more the sterile environment they are raised in.

</comment><comment><USER66> Really cool. I would definitely be interested in trying this out depending on the price point.

</comment><comment><USER67> My mouth was salivating while reading the website. I think I'm ready to eat bugs.

</comment><comment><USER68> i'm trying to wrap my head around this, but im leaning towards engineering vegetables with high protein... or enhancing nut production.

</comment><comment><USER69> probably the insects were the first source of protein for the humanity

</comment><comment><USER70> Why not just go vegan? Pulses are relatively easy to grow and have great nutrition.

</comment><comment><USER71> no

</comment><comment><USER72> This is gross! Humans should be consuming less animal protein, not inventing more new efficient ways to breed, torture and consume more.

How about considering sustainable vegan/vegetarianism before inventing personal bug death cathedrals. Sick and wrong. Burn it!</comment>


Apple Rolls Out Their New MacBook Pro Series - <AUTHOR> http://www.apple.com/macbookpro/features.html

<comment><USER2> Here are the differences I see:

-Intel Core i5/i7 on 15/17-inch models.

-Longer lasting batteries (10hr for 13-inch and 8-9hr for 15/17-inch)

-GPU upgrade to 330M from 9600M GT on 15/17-inch models and 320M on 13-inch models

-Intel HD Graphics

-Option to get a higher resolution screen (1680x1050 for 15-inch) with "antiglare"

Anything else?

<comment><USER3> There have been major performance bumps in the CPU/graphics board, with automatic graphics switching in between the Nvidia 330M and the integrated Intel HD chipset. That should improve battery life.

More details : <http://www.apple.com/macbookpro/performance.html>

Also, you can order a screen with 1680 by 1050 resolution on the 15" MacBooks.

Still, on the whole having a hard time getting very excited about the update. It's a refresh as opposed to a major update.

<comment><USER4> The previous version didn't offer 1680x1050 at 15"? I consider that a necessity.

</comment></comment></comment><comment><USER5> Pricey. For the cost of a 17" MacBook, you could instead get a quad-core i7 desktop, an SSD for the boot drive, 2TB of RAID-1, and a 30" monitor.

This is why I go the desktop/netbook route. Cheaper overall, and the laptop is basically disposable. If you break it or lose it, oh well. Not the case with the Macbook.

<comment><USER6> I took the netbook-only route. Never looked back.

All my code is on version control, mail and calendar are "on the cloud" and all important files are rsync'ed to another machine that would be perfectly happy with a serial terminal (but has hardware accelerated graphics because it was cheaper this way).

On my desk you will find a mouse, a monitor and a notebook stand. No need for more, really.

<comment><USER7> Which netbook do you have?

<comment><USER6> An Acer Aspire One, the one with the hard-disk. I got it upgraded to 1.5 gigs.

</comment></comment></comment></comment><comment><USER8> Are i5's and i7's really much faster? The clock-speeds are basically the same. I know there's more to it, like cache size and such, but clockspeed and number of cores is a lot of it, and that only changed slightly. (2.33GHz->2.4GHz for the cheap 15", I believe.)

<comment><USER9> They are in fact dramatically faster.

</comment></comment><comment><USER4> No quad-core? Considering Apple's popularity with developers and media creators, I expected to see the option.

<comment><USER10> Unless I'm mistaken, there's no mobile quad-core Arrandale CPU. You'd have to go to a non-mobile chip, with TDP in a completely different ballpark.

<comment><USER4> The quad-core mobile part is designated Clarksfield. TDP is 45W for the lower- clocked models and 55W for the highest. The Arrandale chips Apple is using are 35W.

</comment></comment></comment><comment><USER11> Was the Air updated as well? I've been waiting for it to get 4GB of memory since it came out.

<comment><USER10> doesn't look like it.</comment></comment>


The cult of the faceless boss - <AUTHOR> http://www.economist.com/businessfinance/displaystory.cfm?story_id=14844995

<comment><USER2> My suggestion for a better title: "The lament of the business journalist"</comment>


It's really not cool when you see blatant design ripoffs like this. - <AUTHOR> https://twitter.com/yongyisung/status/338895791206846464 <comment><USER2> Isn't it possible it's a generic template they both used? There's no investigation as to whether there really is one ripping off the other, nor which one would be ripping off the other.

This is really just saying "these sites look just like one another, let's make assumptions and vague accusations about them with no evidence."</comment>


Scientists say WHO ignores the risk that coronavirus floats in air as aerosol - <AUTHOR> https://www.msn.com/en-us/health/medical/scientists-say-who-ignores-the-risk-that-coronavirus-floats-in-air-as-aerosol/ar-BB16kGjC <comment><USER2> In India, hot and stuffy offices are now running without AC. Can centralized and split ACs be upgraded easily to limit aerosol spread?</comment>


Show HN: World Cup API for 2018 - <AUTHOR> http://worldcup.sfg.io/ <comment><USER2> Timezones look wrong. This is the stamp for today's match:

2018-06-14T17:00:00.000-05:00

Moscow is GMT+3, and kick-off is 18h local time (i.e. 15h GMT). Not sure what combination of stuff has gone wrong there!

<comment><USER3> Yes, the minutely update seems to be off by 2 hrs at least. The first match is already 3:0, but the API still has 0:0

</comment></comment><comment><AUTHOR> Hi all -- Sorry for not updating sooner -- FIFA changed things significantly from 2014 and I had to do a bunch of updating to the scraper to use headless chrome to pull in updates via JS to get all the events working again.

Everything should be working in real time for tomorrow's games. Real time goals, matches marked completed after they are officially over, and an event stream of goals, subs, and cards.

Sorry for delay, hard to scrape data until it actually exists, and besided the 50+ emails I got in the past few months asking me to make it work for 2018, I was the only one making PRs ;)

Should be good to go for tomorrow, please file a github issue if you see any problems.

</comment><comment><USER4> There are a quite a few problems with this. We are 31 minutes into the first game (Russia vs Saudi A) and it is 1 - nil.

This feed (although updated each minute) is not reflecting the score. Also the current game endpoint is empty.

As one poster has pointed out the timezone setting are wrong which could be why.

<comment><AUTHOR> nope, was just problems with scraping data -- can't scrape data until it exists (FIFA is using a new CMS for World Cup 2018 that uses a fair amount of JS), and I couldn't get all the events that are used to mark a match officially completed.

Should be working now for the next games. First day is always a bit of a mess.

</comment></comment><comment><USER5> WhoScored and the StatsZone app are both wonderful to scrape if anybody wanted to poke around harder for more detailed data.

</comment><comment><USER6> This looks great! The background page says you were scraping the data from websites. Are you still doing that? If so:

\- did you ask permission? Did you feel you had to?

\- do you have problems with sites accidentally/deliberately breaking your parsing code?

</comment><comment><USER7> Slightly related: My friends have created [https://wcfixtures.football](https://wcfixtures.football). For some reason they only made it work on mobile. We did a similar one back in 2014 but I was not involved in this one. I imagine they use [https://www.football- data.org](https://www.football-data.org) or scape themselves.

<comment><USER8> Forgot to say thank you for this. I had a look at this yesterday and I love it. So clean. - pass on my thanks to your dev friends.

</comment></comment><comment><USER9> Hey guys, I just created an API with my App for WhoScored. Its currently running very 15mins.

[https://getdata.io/data-sources/5470-football-statistics- foo...](https://getdata.io/data-sources/5470-football-statistics-football- live-scores-whoscored-com)

Will update again once I got another API setup for StatsZone when ready.

By the way, how often do you guys need data refresh for? Once I get some feedback I could tweak my app to increase the number of frequency.

Also please do ping me if you want to register your webhooks. My app only supports only one webhook per API at the moment. I will try to get it properly extended so that all your webhooks can get registered.

My email address is firstname.lastname@example.com

</comment><comment><USER10> Nice! I built a World Cup IRC bot back in 2014 but couldn't find a reliable API. In the end I found the only way I could get realtime results was by streaming from the official Twitter page, as they posted live match updates in a (reasonably) predictable format.

All the best with your API this World Cup!

</comment><comment><USER11> [http://worldcup.sfg.io/matches](http://worldcup.sfg.io/matches) The time zone seems off. I get "datetime": "2018-06-14T17:00:00.000-05:00" for the first match.

It should however be 17:00 for CEST (UTC +2)

<comment><AUTHOR> Time zones are always a pain, I'll check into it now that I got all the events working!

</comment></comment><comment><USER12> I've been using [https://www.football-data.org](https://www.football-data.org) which is also an API for the World Cup, does anyone know the pros and cons of the 2?

</comment><comment><USER13> Anyone got a lambda based slack bot for WC?

<comment><USER14> You can try this [https://guessthewinner.blinch.site/](https://guessthewinner.blinch.site/) (I built it) You can read about it here: [https://medium.com/@blinch/what-did-i- learn-while-building-a...](https://medium.com/@blinch/what-did-i-learn-while- building-a-product-for-offices-watching-the-world-cup-6e32220bfae4) Help me share it, this is my first response in HN

</comment></comment><comment><USER9> I don't see any match related data from StatsZone at the moment, but I have created an API for the world cup related news articles that are being published on the site.

[https://getdata.io/data-sources/5471-fifa-world-cup- fourfour...](https://getdata.io/data-sources/5471-fifa-world-cup-fourfourtwo- world-cup-news)

I will check again to see if there are any new data once the match starts and then create an API for those too.

</comment><comment><USER15> The FIFA API is hard to understand but has all of the info as well. Here's a list of all matches in the group stages; I don't believe the round of 16 matches have been generated yet.

[https://gist.github.com/dmlittle/9733711dcfa638b304884198d75...](https://gist.github.com/dmlittle/9733711dcfa638b304884198d759deba)

</comment><comment><USER16> Has anyone made a dashboard out of this? Would like to put something on our displays at the office but no time to do it myself!

<comment><USER17> You can try: pip install worldcup

And then: watch -n 60 worldcup today

And just make the font in the terminal window huge :)

<comment><USER18> At least on my server, I needed to run

        pip2 install worldcup       # didn't like Python3
        watch -cn 60 worldcup today # -c for colours

Also the time handling seems wrong - it claims Russia vs Saudia Arabia will be "9 hours from now" except it kicks off in 2.5 hours...

<comment><AUTHOR> yup, all events and goals should happen in real time starting tomorrow, first day is always a mess because it is a scraper and FIFA is using a new CMS this year. Thought I had it worked, but had to make some sig changes to account for lots of JS.

Events and status changes and goals should all update in realtime now.

</comment></comment></comment></comment><comment><USER19> [http://worldcup.sfg.io/matches/country?fifa_code=cro](http://worldcup.sfg.io/matches/country?fifa_code=cro)

Internal Server Error?

I was expecting 404 in the worst case, but parameter case conversion (upper to low and vice versa) would be a better solution.

</comment><comment><USER20> Nice. Build a little py script for work. :]

[https://gist.github.com/int9h/83373326174ce8dab25a333a9c36f0...](https://gist.github.com/int9h/83373326174ce8dab25a333a9c36f0d3)

</comment><comment><USER21> I tried loading over HTTPS and got the following error:

        This server could not prove that it is
        worldcup.sfg.io; its security certificate
        is from *.herokuapp.com. This may be
        caused by a misconfiguration or an
        attacker intercepting your connection.

<comment><AUTHOR> I'll look into HTTPS, heroku says it is configured fine for worldcup.sfg.io, browser says it isn't, browser wins :)

</comment></comment><comment><USER22> Kinda unrelated but does anyone know where do Google get the win probability numbers from on the match pages? Is it something scientific or some "social" numbers (like which team is more popular, more searches etc.)

<comment><USER23> I believe they use the ELO Ratings[0]. they have the Win Probability on their website[1].

[0] - [https://en.wikipedia.org/wiki/World_Football_Elo_Ratings](https://en.wikipedia.org/wiki/World_Football_Elo_Ratings)

[1] - [http://eloratings.net/fixtures](http://eloratings.net/fixtures)

</comment></comment><comment><USER24> Nice, is there an end point to get the champion?

</comment><comment><USER25> Is there no official API?

<comment><USER26> There are definitely other APIs for commercial use that don't rely on scraping but the problem is that they aren't free. Sports data can get very expensive.

<comment><AUTHOR> They are expensive, hence a free one

</comment></comment></comment><comment><USER27> It's 'Colombia' not ,Columbia'</comment>


Swift is faster than C++ - <AUTHOR> https://twitter.com/relativetoyou/status/758438501050441728 <comment><USER2> If you are naive about data access, like in this case of inserting into an array without preallocation, C++ STL collections are pretty slow. I once wrote an algorithm that made heavy use of dictionaries in C++ and Python and the Python version was significantly faster. C++ just does not have fast general purpose collections in the standard library.

</comment><comment><USER3> Sort of. I bet I could take a snippet of C++ and find flags which would slow runtime right the heck down myself.

</comment><comment><USER4> Not that we needed it, but more evidence that the adjectives "faster" and "slower" are overloaded to the point of meaninglessness when discussing compilers and languages.

</comment><comment><USER5> Yeyyy.. hurrayyy ... ok back to work.</comment>


MetaMind acquired by Salesforce - <AUTHOR> https://www.metamind.io/salesforce-acquisition <comment><USER2> It's very hard to find a viable business model in machine learning or AI tools and platforms at the moment: the size of the market is small, and most money is being made by the end users. As a result companies who could get value from AI want to own it themselves (to keep all of this money themselves). It's a little bit like everyone wanting to own their own data center full of servers in 1999; at some point it will seem silly, but it's hard to sell against because it's accepted wisdom.

Doing services is a reasonable response to that market dynamic, although they certainly had a product vision too.

Without knowing any of the details, I'd say they can be proud of what was accomplished and how they managed their exit: 1\. From what I've heard, some of the work they did in the medical domain really did help save lives or make them better 2\. They probably returned the capital to their investors and kept most of their employees 3\. They didn't get bought by a company that would be horrible to work for or is in terminal decline

Credit where it's due: they entered a rough market and managed it well.

</comment><comment><USER3> I think it is mainly an acquahire.

Metamind was always a services company. I may be wrong but they don't seem to have any product. They were going after contracts north of $250K for two month projects.

May be there is not much dough in consulting market.

<comment><USER4> Consulting doesn't scale as well, because you need people to do the work. In theory, with an product, you only need people to sell it. The cost of selling software is expensive, but still much less than the cost of delivery consulting.

</comment></comment><comment><USER5> I assume this page is soon to join the clan over on "Our Incredible Journey".

[http://ourincrediblejourney.tumblr.com/](http://ourincrediblejourney.tumblr.com/)

<comment><USER6> That is the most depressing thing I've seen all week.

</comment></comment><comment><USER7> In this new environment, when I see an acquisition, I wonder if it was a forced one b/c of lack of VC funding.

<comment><USER8> MetaMind would have been able to raise any amount of money they wanted. Any sensible VC knows that Richard Socher is as close to a sure bet as it is possible to get.

<comment><USER9> A sure bet for what? Metamind as a company failed.

<comment><USER8> What makes you say that?

</comment></comment></comment></comment><comment><USER10> "For unpaid web users, MetaMind's products will be discontinued on May 4. For our monthly recurring users, MetaMind's products will be discontinued on June 4."

</comment><comment><USER11> All the best to the metamind team in their new adventure. For users of the metamind, Heuro Labs GmbH (Disclosure: I am the founder) offers a unified api for data mining supporting multiple modalities, streaming input directly from Social Media, etc. and built from the ground up to be a data fusion pipeline [http://api.cognitio.heurolabs.com/#/signup](http://api.cognitio.heurolabs.com/#/signup) Swagger docs: [http://api.cognitio.heurolabs.com/assets/docs.html](http://api.cognitio.heurolabs.com/assets/docs.html) Wiki: [https://heurolabs.atlassian.net/wiki/display/CogniDoc/Overvi...](https://heurolabs.atlassian.net/wiki/display/CogniDoc/Overview) Demo: [http://web.cognitio.heurolabs.com/](http://web.cognitio.heurolabs.com/)

</comment><comment><USER12> As usual, folks that make breakthroughs in science have a hard time commercializing their tech. In this case, the team behind Metamind will make off a lot better than William Shockley did, though this definitely seems like an acquihire.

</comment><comment><USER13> I wonder how much did Benioff being on the board have to do with this?

</comment><comment><USER14> I wonder where Salesforce is going to integrate MetaMind's technology. From afar, the overlapping use cases aren't obvious.

<comment><USER6> "With MetaMind and Salesforce coming together, we'll be able to offer customers real AI solutions with breakthrough capabilities that further automate and personalize customer support, marketing automation, and many other business processes."

They want conversational AI for phone support, cold calling, etc.

<comment><USER15> There is a lot more than that - just reading case filed to understand what the request is about is tough. There are many ways humans can be augmented by modest AI. SFDC has so many products within their various clouds where even modest, but accurate classification could be a gold mine.

Personally, I think we are fairly far away from fully conversant customer support that is fully automated, yet sounds human enough. Most people today do not yet like talking to machines.</comment></comment></comment>


Precursor – A mobile, open source electronics platform - <AUTHOR> https://www.bunniestudios.com/blog/?p=5921 <comment><USER2> I must admit while this cool, what I really want is a standard dirtcheap 8 to 10 inch Android tablet with a hackable OS and a row of gpio pins on it like the raspberry pi. $50 will get you a lot of power and convience today as these things are two a penny due to economies of Scale. Throw a usb-c video input and output onto it too, so it can use it as a touch screen monitor for my phone too. and I'm sold

<comment><USER3> It sounds like what you're looking for is the Pocket C.H.I.P. The company went out of business, but I bought one back in the day and it was so fun to hack around with.

While writing this comment, I discovered that there's a website selling new old stock? Can't vouch for its authenticity, but you should go for it! [https://shop.pocketchip.co/collections/frontpage/products/po...](https://shop.pocketchip.co/collections/frontpage/products/pocket- c-h-i-p-new)

<comment><USER4> I don't think that is akin to an 8 to 10" Android tablet/screen. Then again, I don't see how all the other products are related to the one mentioned here. Except they're all hackable?

If you want a small device to play old games on via an emulator, I can recommend Pocketsprite [1]. You can even assemble one yourself.

FWIW, I'm looking for a small portable screen (1080p, IPS) to combine with my MBP 2015 (via TB2 or HDMI but I also want it to have USB-C for future compatibility).

[1] [https://pocketsprite.com](https://pocketsprite.com)

<comment><USER5> If just looking for a portable display, there are plenty on amazon. I bought a Chinese brand, magedock, because they had a touch screen 1600p model that was more portable than the others (no battery though).

<comment><USER4> Yeah, Amazon is such a rain-forest though. There's a plethora of devices there, and I don't trust the reviews. I'd prefer a 14", don't require touchscreen (though if it would cost me 50 EUR, I'd go for it, but not double the price like ThinkVision M14t). Speaking of which I've seen the ThinkVision M14 for 180 EUR, that's a fair price. It has high brightness of 300 nits (better than the Asus one, of which the 16" gets recommended a lot even though its barely readable in sunlight), though reportedly also has coil whine. However, it _only_ supports USB-C. So I would need some kind of adapter I guess. A lot of the Chinese stuff has the adapters included, but even the brandnames just don't make sense. Magedok was out of stock (they didn't have Magedock). Battery I don't care for; I'd just hang a powerbank behind it with velcro.

</comment></comment></comment></comment></comment><comment><USER6> At the risk of wanting this to be something that it's not - what's the reasoning behind not targeting Precursor towards running (embedded) Linux? With a little more RAM it seems like the specs would make it a great fit for Linux, which might allow for a broader ecosystem of use cases?

Is there something I'm missing that means developing a new OS ([https://github.com/betrusted-io/xous-core/](https://github.com/betrusted- io/xous-core/)) works better for Precursor? Keen to understand the rationale, cause I think I'm probably missing something here!

edit: There's a good explanation on the CrowdSupply page - seems like it's in order to make it a more secure platform:

> Simplicity addresses the reality of only having 24 hours in a day. Even > though the full source code for the Linux kernel and Firefox is published, > nobody has the time to personally review every release for potential > security problems; we simply trust that others have done a good job, because > we have no other choice. Precursor rolls the clock back to the early 2000's, > when mobile computers were powerful enough to be useful for single tasks, > while simple enough that individuals or small teams could build them from > scratch. But don't worry, despite its simplicity, Precursor's computational > capability exceeds that of the Palm Pilot series. It's more on par with a > Nintendo DS: sufficient for core security tasks such as authentication, > instant messaging, crypto wallets, and even end-to-end encrypted voice > calls.

<comment> arc-in-space This is something that worries me about this project. Is the focus more on hackability, or security/inspectability? The messaging is unclear, and this decision looks like a big sacrifice of the former for the latter. I'd maybe be interested in this device but only for the purposes of DIY messing around, I'm nowhere near so worried about security I wouldn't trust the linux kernel.

<comment><USER7> This project is definitely security-first. That being said, we're defining "hackability" as "empowerment to hack". For example, this is one of the few platforms where you can hack the CPU itself by adding new instructions to it.

</comment></comment></comment><comment><USER8> Wow, this looks awesome.

This formfactor, combined with a LoRa transceiver would be epic as an off-grid or fallback comms device.

I get fuzzy cyberpunk feelings imagining it.

Bunnie's projects are always intriguing. I'm still amazed by the investigation into sd card controller chips.

<comment><USER9> What is LoRa?

<comment><USER10> [https://en.m.wikipedia.org/wiki/LoRa](https://en.m.wikipedia.org/wiki/LoRa)

</comment></comment></comment><comment><USER11> This scratches a fairly specific itch I've had for quite a while now — portable DIY electronics. At the moment, even if you use something as Lego- like as Adafruit's boards [1], you still need your primary logic board, a separate module to handling charging, a battery pack, a case that holds all of the above in place neatly, and more. Personally I don't find the keyboard to be a very attractive feature of Precursor, but all the rest of this project is super exciting and I can't wait to see them deliver on it.

[1] [https://www.adafruit.com/](https://www.adafruit.com/)

<comment> semi-extrinsic Personally I just use ESP32 (specifically Lolin D32) in an altoids-type box with a run-of-the-mill small USB power bank taped to the back. Usually with some level shifters and stuff to run the Blinkenlights (FastLED + ws2813).

If that's too ghetto for you, have a look at the M5Stack series. A main unit (ESP32, screen, speaker, TF card reader, in a case with some buttons) costs $35, and the battery module you can stack on is $10. There is even a keyboard and a gameboy-like attachment.

I like the look of the Precursor, but personally the FPGA is a bit off- putting, just because I've never gone down that road.

<comment><USER12> Step up to FPGA. There has to be a first time.

</comment></comment></comment><comment><USER13> This looks lovely. I've long been looking for a hackable device in this form factor, albeit more with the intent of running Linux.

One thing I can't find any detail on is the keyboard. Making a keyboard from scratch is well outside of usual low-volume productions and there aren't any readily available parts in this form factor as far as I know. How is the Precursor's one made/sourced?

<comment><USER7> I'll be writing an article on this in the future, and you're right, the keyboard was a serious pain to build. It's one of the big reasons it took two years to bring the product to this state.

<comment><USER13> Thanks, I'm excited already!

I'm using a Blackberry keyboard for my project, but that's obviously not scalable.

</comment></comment></comment><comment><USER14> Bunnie (as you seem to be around here) — can the accel/gyro values be read/sampled? They're listed under the "anti-tamper" category on crowdsupply so I wasn't sure. Are there some specs on max Gs, sample rate, etc.?

—

I find this device extraordinarily appealing (will definitely be backing). Bunnie is a hardware hacker's hacker, the project has at least 2 years of development behind it. It will most definitely ship, and work. Ha.

But — I'm specifically excited because this seems like an ideal platform to build whimsical mobile hardware projects.

My dream of a 2000-era electronic organizer with a "retro" (non touch) display, with physical keyboard, and battery, and programmable/hackable and fully open... this is truly a dream come true.

Why couldn't this become the democratizing mobile Arduino-like hobbyist "base"?

I'm extra, extra excited about it!

(And dream of adding LTE and making a retro minimal... phone OS/"app"? Fast email + wikipedia clients??)

<comment><USER7> Thanks for the enthusiasm! I happen to be up really late tonight, but I'm going to bed soon. Thank you for the support and kind words.

The accelerometer is the LSM6DS3, I'll refer you directly to the manufacturer's website: [https://www.st.com/en/mems-and- sensors/lsm6ds3.html](https://www.st.com/en/mems-and-sensors/lsm6ds3.html)

You can find out more about how it's integrated at [https://github.com/betrusted-io/betrusted- hardware/blob/mast...](https://github.com/betrusted-io/betrusted- hardware/blob/master/mainboard-dvt1/trusted_io_dvt1.pdf) (note: this is a "DVT" schematic, bugs were found, they are currently being fixed, but they aren't related to the accelerometer).

The TL;DR is that the accelerometer is integrated so that it's in the "always on" untrusted domain, so to access it from the main FPGA "SoC" you have to go through the system controller FPGA ("EC" as we call it). The idea is for it to be available in power down states for anti-tamper, hence the extra layer of complication.

Talking to it requires a call to the EC via the "COM" bus ([https://github.com/betrusted-io/betrusted- soc/blob/master/fw...](https://github.com/betrusted-io/betrusted- soc/blob/master/fw/src/main.rs#L849)). The EC driver itself is based on the C-native library provided by STM and translated into Rust bindings. It's a little gross: [https://github.com/betrusted-io/betrusted- ec/blob/master/sw/...](https://github.com/betrusted-io/betrusted- ec/blob/master/sw/gyro_bindings/src/lib.rs)

Hope that helps.

<comment><USER14> You don't know how flustered I am at your response. Thank you so, so much...!

</comment></comment></comment><comment><USER9> I really dig the slim and professional form factor, a lot of "portable" open- source hardware projects look like a bunch of PCBs stapled together, with wires and connectors hanging out everywhere.

</comment><comment><USER12> I just learned of "dynamic reconfiguration", where a running device configures and commits additional logic units to a temporary task.

Is that possible, in principle, in a Spartan 7?

It is easy to believe that you would need to pre-generate bitstreams for each configuation, and could only swap them in verbatim, not generate them on-the- fly, but downloading from a library, perhaps with parameterized choices, could increase flexibility.

<comment><USER15> Most current FPGAs offer the option to have one configuration select a different bitstream in the configuration memory and have that replace itself. That allows a simple menu configuration to let the user select between several actual configurations. Or it allows over the air updates.

In the specific case of Xilinx FPGAs there was a feature introduced in the original Virtex called "partial configuration". This has been present in all its products for the last 20 years. It allows a design to be broken into parts such that one part may be replaced even while the rest of the FPGA continues to work normally. This is pretty hard to use and the interface between the part being swapped and the rest of the circuit is rather tricky, so it has been use more for cool demos than actual products.

It is possible to have the equivalent to this with non Xilinx FPGAs by having several smaller ones connected to each other on a board. Then dynamic reconfiguration of one can happen while the others continue to work normally.

<comment><USER12> Thank you. I guess it would be a bit much to hope for more auxiliary FPGAs on such a portable device.

</comment></comment></comment><comment><USER16> This looks very nice, and actually pretty rugged. A few thoughts:

* Would it increase the complexity a lot to provide a linux-capable SoC as an additional chip? (OK, this could be a daughter board)

* "iCE40UP5K SG48, 98% utilized" <\- isn't it a bit restrictive to start with such a low room for growth?

<comment><USER7> The iCE40UP5K is not the main processor. It's the embedded controller. Think of it as a power management coprocessor that takes care of things like managing the battery while the main CPU is asleep. It is packed to the gills, but the iCE40UP5K is low enough power to remain on and not drain the battery for several days.

The main CPU is a Spartan7 XC7S50, which has plenty of space for things like crypto accelerator cores beyond the primary RISC-V CPU.

<comment><USER17> What kind of crypto accelerator would be most interesting to people?

<comment><USER18> What I think would be most interesting is whatever primitives are needed to build fancy cryptosystems which are resistant to EMI/DPA sidechannels.

Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).

But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.

Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).

Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.

<comment><USER7> We've got a curve25519 accelerator for the reference hardware: [https://ci.betrusted.io/betrusted- soc/doc/engine.html](https://ci.betrusted.io/betrusted-soc/doc/engine.html)

</comment></comment></comment></comment></comment><comment><USER19> Interesting project but it seems like the schematics require proprietary and extremely expensive software to look at. Certainly beyond hobbyist reach. Why not develop with open source tools like Kicad? Kicad these days is mature enough to handle a project of this scale easily.

</comment><comment><USER20> super interesting. I know things cost money, but I really hope they can hit a price point similar to pinephone or wiphone.

</comment><comment><USER21> I remember there was a similar attempt years ago (probably between 5 to 10 years ago). I forgot the name of the startup but they were trying to build a non-phone mobile device that's programmable. I actually applied for beta testing and got one for free, but they ended up going out of business. I remember the color was ruby-ish. Can't remember the name. Anyone know what this was?

<comment><USER22> Are you thinking of the long-delayed DragonBox Pyra from the Pandora community?

[https://pyra-handheld.com/boards/pages/pyra/](https://pyra- handheld.com/boards/pages/pyra/)

<comment><USER21> no the project I'm talking about looked similar to this one but a bit shorter vertically, and the one I owned had a dark pink (or ruby) color. Had the same blackberry type keyboard too. It was a startup, and they shut down eventually.

</comment></comment></comment><comment><USER23> For me the attraction is a reasonable screen and keyboard - that sort of interface is by far the most difficult part of hardware projects.

</comment><comment><USER24> I found a typo where the "are" is duplicated:

> enclosure's length and thickness are are parameterized.

<comment><USER7> thanks, fixed.

</comment></comment><comment><USER25> Does that FPGA come with software tools that are backed by the FPGA vendor?

<comment><USER26> The XC7S50 is a Spartan7, which is supported by Vivado's WebPack edition (free but with many non-FOSS parts) as well as the FOSS SymbiFlow toolchain (I can't figure out which Place-and-Route tool that targets Xilinx 7-series parts they're using from the docs, but they imply one is at least vaguely usable) too.

The iCE40UP5K will work with any IceStorm-based FOSS toolchain (including SymbiFlow) as well as Lattice's free first party Radiant tool (and I think also the older IceCube2 toolchain).

It's a little odd that they're different vendor parts / on different 1st party toolchains, but it does look like you could program everything through the FOSS tools, albeit probably missing a few features (Last I looked a couple of the special purpose blocks in both the Xilinx 7-series and the UltraPlus were not fully understood by the FOSS stuff; that may have changed).

I've been meaning to try Radiant, I teach some classes on top fo Vivado + Artix7 FPGA dev boards, and it's so much less awful than ISE (Xilinx's old toolchain) I'm still pleased with, but there are some nice, affordable iCE40-UltraPlus boards coming on the market, and if Radiant is less of a hassle (Vivado is a 25GB install and not _entirely_ beginner-friendly) I'd consider retooling.

<comment><USER19> Isn't Spartan a legacy platform?

<comment><USER26> The Spartan 3/3E/6 lines are legacy parts (and hence stuck on ISE for programming, so you don't want them). The Spartan 7 parts were a late addition (not shipping until 2017) to the 7th gen line for the low end; they use the 7th gen blocks and tooling, but are "cost optimized" and lack the fancy transceivers and such - though irritatingly the cost and resources of the Artix and Spartan parts have a lot of overlap; Spartan7 parts run from about $15-140 in single, Artix7 parts from about $25-430.

</comment></comment></comment></comment><comment><USER27> Seriously cool. Love the attention to detail. I'll definitely back whatever funding campaign is launched for this, I've got the perfect project in mind for a portable secure controller.

</comment><comment><USER28> I love this. I like the form factor. I like the versatility of it that is being thought of from the start.

</comment><comment><USER17> I just want a modern EEEPC in a 7" format with an FPGA for a brain rather than any processor, so you can build whatever you want.

</comment><comment><USER29> The FPGAs could still be backdoored, and the WiFi chipset should receive a fair bit of suspicion. But I guess it is a good first step.

<comment><USER30> It'd be a pretty gargantuan task to backdoor the FPGA silicon itself. You'd have to have compromised Xilinx's software and had some idea of what signals you want to tap. Kinda interesting to think about... I suppose that's were open source tools for FPGAs would be nice.

The image? Sure, could easily be backdoored, but that's what open source is for; auditability.

Edit: FPGA silicon is kinda backdoored by definition thanks to JTAG configurability/readability. (Barring cases where keys are used.) So I think the really interesting thing would be addition of nefarious logic by the design tools.

<comment><USER29> Well, yes, but in the past this type of device would be floated as an attempt to fight state-level actors. And... it can't do that. That's all I'm pointing out.

Either the silicon, the synthesis software, or both could be compromised. Per leaked documents usually what gets attacked is random number generation, but there are more avenues I am sure.

You can usually turn off JTAG, but having JTAG or other debug interface not be permanently disabled is actually an exploit class.

<comment><USER31> What's stopping the toolchain for your micro from being backdoored as well? The chain of trust has to start somewhere.

<comment><USER32> This is the likely target for NSA. Intercepting supply chains for stock parts inside of China is not their specialty. Further, to bother with custom hardware would require substantial resources and time to develop before even getting it deployed. Nobody is going to do that. Bunnie's compiler just changed checksum...

To fight such an attack, the output of deterministic builds running on geographically dispersed systems with disparate stacks (physical, cloud, newly purchased, multiple OSs, etc.) may be compared before release.

The protected body of software should also include the firmware upload utilities.

Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.

<comment><USER33> _> Intercepting supply chains for stock parts inside of China is not [the NSA's] specialty_

 _> Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted. _

I like thinking about high-level threat models as much as the next guy, but these two statements seem to be at odds. Unless by "compromised units" you don't mean what I think you mean.

<comment><USER32> First was referring to supply chain interdiction for third party fabricators attempting to produce non-compromised units. Second was referring to active fabrication and distribution of compromised units to unsuspecting consumers.

<comment><USER33> Oh, ok. So its the difference between opening the box to put in a wayward chip, versus starting a factory who makes units with the wayward chip to begin with. Fair enough.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> Best name.

</comment><comment><USER35> modern pocket calcs

<comment><USER36> [https://www.numworks.com/](https://www.numworks.com/)

<comment><USER35> that's modern old school calcs, huang's thing has data input and an fpga, that's a new view on the topic</comment></comment></comment>


Melbourne Remote Control Tourist - <AUTHOR> http://remotecontroltourist.com

<comment><USER2> pretty cool. nice idea and the interface they've built is really well done.</comment>