The State of Go - <AUTHOR> https://talks.golang.org/2015/state-of-go.slide#1 <comment><USER2> Edit: This commit was written to the original submission: [https://talks.golang.org/2015/state-of- go.slide#7](https://talks.golang.org/2015/state-of-go.slide#7)

\</comment><comment></comment><comment>--

It seems like these people simply don't understand Github very well.

        Can only view diffs on a single page (can be very slow).
        Cannot compare differences between patch sets.
        Accepting a patch creates a "merge commit" (ugly repo history).

Don't use the merge button, just add the requester's repo as a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR.

        Comments are sent as they are written; you cannot "draft" comments.

How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.)

        To create a patch one must fork the repository publicly
        (weird and unnecessary).

What exactly is weird about that? It makes it possible for the requestor to craft their changes with full control, without requiring upstream to give them write access. This point is just entirely nonsensical.

        In general, pull request culture is not about code review.

A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible.

Edit:

In light of their complaints about the need to fork, i have to say that their current contribution process can in its entirety be described as weird, unnecessary _and_ baroque:

[https://golang.org/doc/contribute.html](https://golang.org/doc/contribute.html)

<comment><USER3> > Don't use the merge button, just add the requester's repo as a remote to > yours

Actually, you don't need to do that. GitHub provides a special _pulls_ remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so:

        [remote "upstream"]
          url = https://github.com/neovim/neovim.git
          fetch = +refs/heads/*:refs/remotes/upstream/*
          fetch = +refs/pull/*/head:refs/pull/upstream/*

Then when you `git fetch --all`, you will have ALL pull requests available in your local repo in the local pull/ namespace. To check out PR #42:

        git checkout -b foo refs/pull/upstream/42

<comment><USER4> is this documented somewhere on github?

<comment><USER5> Yeah, I have to google the precise path every time I need it: [https://help.github.com/articles/checking-out-pull- requests-...](https://help.github.com/articles/checking-out-pull-requests- locally/)

</comment></comment></comment></comment><comment><USER6> The comments here represent one of the best examples of bikeshedding I've ever seen. The deep details of go are too complex for some people to really have an opinion on but god damn does everyone want to get their voices heard about github!

<comment><USER7> Agreed. However, the original submission called attention to that slide specifically, not the whole State of Go presentation. So people kept on topic :)

</comment></comment><comment><USER8> Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository.

Drafting comments... if you want to draft comments, can't you do that in a separate editor? Better than relying on the browser as an editor.

I agree, though, the public repository requirement for making a PR is a bit awkward.

<comment><USER9> > which to my eyes is more useful than a "pretty" repository.

A pretty history is extremely important when you need to attract new contributors to your repository. I've maintained extremely clean git logs and extremely nasty ones too. New contributors are immediately turned off in the latter case, because a good developer will generally git log extremely early when discovering a new project.

<comment><USER10> It is a false dichotomy. You can have a dirty repository history with fast forward merges as well. And you can have a clean repository history with explicit merges. As I wrote in a sibling comment, feature branch commits should be rebased to looks clean and meaningful (squashed in some cases if needed) but then merged into main/master branch using --no-ff flag in order to generate a merge commit.

<comment><USER2> Here's my specific issue with that: Even in such a merge it would be possible for someone to hide a change in the merge commit, and due to the nature of git it is quite difficult to figure out with confidence whether a merge commit contains additional changes or not. I much prefer the rebase/merge no ff approach over the common "just merge whatever the fuck whenever", but due to the possibility of hidden details in merge commits, i prefer a linear history.

<comment><USER11> Who is doing the merge commit? In every project I've contributed to, that's the automatic part by the code review system. If you can't trust that, then you are screwed in any workflow.

If you're talking about merges into an outstanding pull request, then that's a non-issue because any changes will still show up in the diff against the target branch/repo.

</comment></comment></comment></comment></comment><comment><USER12> What is the better alternative Go is using?

"Can only view diffs on a single page"

You don't need to use GitHub to view diffs.

"To create a patch one must fork the repository publicly (weird and unnecessary)."

I don't think it's weird.

"Accepting a patch creates a "merge commit" (ugly repo history)."

You don't need to have a merge commit, although I don't think that creates an ugly repo history.

"In general, pull request culture is not about code review."

I have no idea what this means.

<comment><USER13> They're probably using Gerrit.

Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way.

In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.

<comment><USER2> > I think people coming from SVN/CVS where history is strictly linear have > this obsession with keeping it that way.

This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master:

It makes debugging very easy.

With branch merges, especially when the branch lines cross, or the merge is an octopus merge, the complexity of the code necessitating inspection to find the root cause of a bug straight-up explodes. Meanwhile with a linear history it's not only easy, but automatable to find a commit that breaks a thing.

I do realize that you may not have had the displeasure yet to be in the situation to learn these things. Please feel free to consider yourself fortunate, but please also do try to understand that the things i just wrote are in fact simple observation of realities.

<comment><USER14> Linearized histories are much harder to find bugs in. You end up looking through revisions that never existed; in SVN you merge the remote history into your local history without it ever showing up as a merge. The explicit git approach tells you something much closer to the truth.

Your condescension is only hurting yourself.

<comment><USER2> Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you put a rebase of a branch on master without verifying the rebase, then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason.

Frankly, i find your style of argument through implication, and through trying to disregard something because it doesn't fit your definition of truth to be much more condescending than anything i wrote before.

<comment><USER15> > "Revisions that never existed" do exist

"Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably.

> then you may end up in a mess, but it's your fault. Code review is a thing > that is done for a reason.

Sure. But I've missed so many things in code reviews, had so many things in my own code missed in code reviews, and generally make mistakes and messes.

I do agree that simpler branch topology tend to be easier to reason about. But branches do have their advantages... and I've also found that preserving the original branch topology has helped me untangle merge mistakes that were missed, committed, and then only discovered a year or more later.

<comment><USER2> > Do you rewind through all your history and rebuild and retest every commit > in a branch every time you rebase?

Yes.

<comment><USER15> I hope that's all automated with short build+test iteration times! That'd easily eat a day for minor feature branches for me - I can't afford that kind of turnaround time.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> _Can only view diffs on a single page (can be very slow)._

I've seen GitHub take five seconds to render a 100K line diff. In my experience all of the other tools I've used, including some of the ones listed, can take longer to render individual file sections of such a diff. It's fast enough.

 _Comments are sent as they are written; you cannot "draft" comments._

I'm a bit puzzled as to why you would need to draft comments inside the PR interface, especially in light of the fact that they can be edited.

 _Cannot compare differences between patch sets._

You most certainly can. Just use branch/revision compare.

 _To create a patch one must fork the repository publicly (weird and unnecessary)._

Also immaterial.

 _Accepting a patch creates a "merge commit" (ugly repo history)._

This comes closest to being a legitimate complaint. Because GitHub emphasizes recognition of contributors, it doesn't let you rewrite the commits in the PR as you merge them with the merge button, but there are multiple ways to merge on the command line that avoid the merge commit and play nice with the PR.

 _In general, pull request culture is not about code review._

WTF?

Sounds like a strong case of NIH.

<comment><USER17> > _I 'm a bit puzzled as to why you would need to draft comments inside the PR > interface, especially in light of the fact that they can be edited._

This scenario happens often: I read through a change, making comments as I go. Then I reach some part of the change and realise "Oh, that explains why they did that in that other file!" So I go back and delete or alter my comments.

In Gerrit or Rietveld, the reviewee never sees those earlier comments.

On GitHub, the reviewee has already received the comment notifications and started responding before I have a chance to make the changes. The reviewee wastes time responding to questions to which I already know the answer. It's clunky, inefficient, and unnecessary.

It seems like you haven't used a tool like Gerrit or Rietveld. You should check them out.

<comment><USER18> A lot of people commenting here probably haven't had the experience of working with mature pre-submit code review tools. It's funny how much of an opinion people seem to have about things they don't know about.

I'm shocked at how bad Githubs PR review UI is given how much funding they have had for so many years. Even abandoned side projects like Rietveld have vastly better review UIs and workflows for larger patch sets.

<comment><USER19> I don't see a problem. Google people use what their NIH-filter-bubble tells them and the rest of the world uses Git(Hub).

Everyone is happy.

<comment><USER18> I probably sounded overly dismissive of github. Which probably isn't fair. But I'll leave my post un-edited for posterity.

I use github every day for work. There are lots of things it gets right. But if you want to work on a project where you more or less have a central repository, take contributions from external and internal contributors, and have a strict policy of pre-submit reviews for individual commits to master that vary in size and complexity, then you want a tool that is 'code review centric'. That is, something that supports comment drafts, back and forth exchanges across many files, and notions of iterations as the reviewee responds to feedback. Github is lacking in this regard, for all the reasons the Go team pointed out. I mean... they just recently shipped side by side diffs!

The main thrust of my comment was to point out that lots of people in this thread are criticizing the Go team's choice to use Gerrit instead of Github, and the points they make seem to stem from an ignorance of both tools like Gerrit, and of workflows that work well that aren't pull requests. It's a bit of "what you see is all there is" where all they've seen is Github. And statements like "github is good enough" seem overly dismissive of the decisions of a lot of very smart people on the Go team.

For folks that are familiar with Gerrit and still poopoo their decision to use it. Well... we can agree to disagree :).

I'm rooting for Github. I want to see it get better so I can stop running a separate code review tool for my own projects! But it's got a ways to go still.

<comment><USER18> @piotrkaminski Comment nesting seemed to run out. So replying to myself.

Our team is currently using Rietveld. But I've used Gerrit in the past, as well as internal tools of the same flavor back when I was at Google.

I don't particularly love Rietveld. But it's simple to maintain and does the job. That being said, I'm genuinely looking forward to one day being able to just use Github for this.

<comment><USER20> Heh, that's almost exactly like me: used internal tools at Google, brought up a Rietveld instance after I left. Except that I got frustrated with Rietveld and built [https://reviewable.io](https://reviewable.io) \-- you might want to check it out. :)

FullStory looks awesome, BTW, I just wish I could afford it.

<comment><USER18> Shoot me an email and let's see what we can do.

Also, I'll definitely have to check out Reviewable!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> > Better bindings for calling Go from Java.

If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low- level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.

<comment><USER22> You jest?

Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.

<comment><USER23> Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?

<comment><USER24> JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute.

Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same applies to more complicated type of software. Some configuration and invocation parameters tend to be effectively static during that particular invocation. JITs can capitalize on this fact.

JITs have also better chance to adapt to exact hardware it's running on. Compiled code is forced to make one or a limited number of assumptions of available CPU hardware configuration.

In the end, both options are running compiled native code. JIT just does it a bit before running.

Of course current reality is the opposite, but the key word here is _potential_.

<comment><USER25> I'm glad you emphasized _potential_ and mentioned reality.

One other aspect that has become increasingly important is power consumption and heat. Huge data centers now have to worry about enormous electricity consumption and keeping all the equipment cool. JIT code must do more work to compile (and recompile to optimize) on the fly which means more power and more heat.

On the consumer end, Android just switched to Ahead of Time compilation instead of JIT because its JIT performance wasn't that good and it required more power thus sucking battery life.

<comment><USER26> Same on Windows Phone. .NET is also compiled to native code ahead of time.

</comment></comment></comment></comment></comment></comment><comment><USER27> Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are written; you cannot "draft" comment'

But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.

I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.

<comment><USER28> They use Gerrit: [https://code.google.com/p/gerrit/](https://code.google.com/p/gerrit/)

</comment></comment><comment><USER29> > In general, pull request culture is not about code review.

This is not true. There are many projects on GitHub which do extensive code reviews on pull requests. It may not be as nice as Gerrit for the type of project like Go (where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient (and arguably more efficient than Gerrit).

<comment><USER3> > where you often have many iterations or the diffs are large). But for many > other projects the UI that GitHub provides is sufficient

GitHub is painful for non-trivial reviews. Biggest WTFs:

\- No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments.

\- Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests)

Yes, we try to keep PRs small. But they also need to be meaningful, and sometimes they require (many) more reworks than expected.

[1] [https://github.com/neovim/neovim/pull/1820](https://github.com/neovim/neovim/pull/1820)

<comment><USER8> Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository.

[https://news.ycombinator.com/item?id=6713742](https://news.ycombinator.com/item?id=6713742)

<comment><USER30> What? Pull requests should be on their own branches, if you want to keep one commit per PR but need to edit it you _must_ rebase it and thus force push. It's a terrible habit if you're sharing your branch with others, it's completely normal if not.

</comment></comment></comment></comment><comment><USER31> I'm late to the hate-parade but I did want to chime in to say how much I appreciate all the work the go team has put into the language, and tools. Go is a wonderful tool to get things done with. I recently rewrote a cross platform `enterprise` app from java (25k LOC) to go (8k LOC) and saw improvements in readability, memory footprint, and overall quality. Some notes on my experiences so far:

Go binary size is a non-issue for most software. The java-rewrite I mentioned above went from a 80MB or so binary, to a 8MB executable. That said, there's been a few occasions when I've really wanted to use go for an embedded project, but couldn't due to it's size.

I read somewhere, someone said of go, "you'll come for the concurrency, but you'll stay for the interfaces. This is very true for me.

Generics. Go's red herring. Sure, there's been a handful of occasions where generics would have saved me some boiler-plate, but it's not been a pain point for me.

Tooling, from fmt, vet, to unit testing are all first rate. However, I wish there was a better debugger option for go. I know that gdb works with go (and with a great deal of difficulty if you develop with OSX) but I'm probably not alone when I say I really dislike GDB.

Overall, I've found the community to be friendly both online and in person.

As an aside, I've noticed much of the recent vitriol towards Go seems to come from the Rust crowd which I think is too bad. I enjoy both. Languages are not a zero-sum game. Who knows, the hate means Go has finally arrived.

</comment><comment><USER32> There were some great new tools mentioned on there - like "callgraph" for plotting the callgraph.

I can't however find any instructions how to download and install them. Anyone able to help me?

<comment><USER17>
        go get golang.org/x/tools/cmd/callgraph

Or similar for any of these commands: [http://godoc.org/golang.org/x/tools/cmd](http://godoc.org/golang.org/x/tools/cmd)

</comment></comment><comment><USER33> This presentation looks horrible on the iPhone screen. I wonder if they couldn't spend a few minutes to point phone users to a working version or at least not lock the viewport size so mobile users could pinch-zoom out.

<comment><USER34> Each slide was okay when viewed horizontally, but then advancing then shows the damn address bar. I had to annoyingly advance, rotate, rotate back, and then read. After a while I just gave up on the titles...

</comment></comment><comment><USER35> I tried to mitigate some of the pains with GitHub code review UI by writing a helper userscript to track the progress of big code reviews. Some of the items listed in the link can be fixed in this way.

The idea is to expand/collapse files, store progress of the review and collapse status of the files in local storage of the browser, so you can stop and resume at any time (I also have in mind serializing this stuff into a hash in the URL so you can forward it to the other machine for instance, and recreate the progress there).

I work on it every now and then and have a number of items in the backlog. If someone is interested to contribute I'll be happy to accept pull requests (sic!) :)

[https://github.com/jakub-g/gh-code-review- assistant](https://github.com/jakub-g/gh-code-review-assistant)

</comment><comment><USER36> > In general, pull request culture is not about code review.

A lot of people seem to here insist that this is somewhat even remotely true. This is not. Look through Docker's pull requests on Github, look at their CI hooks.

</comment><comment><USER11> Gerrit still produces merge commits unless they have it configured to cherry- pick onto master, which is insane because you are changing the commit sha at that point.

<comment><USER17> That's exactly what we do, and we need to change the commit hash because we want to include the review information in the commit message.

Not sure why this is "insane."

<comment><USER11> It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes.

Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point?

Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say patch c depends on b, which depends on a. Now say that patch c requires a change that merged into master. Because you can't merge into your development branch, you have to rebase c AND b AND a. This really pissed of the owners of b and a because it shows up as a new changset and wipes out votes. God forbid you depend on two different patches that each have separate dependencies.

You can use the merge commit to add the review information if you want. Then you don't have to molest the code change commit.

<comment><USER17> One nice thing about Git is it lets you choose your workflow.

Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit.

We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.

<comment><USER11> It's not complicated at all if you use merge commits. That's exactly what you are doing with a feature branch. Failing to realize merge commits are useful is what makes them complicated.

<comment><USER17> It doesn't matter what the mechanism is; writing code that depends on code that changes is more complex than simply not doing that.

<comment><USER11> You can't "simply not do that" if you're project is fast moving. That's essentially the "you're holding it wrong" defense for a terrible design flaw.

Imagine you are developing a plugin framework for something and would like to develop a reference plugin at the same time to flesh out the API. Neither belongs as part of the same change but the plugin certainly depends on the framework. This is basically impossible in Gerrit because of the awful way dependencies work. The only way it can work is with a feature branch, which is basically giving up on Gerrit anyway and using git in the way it was intended.

Gerrit ultimately becomes a choke point on the throughout a given project can have unless you have an extremely small set of contributors that can coordinate well (i.e. Not a large open source project). Maybe this isn't a problem for Go since there is a high barrier to entry for contributors, but it's something to keep in mind.

<comment><USER17> The Go project is sufficiently modular that this isn't an issue for us.

<comment><USER11> Didn't you say that you used feature branches? If so, that was a case where Gerrit failed and you had to use git in an almost normal way.

<comment><USER17> How is that Gerrit failing? Gerrit is designed to support all kinds of workflows, just like Git. As far as I can tell, we're using our various tools the way they were intended. Just because it doesn't line up with your exact view on how Git should be used, doesn't mean we're doing something wrong (or "insane").

This is a boring conversation.

<comment><USER11> If it's boring, why were you trying to defend such a suboptimal use of git?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> Does GitHub still not support "fast-forward only" commits? The "ugly merge" thing is easily avoided with a rebase before committing.

<comment><USER37> GitLab CEO here. Both GitHub and GitLab normally always create a merge commit when accepting a merge request in the web UI. GitLab EE has a rebase feature where you can accept merge requests by automatically rebasing them just before merging, for more information see [https://about.gitlab.com/2014/12/22/gitlab-7-6-and- ci-5-3-re...](https://about.gitlab.com/2014/12/22/gitlab-7-6-and- ci-5-3-released/)

<comment><USER37> I see this is down-voted (after being up-voted initially). I thought it was interesting that GitLab allows you to accept pull/merge requests without creating a merge commit. Should I not have included the url? Edit: Thanks for re-upvoting it

</comment></comment></comment><comment><USER38> Breaking the mouse entirely probably isn't the greatest of frontend design patterns.

<comment><USER39> Besides the arrow keys, you can move forwards or backwards by clicking on the left or right edges of a slide.

<comment><USER40> You can also click on the vertical area between slides to go forward/back.

<comment><USER41> Also known as "easter egg navigation."

<comment><USER17> It's a tool for _giving_ presentations, not necessarily for reading them.

But I've just sent a change to add some help text to these pages: [https://go- review.googlesource.com/4910](https://go-review.googlesource.com/4910)

edit: The change is now live. No more easter egg navigation. Yay!

</comment></comment></comment></comment></comment><comment><USER42> [https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEm...](https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEmhmkx_k- CqBWeA)

</comment><comment><USER43> > To create a patch one must fork the repository publicly (weird and > unnecessary).

I think it's very fair to demand from a contributor to sync and build the entire app before they're allowed to submit a patch.

Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.

<comment><USER44> We expect contributors to sync and run all the tests. The _public_ forking is the weird and unnecessary part.

Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.

<comment><USER43> What is so disturbing about the "public" part that it's worth discarding the whole approach?

<comment><USER44> No-one said "disturbing". It's weird if you've come from an environment where you do your individual work in private, and only show it to people when it's ready to be committed/merged.

No-one said that that point alone is worth discarding the whole approach. You're nitpicking a single bullet point from around a half dozen points that stacked up.

</comment></comment></comment></comment><comment><USER45> > Where we're at in February 2015

Still producing 1.3M hello world executables.

I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

<comment><USER46> Yeah, what an outrage this is.

1.3 megabytes. That's like $0.00004 USD worth of hard drive space.

Does the go team think we are all rich or something?

<comment><USER47> I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.

<comment><USER17> Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.

</comment></comment></comment></comment><comment><USER48> Most of career has been spent doing web programming, so maybe I'm ignorant, but if you have to build Go with a Go binary, instead of C, doesn't this break OSS's value proposition? (obviously I'd have to start with a C compiler, but that feels a bit purer in my mind, as I can start with a pretty bare-bones OS)

<comment><USER17> I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?)

To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.

<comment><USER49> I think bdcravens means that to install Go from source on, say, a new Linux box, we will have to download a binary version of Go first, even though we probably already have gcc.

What happens if this catches on, and PyPy replaces CPython, and other languages do the same?

Hassles for those who prefer to install from source, and potentially a lot of duplication of effort writing compiler backends in every language.

<comment><USER50> > What happens if this catches on

I don't understand your comment, because we already live in your nightmare scenario: [http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#L...](http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#List_of_languages_having_self- hosting_compilers)

In practice, it isn't a big deal. When was the last time you worried about the language your compiler was written in?

> potentially a lot of duplication of effort writing compiler backends in > every language.

That's also the state of things for every compiler that doesn't use LLVM or compiles to another language.

<comment><USER49> I agree the installation issues are fairly trivial; they were just a response to the original comment.

But the duplication of effort (which won't end when the "GoGo" compiler is ready to replace cgo), and a potential freeze in Go while "GoGo" catches up, are more serious drawbacks.

Yes, that is a trade-off other compiler teams have made, and it may be the right choice for Go as well, but it should be (and no doubt has been) considered.

</comment></comment></comment></comment></comment><comment><USER51> I think go is failed, compare to rust. 1\. not memory safe on multi-thread 2\. no generic support 3\. error handle is full of pain compare to rust's Result<T>, Option<T> and try! 4\. gc can't be disable 5\. no RAII support, defer can be forgot light-weight thread (spawn) and channel (thread safe FIFO) already exist in rust that make golang more meanless. If you think still any advantage of go please tell me.

<comment><USER52> Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1\. Rust cannot guarantee multi- threaded memory safety in all cases. Care, as in Go, must still be taken. 2\. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3\. Rust and Go's error handling is based on the same principle: force the user to deal with errors, instead of ignoring them. While Go's way of handling things can be a little more verbose, in principle I don't see the big difference. 4\. Alot of people will argue that this is a good thing. Using a GC by default makes certain things easier, like writing datastructures (especially immutable ones) without reaching for 'unsafe' code. Having a GC also means you don't have to mind memory fragmentation, as you do with a manually malloc/free based allocation. 5\. RAII is great, but loses some of it's use in GC based language. Defer is, IMHO, a much better option than the other solutions I've seen in other GC languages (Javas try-with-resources and C#s using)

Just because you can do the same thing in language X, doesn't make language Y obsolete.

Advantage of Go, for me, is less verbose code (implicit interfaces for the win) and a fantastic, stable and huge standard library. I also like the strict compiler, and that the language has a GC by default, makes certain things easier, and for most tasks I don't need the predictability that you get with manual memory management.

<comment><USER53> While I do generally agree with what you've written, I do want to take issue with point (1). Rust _is_ actually intended to guarantee multi-threaded memory safety in safe code. Period. If you can get it to behave otherwise, it's a bug in Rust.

<comment><USER52> True. What I really meant is that safe code can interact with unsafe code, and thus cannot guarantee everything working correctly. Of course, this is bug with unsafe code, my bad.</comment></comment></comment></comment>


Bitcoin mining guzzles energy – and its carbon footprint just keeps growing - <AUTHOR> https://www.wired.com/story/bitcoin-mining-guzzles-energyand-its-carbon-footprint-just-keeps-growing/ <comment><USER2> How does the carbon footprint for x amount of Bitcoin (in, say, $ terms), compare with the carbon footprint of both printing and maintaining a similar amount of traditional currency?

<comment><USER3> Only three to eight percent of fiat currency is held in cash.

<comment><USER2> True, but that's still a substantial amount of physical stuff that needs to be made and maintained...

</comment></comment></comment><comment><USER4> Meh. Use it as a preheater for your furnace. Don't mine in the summer.</comment>


Compiler Construction: The Art of Niklaus Wirth (2000) [pdf] - <AUTHOR> https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762df717bd0af1324.pdf <comment><USER2> _Generate good code from the beginning; don 't generate bad code and optimize later_

Unfortunately this is something that no compiler I know of does, as evidenced by their -O0 being far worse than even what a naive Asm programmer (human) could do, and it's one of the things that irks me about compilers. Dataflow- directed, "work backwards" techniques might be the solution to this, but once again I don't know of any compilers that do it.

On the other hand, his points about using recursive-descent parsing seem to agree with the majority of widely-used compilers. However, this is factually incorrect:

 _I even think that the availability of powerful bottom-up parser generators such as Yacc are responsible for the cryptic syntax of C._

Dennis Ritchie's first C compiler used recursive descent. Yacc itself was written in C, so it could not have come before. You can see the sources yourself here: [https://news.ycombinator.com/item?id=5748672](https://news.ycombinator.com/item?id=5748672)

<comment><USER3> >> Generate good code from the beginning; don't generate bad code and optimize later

> Unfortunately this is something that no compiler I know of does,

You're probably right compared to modern compilers. What you need to compare to are the compilers of the era, which were truly abysmal.

It's not that the Wirth compilers generated fantastic code (e.g. at least one of Wirths students explored adding much more aggressive optimization to his Oberon compiler), but they generated code that was a great deal better than a lot of non-Wirth style compilers at the time.

Some compilers of the time even depended on peephole optimizer passes because the code they generated was so bad that even simple 2-3 instruction peephole passes were enough to drastically improve the code. There was little reason for this. E.g. most of the time it was a matter of as basic stuff as passing on information about the registers to use rather than the dumb/naive approach of generating everything using scratch registers that you move things to/from.

I remember back in my asm days that I once had the C source for a GUI component I wanted to use, but the code the C compiler I had available generated was so awful that in exasperation I compiled it, disassembled it, and proceeded to manually clean it up. I deleted about half the instructions of about several thousand lines of compiler output, with very minimal fixups.

<comment><USER4> Wirth's compilers generated reasonably good code: 80% of the performance of optimizing compilers with 20% of the effort.

The first Java client jit compiler, was developed by Robert Griesemer (former PhD student of Wirth). The design of the compiler is described in the paper "A compiler for the java hotspot virtual machine", published in the same book: "The School of Niklaus Wirth: The Art of Simplicity".

</comment></comment></comment><comment><USER4> I wrote a simple self-hosting compiler to showcase Niklaus Wirth's approach to writing compilers: [https://github.com/lboasso/oberonc](https://github.com/lboasso/oberonc)

Single pass compilers have their advantages.

<comment><USER5> "The School of Niklaus Wirth" [0] contains this essay and many others on how simplicity can be an essential quality of a system. I vastly under appreciated how well Wirthian languages are designed, even after toying with the excellent offshoot, Modula3 [1]. In my youth I was too concerned with raw performance and syntax. In my old age I am concerned about semantics and maintainability.

[0] [https://www.amazon.com/School-Niklaus-Wirth-Art- Simplicity/d...](https://www.amazon.com/School-Niklaus-Wirth-Art- Simplicity/dp/1558607234)

[1] [https://github.com/modula3/cm3](https://github.com/modula3/cm3)

<comment><USER4> I own a copy of "The School of Niklaus Wirth" :) I really appreciate the pragmatism of Wirth's designs and his quest for simplicity.

</comment></comment></comment><comment><USER6> > Don't let the compiler repair poor programming style ... This includes some > cases of common subexpression elimination, loop invariant code motion and > copy propagation

Unfortunately in languages like C++ these inefficiencies often originate from inline function expansion rather than the programmer and thus are absolutely necessary.

> Strive for short compilation times

I wish designers of Swift heard this... Swift's build times can be horrifically slow for no good reason, it seems. I think slow build times have become a new norm pretty much like e.g. graphics display boot up times, i.e. someone at some point convinced the users that it's the way it should be and as a new norm no vendor strives to improve it.

<comment><USER7> > someone at some point convinced the users that it's the way it should be and > as a new norm no vendor strives to improve it.

People tend to defend slow boot up times with arguments that boil down to the aphorism:

Better the code be correct than fast.

Unfortunately most modern software out there is neither, which is where the whole argument falls apart.

</comment></comment><comment><USER8> As a matter of interest do we know when this was written? The PDF has a date of 2007 but the latest reference is Wirth's book, published in 1996.

<comment><USER3> This looks to be the original publication [1]:

Hanspeter Mössenböck: Compiler Construction - The Art of Niklaus Wirth. Chapter in: Böszörmeny et al.(eds): The School of Niklaus Wirth, dpunkt.verlag 2000, pp.55-68

An extensive list of Mössenböck's publications can be found here[2]

[1] [http://ssw.jku.at/Research/Papers/Moe00b.html](http://ssw.jku.at/Research/Papers/Moe00b.html)

[2] [http://ssw.jku.at/Research/Papers/](http://ssw.jku.at/Research/Papers/) (while this from the page looks like it's for his institute, it looks like all of them have him as at least co-author, and they include papers from his past institutions including his time at ETHZ with Wirth; e.g. a favourite of mine of his earlier paper is this collaboration with Marc M. Brandis on generating SSA forms for structured languages in a single pass [3] from '94 - as a confessed Niklaus Wirth fanboy I read most of the papers that came out of his research group in the early 90's..)

[3] [http://ssw.jku.at/Research/Papers/Moe94.html](http://ssw.jku.at/Research/Papers/Moe94.html)

EDIT: I of course had to check, and Amazon (at least in the UK) has the book this is from (The School of Niklaus Wirth: The Art of Simplicity ), though it's expensive... I just had to share this hilarious find from one of the reviews:

"For me, this book is one to keep forever. I enjoyed every page (apart from the section written by Dijkstra since it was handwritten..)."

EDIT2: And having been seduced into buying this book, I can confirm Dijkstra's contribution (On the transitive closure of a well founded relation; dedicated to Niklaus Wirth) is in fact included in his handwritten form. I wish I had handwriting like that (but not enough to put in the effort).

<comment><USER9> > in: Böszörmeny et al.(eds): The School of Niklaus Wirth

I used to have that book somewhere. All of it was nicely typeset, except for Dijkstra's chapter, which was facsimile copies of (nicely) handwritten text.

<comment><USER3> His handwriting is fantastic. And it's such an obvious fun little quirk given how famous he is for his handwritten notes.</comment></comment></comment></comment>


The "rent vs. buy" dilemma (2018) - <AUTHOR> https://medium.com/fabrica/the-rent-versus-buy-dilemma-12-important-questions-5f5a7d1815f <comment><USER2> > _However, most people don't think this through, especially if they want to > buy, in which case ~10% of your home value is spent on the transaction_

This is really not true, at least not in high-demand areas. First of all the seller pays the fees typically, and they are much lower. Redfin for example costs you 1% in the Bay Area. If your agent is telling you it will be 10% then you're being taken for a ride.

<comment><AUTHOR> I've spoken with tens of real estate experts in 2017 and 2018, and everybody pretty much agreed that the transaction costs generally approach or even surpass 10%.

There's much more than just agent fees to include in these costs. Title insurance. Closing. Mortgage origination fees. Etc.

<comment><USER3> Just bought a home half a year ago, fees came out to nowhere near 10%. It was just around 2% that came from my pocket, and the seller paid the rest, but even then I doubt they paid 8% to get that 10% figure they're suggesting.

<comment><USER4> I negotiated the purchase of my condo from our landlord. The first thing we did was shave 6% off from the avg price in the area due to not using real estate agents. That fee is an indirect amount you paid through an increased price.

</comment></comment></comment></comment><comment><USER5> A big factor people miss is that many real estate markets and labor markets are heavily correlated. There's often a few major employers or a few productive sectors that write paychecks in the area, which then drives rental and housing prices in the area. So, housing is often an asset with a large positive correlation with your future wages. There's good historical examples here - Detroit around 2008 had simultaneous drops in real estate prices and automotive sector employment.</comment>


Ask HN: Refactoring tools - <AUTHOR> Hey HN,
In a large project of mine, I regularly have code wrapped across multiple lines that could be expressed more succinctly using a different series of calls.
My initial stab at how to refactor this is to create a small parser that iterates through these files and refactors as appropriate. Is this overkill? Doesn't seem quite right for sed, but awk might work. Any other tools I'm missing? <comment><USER2> Can't you use an IDE that has built in refactoring tools? What language is your project and what ide are you currently using?

</comment><comment><USER3> Some JetBrains IDEs such as PyCharm have refactoring tools built in.</comment>


Replacing $1 Bills with $1 Coins Could Save America Billions - <AUTHOR> http://www.good.is/post/report-replacing-1-bills-with-1-coins-could-save-america-billions/ <comment><USER2> And cost service workers who get dollar bills as tips. See how often people give pound coins as tips in the UK.. I'd tip a lot if we had pound notes back!

<comment><USER3> What is it about pound coins that make them less likely to be used for tips? Is it the extra bulk in your pocket?

<comment><USER2> My belief is that there's a social contract to not analyse the amount of a tip given in cash at the time it is given. You don't usually count out a tip or say how much you're giving - you're more likely to "slip" them a twenty or the like.

With coins, there's no way to maintain an ambiguity over the amount. If it's a coin, it's clearly a small amount and since coins are very easily identifiable (compared to notes), that social expectation is broken.</comment></comment></comment>


Practical Artificial Intelligence with Java (Creative Commons) - <AUTHOR> http://markwatson.com/opencontent/JavaAI3rd.pdf

<comment><USER2> Duplicate post.

<http://news.ycombinator.com/item?id=360365>

There seems to be a lot of duplicate posts lately.

Perhaps the 'submit' button should only appear starting on page 3! :-)

<comment><AUTHOR> Ah I see, it's because I linked directly to the pdf.

</comment></comment><comment><AUTHOR> Here is the author's web page:

<http://markwatson.com/opencontent/>

</comment><comment><USER3> I seem to remember the CCC on Mark Watson's page says you have to download it from him.

<comment><AUTHOR> It was scribd automatically when I posted the link. I can ask pg to take it down, if necessary, it's too late for me to delete the submission.</comment></comment>


ImagePickerController with live filters - <AUTHOR> https://github.com/gobackspaces/DLCImagePickerController#readme <comment><USER2> I was trying to build my own for an app I'm building and all I can say is it's pretty hard. Thanks for this!

<comment><USER3> thanks for this

</comment></comment><comment><USER4> Seems to be crashing when clicking 'show picker' on my iPhone 4... does it work on 4S only?

<comment><USER5> GPUImage can't work with full resolution images on an iPhone 4, only iPhone 4s, iPad Retina.

Texture size limitation.

* One possible explanation.

<comment><USER6> Nah it works, his issue was because I used xibs. To be fair, the front camera is buggy because of this sometimes though.

</comment></comment></comment><comment><USER7> This looks great. Thanks for sharing! Backspaces is a cool concept as well.

<comment><USER8> I'd be interested to learn more about Backspaces, but didn't get much from its website.

<comment><USER9> hey there, co-founder at backspac.es here. happy to answer any questions you have!

<comment><USER10> can you load images in as well, or does it always have to be from taking a pic from the camera?

<comment><USER9> woops, didn't see the reply button for some reason, but yes you can, see this screencast: [http://www.youtube.com/watch?v=mYWTMEbrqWk&feature=plcp](http://www.youtube.com/watch?v=mYWTMEbrqWk&feature=plcp)</comment></comment></comment></comment></comment>


Hackers Hijack entire operation of Brazilian bank - <AUTHOR> https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation <comment><USER2> crime pays really well. nobody likes to admit it. most of the rich powerful people dont think twice about it. it seems like to get ahead in this capitalist world, crime is a growth hack strategy. even at the white collar level, crimes are less punishing and more forgiving than violent crimes when the economic aftermath of Enron, Theranos, Madoff is far far detrimental.</comment>


'A Smoking Gun': Infectious Coronavirus Retrieved from Hospital Air - <AUTHOR> https://www.nytimes.com/2020/08/11/health/coronavirus-aerosols-indoors.html <comment><USER2> >Viable SARS-CoV-2 in the air of a hospital room with COVID-19 patients

[https://www.medrxiv.org/content/10.1101/2020.08.03.20167395v...](https://www.medrxiv.org/content/10.1101/2020.08.03.20167395v1)</comment>


Ask HN: Is there any semantic search developed on top of Algolia? - <AUTHOR> Is there any project that uses BERT to improve the search relevance of the Algolia search engine? <comment><USER2> (I'm on the team at Algolia that works on NLU and semantic search.)

I don't know of any community projects using BERT atop Algolia for semantic search, but we have been experimenting with it internally. Earlier in 2020 we ran some tests that first performed a search on Algolia, before using BERT for the "semantic" side of it. We stopped those experiments for three reasons:

1\. The results weren't high-quality enough 2\. The predictions took too long 3\. We found other approaches that performed better

We could have probably improved the quality of the predictions, and there were strategies we considered to avoid the issues around prediction time. But since we had better approaches at the ready, we put further experimentation on hold. (Apologies for being coy about the other approaches, but we are still working on those and aren't sure if they will end up in production or not.)

I'm happy to answer more questions, or if you have something you're working on that you'd like to discuss you can reach out as well. (Email is dustin@)

<comment><AUTHOR> Hi Dustin, thank you for your answer. Is there any experiment using the current search relevance evaluation dataset (bing queries for example) that compared Algolia's search relevance to other alternatives? For example, in this project [https://github.com/koursaros- ai/nboost](https://github.com/koursaros-ai/nboost) they said the model can boost the search relevance.</comment></comment>


[Google App Engine] Another Official Update of New Pricing FAQ - <AUTHOR> http://code.google.com/appengine/forum/?place=msg%2Fgoogle-appengine%2FHluog1_a3n4%2FuFMhaBWhVi8J

<comment><USER2> I think that I am in a minority opinion here: I think that the new pricing structure makes sense, given Google's statement that they want AppEngine to be a long term sustainable business.

I like the discussion of what things are expensive to support, and it makes sense to charge expenses plus some profit margin. Call me old fashion but I believe that every business interaction should be win-win.

I have used AppEngine for several years to host one of my ancient domains that is a Java web app. The price has always been free but I plan on upgrading to always keep one instance running.

Virtually all of my customers deploy to AWS but I (also) like AppEngine for my own projects.

</comment><comment><USER3> I am just as confused as before.</comment>


Opas: AI-powered automated root cause analysis - <AUTHOR> https://opas.ai/ <comment><USER2> White text on white background -- unreadable on mobile.

</comment><comment><USER3> Nice</comment>


Ask HN: Help with Choosing a Doctor? - <AUTHOR> I am co-founder at a health care startup and and we are interested in building a service to help people find doctors. In talking to folks, we have found people value opinions of their friends and family in choosing a doctor over review websites like Yelp or HealthGrade. However, we have found some people hesitant to reach out to friends/family as it can understandably be a sensitive issue. We are trying to make this process a little easier.
1. Poll Your Friends/Family - This would be an easy way to send a request out to friends (whether from FB, Gmail, etc.) asking them for help in choosing a doc in an anonymous way. For example, someone may be looking for a good psychiatrist but this can be a hard to share unless done in an anonymous way. We would have pre-loaded data on several physicians making it easier for all involved to browse through options.
2. Free Personal Health Advisor - This would be a real person helping you choose a doctor. There are my nuances to choosing a doctor that many might not be aware of like choosing one in the same health care system.
Thanks! Would love to hear thoughts. <comment><USER2> I recently moved to another state and decided I need to find a doc. I've had the hardest time trying to find a doc, but at the same time I don't have a large social network local to the area to draw upon.

My concerns in order of importance:

* Does a doc take my insurance

* Are they with in a 20min driving radius

* Are they taking new patients

* Are they not terrible at their job

* Are they remotely personable

* Differentiating between different GP specialties was a bit confusing (internal medicine, family practice, etc)

With 20-30 or so docs in the area to choose from, I'm just going to have to roll the dice and see if things work out. Anything to help make this choice easier would be awesome.

<comment><AUTHOR> Before seeing a doc, how do you figure out "Are they not terrible at their job" and "Are they remotely personable"?

<comment><USER2> Other than the existing review sites, I really don't have any way to know. The only way for me to find out is to set an appointment, hence why I would love a better way.

<comment><AUTHOR> Got it. Friends/family would be a great source.

</comment></comment></comment></comment><comment><USER3> How about being able to assign a value to certain attributes, and then recommend the highest "scoring" doctors?

For instance, accepting my insurance is incredibly important (100 points), being the same gender as me is a somewhat important (25 points), having a doctor under 45 is important to me (35 points), speaking a language other than English isn't important at all (0 points), etc, etc.

I am effectively applying this sort of algorithm now when choosing a doctor, but it would be nice to have it explicit and faster than looking up all the information on each doctors page.

<comment><AUTHOR> That sounds interesting. Out of curiosity, what sites do you use to gather info on docs?

</comment></comment><comment><USER4> I'm curious, have you explored how ZocDoc works? It's what I used when I was clueless about finding a doctor.

</comment><comment><USER5> Make it easy to browse the data and see how they choose.

<comment><AUTHOR> Betterdoctor.com does this to a certain extent but does not have all of the nuances mentioned above.</comment></comment>


Implementing Human-Like Intuition Mechanism in Artificial Intelligence - <AUTHOR> http://arxiv.org/abs/1106.5917 <comment><USER2> There was an article a year ago or so about a theory around giving AI emotional responses, which was a separate process than that running the neural network. I can't remember what it was called.

I wish my phone had more empathy for me.</comment>


If Earth Had a Ring Like Saturn - <AUTHOR> http://io9.com/if-earth-had-a-ring-like-saturn-508750253

<comment><USER2> Also, the article implicitly assumes that the ring is in the equatorial plane. Looking around, I found this for justification: "Ring particle orbits must lie precisely in the equatorial plane of the planet. Inclined orbits precess, or change their orientation. Very quickly, an inclined ring will soon degenerate into swarms of particles with different orbital planes." from [http://www.uwgb.edu/dutchs/planets/resonanc.htm](http://www.uwgb.edu/dutchs/planets/resonanc.htm)

This destroys my alternate world fantasies of an Earth with a ring going perpendicular to the equator and providing easy longitudinal information for early seafarers, thereby speeding up the rate of exploration and mapping.</comment>


Choosing The Best CSS Framework: A Complete Guide  - <AUTHOR> http://devsnippets.com/article/complete-guide-to-css-frameworks.html <comment><USER2> Another survey article, with no conclusions or recommendations... No pros/cons covered, somebody have a good _review_ rather than a survey?

<comment><USER3> Just go with Compass and be done with ;-) It admittedly makes deploys a little more annoying though (particularly if you aren't already using Ruby).

<comment><USER4> I just use Compass with a sample index.html to get the styles right, then punt the generated CSS sideways into whatever project I'm working on. Makes things nice and simple.

If I find a weird corner case where the style breaks, I add that to the index.html as a test case and repeat.

</comment></comment></comment><comment><USER5> > But it can also be a steep learning curve to figure out which framework you > should use (or if you should use one at all) and then how to use it.

I was really looking forward to hear someone talk about this.

I'd like to know more about whether or not I should be using one at all. I've found CSS frameworks useful for mockups or prototyping, but I'm concerned that they're too heavy and general-purpose to use in production.

<comment><USER6> That's what I've found too. The value of a css framework comes from showing you a structured way to achieve certain things, eg grid based design, font scaling. Once you know how to do that, you don't need the framework and it's probably just as easy to write the css directly.

I've found the best way to use them is a starting point. By the time your site goes live you've stripped out the rules you don't need and customised the names of the classes etc so you can't see much of the original framework.

</comment></comment><comment><USER7> Choosing seems even harder nowadays, what with SASS, LessCSS, CleverCSS, etc.

I've been using Compass, a set of SASS libraries that (among other things) re- implements Blueprint. I love Compass; I like SASS a bit less (especially where syntax is concerned.)

<http://wiki.github.com/chriseppstein/compass/>

<comment><USER8> Luckily for you, Sass 3 will have a new CSS-like syntax. You can even use it right now if you want: <http://github.com/nex3/haml/commits/scss>. I believe it works great with the Compass 0.10 prerelease.

</comment></comment><comment><USER9> I've been using YUI Grids for a couple of years and it simplified my CSS. I use it to "reset" all the default rules for the browsers so that things like font sizes and spacing appears uniform between the browsers. Then I use it to set up an initial grid layout for the base columns and rows of the site.

I moved from YUI to jQuery because I wanted to use a lighter framework, but I've continued to use YUI CSS because it's still pretty tight.

However, I hope that YUI does look into add compatibility for HTML5 tags because that is something that is lacking.

</comment><comment><USER10> If I'm doing a simple, non-CMS site I'll use custom Blueprint CSS generated by Boks: <http://toki-woki.net/p/Boks/>.

<comment><USER11> I like blueprint, but I always feel like I am getting into nested div hell as you can't add padding to its grid. Either that or I am doing something wrong.

<comment><USER12> Pull or push don't do what you want?

</comment></comment></comment><comment><USER13> Help a noob - Are these helpful at all for building CMS based sites - like on wordpress or shopify? Or are they mostly just for making standalone sites?

<comment><USER14> I've used YUI Grids to build both Drupal and WordPress sites. It's pretty straight forward and definitely easier than trying to customize an existing CMS template/theme.

</comment></comment><comment><USER15> Everything on Grid Based Designs and the appropriate tools can be found here: <http://www.fuelyourcreativity.com/grid-based-design-toolbox/>

</comment><comment><USER16> Any recommendations to use with a GWT application?

<comment><USER17> I think the answer would depend more on the nature of your particular application than whether or not you're using GWT. Was there anything about GWT that leads you to suspect otherwise?

<comment><USER16> I cannot pin point what is different with GWT. May be I just need to try one the css frameworks to see if I get a better insight.</comment></comment></comment>


Seeking Testers For A Bookmarking Site - <AUTHOR> http://idlewords.com/2009/06/seeking_testers_for_a_bookmarking_site.htm

<comment><USER2> This "social bookmarking" thing is never going to take off.</comment>


Show HN: microvm – a minimalist machine type for QEMU inspired by Firecracker - <AUTHOR> https://github.com/qemu/qemu/blob/master/docs/microvm.rst <comment> yjftsjthsd-h Oh, nice: props for including precise, fully worked example commands to actually use this. This is so helpful in terms of onboarding and being able to actually get people to use a project:)

<comment><USER2> If I was an eccentric billionaire, I'd reward good documentation with an open source doc prize.

It's so difficult to impress upon some people just important documentation is. And when they do it, they half-ass it by copying stuff from source code and not adding any context.

<comment><USER3> +100 to this. I've become a cheerleader for some projects just because the documentation was so good that it was easy to get started. It's how I became a ZFS zealot among other things.

<comment><USER4> OT: where do you find the good ZFS documentation? Googling always seems to turn up Oracle's documentation, which may not match what's in FreeBSD or ZFS- on-Linux

<comment><USER5> The zfs man pages (at least on FreeBSD) are actually pretty decent for finding command usage. The FreeBSD handbook[1] covers some typical usages.

[1]: [https://www.freebsd.org/doc/handbook/zfs.html](https://www.freebsd.org/doc/handbook/zfs.html)

</comment></comment></comment></comment></comment><comment><USER6> Firecracker requires KVM, but QEMU can be used with instruction emulation, correct? Does that make this potentially a little easier to develop with in certain environments?

<comment><AUTHOR> That's correct. The initial versions of the microvm patch series did require KVM, but the one that got upstreamed does work with TCG [1], thanks to the QEMU's maintainers feedback.

That said, I'm not sure for which kind of use cases it would be useful to run it this way, as the performance won't be amazing. I find TCG acceleration mainly useful for debugging and foreign systems emulation.

[1] [https://wiki.qemu.org/Documentation/TCG](https://wiki.qemu.org/Documentation/TCG)

</comment></comment><comment><USER7> What are the differences compare to Firecracker?

<comment><AUTHOR> From the guest perspective, the differences are minimal. Even boot time of the guest (thinking about a custom-built minimalist Linux kernel here) is roughly the same.

On the host side, things are more interesting. Firecraker has a smaller TCB (Trusted Computing Base), is written in Rust, and is statically linked. On the other hand, QEMU provides more features (especially in the block layer, with more formats, network-based block devices, asynchronous I/O...), can be configured at build time to adapt it to a particular use case, and has a pretty good security record.

In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins.

<comment><USER8> > QEMU... has a pretty good security record

That's an interesting and I would argue, contrarian take?

[https://www.theregister.co.uk/2017/01/30/google_cloud_kicked...](https://www.theregister.co.uk/2017/01/30/google_cloud_kicked_qemu_to_the_kerb_to_harden_kvm/)

"QEMU has a long track record of security bugs, such as VENOM, and it's unclear what vulnerabilities may still be lurking in the code."

<comment><AUTHOR> I think the slide 14 from the talk "Reports of my Bloat Have Been Greatly Exaggerated" [1] presented by Paolo Bonzini at KVM Forum 2019 gives some good perspective about QEMU's security track:

"Of the top 100 vulnerabilities reported for QEMU:

\- 65 were not guest exploitable

\- 3 were not in QEMU :)

\- 5 did not affect x86 KVM guests

\- 3 were not related to the C language

\- Only 6 affected devices normally used for IaaS

The most recent of these 6 was reported in 2016"

The rest of this talk was also very interesting. I encourage everyone with 10 minutes to spare and an interest in VMMs to take a look at the slides.

[1] [https://static.sched.com/hosted_files/kvmforum2019/c6/kvmfor...](https://static.sched.com/hosted_files/kvmforum2019/c6/kvmforum19-bloat.pdf)

<comment><USER9> > "Of the top 100 vulnerabilities reported for QEMU:

> \- 65 were not guest exploitable

> [...]

Which leaves about 30 that presumably were guest exploitable.

Don't get me wrong -- QEMU is _useful_. As a "kitchen sink" solution that runs anything, anywhere, with any useful combination of emulated {devices,processors,systems}.

However, this is also its biggest weakness. Which is why Google and Amazon all run their own custom VMMs for their IaaS services.

The microvm machine type as described here is a great step to improve this situation. The next step in my book would be to reconfigure QEMU's build system to allow building a binary that _only_ supports the devices provided by microvm, and nothing else.

</comment></comment></comment></comment></comment><comment><USER10> What kind of workloads make sense for this runtime? DIYFaaS? Or small, isolated long-running processes?

<comment><USER11> Function as a service is certainly one place. Others include secure container runtimes (eg. Kata-containers), sandboxing applications in general, and libguestfs.</comment></comment>


Ask HN: Evaluate my startup - <AUTHOR>

Hey Guys- I had just started my startup and need your feedback on it. http://www.akhadaonline.com/ <comment><USER2> Not clear what your site does for a new visitor. After a while, I figured out there were "stars" and "fights". But no sense of why I would want to use it.

<comment><AUTHOR> Its a online debate site.

</comment></comment><comment><AUTHOR> Its an online debate site.

</comment><comment><USER3> question: Why does google show your site existed 10 years ago?

<comment><AUTHOR> I don`t know much about that.</comment></comment>


Stanford engineers team up with U.S. Army to set computational record - <AUTHOR> http://aa.stanford.edu/news-events/news/stanford-engineers-team-us-army-set-computational-record <comment><USER2> This is complete fluff without quantifying the properties of the algebraic system. 1D PDEs with billions of variables can easily be solved in seconds on a laptop. Fully 3D highly indefinite equations are another story. The university press should be ashamed.

<comment><AUTHOR> I almost didn't submit it because there were no details on what "mathematical equations" were used.

I think the emphasis was (or should have been) on the algorithms developed to work with multiple processors, but there wasn't much info on that either.

        "When you connect 100 computers and tell them to solve a system of
        equations, I need to break it into 100 pieces and ship each piece to a
        computer, and then they need to talk to each other," Farhat said.
        "They cannot do this independently."

        To confront this well-known problem, Farhat and his team – led by Jari
        Toivanen, Radek Tezaur and Philip Avery – collaborated with the ARL
        DSRC to craft algorithms to divide these calculations among thousands
        of computers.

        The team members worked around the clock for three weeks to prepare
        their software for the test on Excalibur. When the day came last
        month, they had access to a significant chunk of the facility's
        101,184 processors to divide slices of their equations, share
        information and solve the problem. A mere three minutes later, those
        thousands of processors had solved over 10 billion calculations
        accurately.

It's also troubling when the link to "Army High Performance Computing Research Center (AHPCRC)" gives a Drupal error.

<comment><USER2> If you're interested, Prof. Farhat is very well known for the FETI method [1], which is likely what is being alluded to by the article. But the article as written is devoid of any description of what was interesting about the calculation.

[1] [https://en.wikipedia.org/wiki/FETI](https://en.wikipedia.org/wiki/FETI)

<comment><AUTHOR>
        Prof. Farhat is very well known for the FETI method

And he's flown with the Blue Angels (I would give anything to do that).

[https://www.flickr.com/photos/stanfordeng/sets/7215764813436...](https://www.flickr.com/photos/stanfordeng/sets/72157648134366930/)

</comment></comment></comment></comment><comment><USER3> What exactly did they solve on those machines?

</comment><comment><USER4> This is old school monolithic system HPC trying to survive in a world of distributed HPC and GPUs.

<comment><USER5> Distributed hpc? GPUs? Wake me when distributed HPC or a GPU machine wins gordon bell.</comment></comment>


Petition: Apple recall and replace defective Macbook Pro keyboard design - <AUTHOR> https://www.change.org/p/apple-apple-recall-macbook-pro-w-defective-keyboard-replace-with-different-working-keyboard <comment><USER2> My 2017 Macbook Pro is five months old and the A, D, R, and T keys will lift right off with my fingers as I type.

I looked at them with a magnifying glass. The C-clamps that hold them in aren't broken. They just are stretched an extra micronanometer such that they don't hold the spoke anymore. It alone wastes a bunch of my time every minute as I have to fix the keys as I type a line of code, but the anger it provokes is even more distracting.

If I could go back in time five month ago, I would've simply bought a Macbook Air which still has the older keyboard. My previous computer was a 2014 Macbook Air and it's the best computer I've used. The battery lasted longer as well.

Another surprising quirk of the Macbook Pro is how hot it gets. I can't watch Netflix with it perched on my belly in bed like I did for three years with my Air.

It's comical how much I hate this computer. If I wasn't roughing it on minimal expenses in Mexico, I'd sell it and get a new Air. I'm glad I didn't sell my old Air because I guarantee inside of three months I'll be using it over this MBP. It just needs a new battery but there aren't any Apple stores here.

<comment><USER3> I had my E key lift off and just went to the store. They put a new one on.

</comment></comment><comment><USER4> I tried out the MBP keyboard before buying and thought it would be ok. Unfortunately, the experience of using it for a few minutes in a store is very different from using it several hours a day. My fingers literally hurt most days. I cannot believe that "upgrading" to a new computer could be such a big step backward on this important metric.

<comment><USER5> I was never a keyboard snob. I never owned a mechanical keyboard, and I never "just had to tell" someone about my new cherry mx pro aqua-purple super keys. All keyboards seemed passable to me, with no further opinion. The new macbook (which i was issued at work) is the first time, actually, that I had an opinion on a keyboard. and it was a distinctively bad one. It was an interesting realization that one could hate a keyboard. I switched to ASUS C302CA and the keyboard there is actually nice :)

<comment><USER6> To give a counterpoint, I absolutely love the new keyboard and think it's objectively one of the best I've ever typed on (sans the arrow keys, which are a horrible step backward).

That said, I already replaced a machine with this keyboard due to failing keys and now have a silicone cover over the keyboard of the new one, which inarguably degrades that experience. I'd rather have an okay keyboard that works than a fantastic one that doesn't.

</comment></comment></comment><comment><USER7> I'm holding off an MBP update for as long as possible until Apple: 1. Gets rid of the touchbar, 2. Fixes that daft keyboard, 3. Slaps Intel and makes them ship 32GB lpddr4, and an 8 core iWhateger.

<comment><USER8> I've owned every single form factor of the MBP. I've loved all of them except for this latest "touchbar" version. Actually kicking myself for not returning it straight away.

<comment><USER9> I have a collection of 2014 MBPs because I have a real concern that no one is ever going to make a computer that good (or even a decent computer) ever again.

<comment><USER10> My ThinkPad X1 is as good as any generation of MacBook, it is certainly more serviceable and has a better keyboard. You might prefer MacOS to Linux or Windows, but I can assure you that there are very decent hardware alternatives.

<comment><USER9> One of my constraints is that I have to provide IT support for my very non- technical spouse. That is a very severe constraint. Linux is not an option for her, and Windows is not really an option for me. That leaves Macs.

<comment><USER10> My wife has a Mac, but when it dies, I'm going to persuade her to try Ubuntu. She only uses the Mac for Facebook and occasional Word/Excel. I think LibreOffice and Firefox should have her covered.

<comment><USER11> Why not Chromebook?

<comment><USER9> Because I don't want to hand over that much control over my life to a large corporation. (I run my own email server.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I've only had a few issues with my 15" 2017 MBP, mostly dust and dirt easily fixed with compressed air. That said, I never had a problem with any MBP keyboard before this machine. It seems some people are having way more issues than others, which speaks of a significant inconsistency in quality and wear/tear over time.

<comment><USER13> It could also be related to how hard users are on their keyboards. I've a couple dozen MBPs deployed ranging from 2014-2017. The keyboards on newer model don't seem to pair well with heavy (read: slightly abusive) typists. I haven't upgraded mine :).

<comment><USER12> I've noticed similar trends. With SSDs and all metal designs with very few moving parts, I would have thought these devices would be much more durable. Instead, we're breaking the primary input method that used to work reasonably well. So much for progress...

</comment></comment></comment><comment><USER14> Good initiative to push Apple. There are around 7k signatures now as its trending here. Let's assume it gets up to 10-20k over the trending period.

Some X% of the people petitioning there would be actual users of the model in scope (Macbook Pro 2017 and beyond). And Y% of those people may actually have this issue.

Problem is, nobody would ever know X and Y, and its really bad to speculate. It makes the whole petition basically a guessing game.

Realistically speaking, the only outcome would be to force Apple to take note, or at best issue a statement. Either way, the keyboard is not going away. It would be announced that it would get "better over time" \- which it would have anyways. Its hard to do worse than this going by the feedback.

</comment><comment><USER15> I'm currently keeping an 'e' in my clipboard and using paste to type it every time I need it because my e key is totally broken. i, k and spacebar on the way out as well...

</comment><comment><USER16> Wow, I had no idea this was such a common issue. That explains my unreliable left cmd and up arrow keys.

</comment><comment><USER17> I think emails to Apple would be more effective. Petitions to companies tend to have a bandwagon effect and seem to be largely ignored, especially by Apple.

<comment><USER18> I suppose they could sign the petition and link to it in their feedback email to firstname.lastname@example.com

</comment></comment><comment><USER19> I agree this keyboard is the worst. I also have aching fingers from using it, compared to my previous 2013 pro 15", and beloved thinkpads.

I currently have a broken 'S' key (a couple of the very fragile teeny tiny clips have broken off the keycap) after just a few months - Admittedly, becaue a liquid spill rendered the 'S' intermittently unresponsive, so I removed the keycap to clean with alcohol, which did at least fix the contacts, so the key works, but broke the keycap. Hopefully I can get a replacement keycap to keep me going until probably the liquid spill (a splash of beer, countered immediately with turning the laptop off and upside down in front of a fan overnight etc) starts corroding.

But regardless, the most egregious fault is that the keyboard can't be replaced without also replacing half the laptop, at excessive cost, not to mention the affront of having to pay again for the same crappy keyboard.

This is unacceptable, as the keyboard is one of the few moving parts on the device, and the one most exposed to external dangers.

</comment><comment><USER20> I'm having issues with my 2015 Macbook Pro display getting weird unremovable marks and stains from interaction with the keyboard. I hope they'll replace it for me but these quality issues are really annoying. Here's a (bad) pic to show what I mean: [https://i.imgur.com/LIK4qq5.jpg](https://i.imgur.com/LIK4qq5.jpg)

<comment><USER21> This is a well known issue and Apple will replace your screen free of charge when you take it in. The catch is your laptop will be in service for a week or two which is very annoying if you depend on it for work. You can always buy a new laptop from them while they repair it and return the purchased laptop to them once you get your own laptop back

<comment><USER22> Apple refused to replace for this issue for me on my 2013. Claimed I must have damaged it by applying too much pressure to it in a bag. Did everything I could including many emails but got nowhere, so if you're able to offer any advice or even a case reference or something I could refer to I will definitely try and get them to repair it again.

Looks like the same might be happening to my six month old MBP, along with the keyboard going, which I've been really careful with, so yeah, Apple laptops aren't in my good books right now!

<comment><USER21> There's a facebook group [0] that has people in it who have successfully gotten Apple to change their display for free. Have you tried talking to their online support? When I did and referenced "Staingate" they told me to bring my MacBook in and replace it for free.

When I did it, they said they would only do it up until 3 years after the purchase date of the Macbook but there are people in that Facebook group who have had theirs changed for free with a little bit of arguing.

0: [https://web.facebook.com/groups/607572909386595/about/](https://web.facebook.com/groups/607572909386595/about/)

<comment><USER22> Ah this is great, thank you - I didn't realise there had been a proper recall: [https://www.cultofmac.com/514741/apple-extends-free- repair-p...](https://www.cultofmac.com/514741/apple-extends-free-repair- program-2013-2015-macbook-pro/)

Mine falls within the repair window so I'll be taking this up with them again. Thanks

</comment></comment></comment></comment></comment><comment><USER23> They have a similar design flaw in the 2015 macbook pros.

The keyboard and trackpad will stop working after about a year. It happens because the trackpad ribbon cable sits on the battery, and as the battery heats and expands it destroys the ribbon cable. This design flaw was introduced in the 2015 line.

When you take it to Apple, they say you can either pay $500 to get the keyboard and trackpad replaced, or pay $100 for them to swap out the ribbon cable. Mind you, that ribbon cable only costs $10 if you order it online and swap it out yourself.

Here's a youtube video that shows how to fix it. It has tens of thousands of views:

[https://m.youtube.com/watch?v=0AVoXTd-N0Q](https://m.youtube.com/watch?v=0AVoXTd-N0Q)

And there are tons of these fix-it videos on youtube for this specific issue. Lots of people are having this same exact problem. Apple does not acknowledge that this is a problem.

</comment><comment><USER24> This one could really do _without_ the special HN apple weighting, I'm sure there are plenty of HN apple users who would benefit from seeing/signing this.

<comment><USER25> I certainly benfitted from a hearty and possibly-sinister laugh, as the owner of a T450s.

<comment><USER24> I don't own one of these either, I pretty much hate the current state of apple hardware and software, but that doesn't mean I don't have empathy for those who have essentially been conned by Apple here... don't get me wrong I get a bit of a sinister grin as I see Apple's shitty tactics fail on them, but ultimately they screw over people, and this petition is an opportunity to do right by the people and make Apple pay up.

</comment></comment></comment><comment><USER26> Omg please do this Apple. My keyboard sucks and I already sent it in once for repair. I can't keep losing my laptop it's too inconvenient.

</comment><comment><USER21> The 2017 keyboard seems to not have any of those issues. The touchbar can sometimes be really annoying when I accidentally hit the Siri key when typing fast.

Overall I prefer my 2017 15" pro to my 2015 one mainly because it is thinner, supports USB-C charging, and the screen is much much better

<comment><USER27> > The touchbar can sometimes be really annoying when I accidentally hit the > Siri key when typing fast.

So disable it?

</comment></comment><comment><USER28> I have issues, too, but it's with random keystroke repeats. The fingerprint button has been making strange noises since I got the brand new MacBook Pro. I'm hugely disappointed, but Apple is arrogant and won't fix this for us, though!

</comment><comment><USER29> I've got a late 2016 MBP and the right command key does not register about 1/10 of the time I press it. I use that key a lot. I'm taking it to the Apple Store tomorrow to see what they say about it.

<comment><USER30> I have a late 2017 MBP and the left command key does not register about 2/3 of the time unless you press it in exactly the right spot. We've cancelled all current/future MacBook Pro orders due to problems with the keyboard.

</comment></comment><comment><USER31> I wonder if Apple is being subtly sabotaged by competitors who have double agent employees that wormed their way into Apple and gained access to Tim Cook's ear.

</comment><comment><USER32> I own a 15" MacBook Pro 2016 and already this keyboard has given me more trouble than any other laptop keyboard. Several of the keys are "mushy" and harder to press than most of the others, and there have been times where a spec of dust rendered some of the keys temporarily defective. None of the keys have outright stopped working, and I thankfully haven't run into the double- keypress issue, so at the moment the mushy keys are not worth risking getting an even worse keyboard if I were to try to get a replacement before my warranty expires (I purchased this less than a year ago Apple refurbished).

This petition may not amount to anything, but I'm sure _someone_ in Cupertino has taken notice. Apple has "we know what's best for our customers, better than they do" engrained in their culture, and when it comes to design decisions, _sometimes_ they are right, but I don't see how anyone there could justify a defective or unreliable (at best) keyboard being the right thing for any of its customers. You know what would take courage? To publicly acknowledge the issue and do right by your customers. That takes way more courage than removing a headphone jack.

Unless a recall actually happens (not likely, but I'm really hoping so), we'll never know what--if any--kind of impact this petition has had, but I'm hoping it will cause Apple to (at minimum) go back to the drawing board on this thing and give us a better keyboard the next time around. They should also expose the keyboard to more rigorous testing (that includes dust and other air debris). I just hope the keyboard I have lasts until I'm ready for an upgrade because I don't see myself spending $700 on a repair when this is already the most expensive laptop I've ever purchased (and the $700 is a gamble considering you could get an even worse keyboard).

The sad thing is, back in 2006 I was in the US Military stationed in Baghdad, and I had with me a cheap $600 Dell laptop. That thing survived sand storms that would leave the inside of our tent (and all of our belongings) covered in dust (even with the laptop lid closed and inside of a locker). I highly doubt this keyboard would have survived that deployment. It's sad that a low-end DELL computer from 2006 had a keyboard that's more reliable than Apple's top of the line notebook. If it weren't for macOS, which I love probably more than Apple does, this whole keyboard saga would have caused me to ditched Apple laptops and go with Lenovo.

At the time of this writing, 16,778 people have signed the petition. If each one of those people are a MBP owner, and let's round down the average cost to $2000, that's $33,556,000. That's a drop in the bucket compared to the 5.8 billion in Mac revenue in Q2; however, the Mac business seems big enough to at least please the thousands of customers who feel cheated.

</comment><comment><USER33> Easiest way for Apple to fix this is to expand the TouchBar thing to handle the whole keyboard and add some haptics.

Everyone will hate it but... it will be reliable and amazingly thin.

Maybe use too much power?

<comment><USER34> Oh, please please please.

If it's programmable (and they did a decent job of making the touchbar programmable), it could be an incredible tool. And while getting the haptic right is probably tough, I wonder if it could be in reach now (I love the Magic Touchpad 2, and that's not much smaller than a keyboard. Although keyboard will need to give some cues as to where the keys "are"...)

The howls of the anti-touchbar crowd would just be the icing on the cake...

<comment><USER35> With such keyboard you can't rest your hands on the keys anymore. It's not possible to work that way for any non-trivial time.

<comment><USER36> this is the biggest muscle memory i've had to fight myself from doing. i never realized how much time i would rest my fingers on a key in the Fn key row until the touch bar.

i could not imagine trying to do this for an entire keyboard.</comment></comment></comment></comment>


Startups increase 29 percent - <AUTHOR> http://www.centralvalleybusinesstimes.com/stories/001/?ID=5197 <comment><USER2> Lately people in the valley -- and on this list -- have been talking about how successful entrepreneurs are more likely to be young (say, in their 20's).

This article and its sources would appear to flatly contradict that thought, except that I think the article is defining "startup" as any new business. Whereas we're talking tech.

So maybe younger people do better in tech businesses but not in general? Why would that be? More in touch with new technology? More willing to ignore conventions in applying it? At the same time, suffering from less legal, financial and market acumen.

\</comment><comment></comment><comment>

According to Challenger, start-ups in the first quarter were dominated by experienced workers over 40. Of those starting their own firms, 88 percent were over 40. That was up from 78 percent in the previous quarter.

"It makes sense that these seasoned veterans might be more jaded about the corporate employment experience and are therefore more likely to turn to self- employment. In many respects, these individuals are also better suited than their younger counterparts for entrepreneurship, since they have a deeper foundation in business operations and probably have built a larger network of professional contacts who are critical in drumming up customers," says Mr. Challenger.

"New start-ups will most likely be dominated by older, more experienced veterans of corporate America for the foreseeable future as baby boomers leave the traditional workforce and start their own firms," he says.

Evidence that this is already occurring can be found in unpublished government data revealed by Challenger, which show that those 55 to 64 and older represent one of the fastest growing groups of self-employed workers.

Data from the Bureau of Labor Statistics show that the number of Americans 55 to 64 categorized as self-employed in non-agricultural industries increased 33 percent from 1,439,000 in 2000 to 1,919,000 in 2006. The number of self- employed 65 and older grew 19 percent from 659,000 to 781,000 during the same period.

The largest number of self-employed workers consists of boomers 45 to 54 years old, who accounted for more than 2.7 million or 25 percent of the nation's 10.9 million self-employed in 2006.</comment>


Montreux Jazz Live – 50 years of music history released - <AUTHOR> http://www.montreuxjazz.com/ <comment><USER2> This has such potential, but ALL kinds of problems with the website navigation and display (at least in latest Chrome on Linux).

Am I missing if there is some sort of audio download somewhere?

</comment><comment><AUTHOR> They have some amazing and very interesting footage!</comment>


Ask HN: Best web E2E testing library? - <AUTHOR> Getting into testing, currently a backend developer. Was thinking Puppeteer as it has so many uses. Heard good things about Cypress. Any suggestions? <comment><USER2> Check this out [https://specflow.org/getting- started/](https://specflow.org/getting-started/)</comment>