Hacker News Reader

willnorrison Ian's Shoelace Site

I've been using Ian's Secure Shoelace Knot for... years? I can't even remember how long, but it's served me very well. I just love how much more secure it is and how symmetrical and balanced the final result is. It's also such a trivial upgrade for kids that have learned to tie their shoes using the "bunny ear" method... just one extra twist.

https://www.fieggen.com/shoelace/secureknot.htm

And like many things on HN, previous discussion: https://news.ycombinator.com/item?id=13399095

willnorrison Golink: A private shortlink service for tailnets

A couple of the startups that do go links have blog posts on the history:

https://www.golinks.com/blog/go-links-history/

https://www.trot.to/blog/2020/07/09/go-links-origin-story

willnorrison Golink: A private shortlink service for tailnets

I forgot to add a link to our recent announcement blog post to the project README. I've added that now, and I think it may help explain why we specifically built a service like this on top of Tailscale to take advantage of Magic DNS, automatically authenticated connections, etc. https://tailscale.com/blog/golink/

willnorrison Microformats Wiki

UX definitely ended up being one of the hardest parts. We also never got to the point of really building a compelling product on top of the protocols. We did actually do some work on privacy though, but it never got super far. For example, you could set simple access controls on content that was only available to friends that logged in with an OpenID. I think I had it so that certain of your hcard attributes were only included for authenticated users as well.

Some of the work we did then still exists today in various forms. Activity Steams led to Activity Pub, which has seen far more adoption than we ever did.

And microformats are still widely used in some communities, though certainly not like it could have been, largely things to Google putting weight behind schema.org. For example, nearly all of the indieweb.org work is based around microformats at the core, with things like webmention, micropub, etc

willnorrison twitter/the-algorithm

same team. different company.

willnorrison Things you probably don't know about Go (2012) [slides]

From https://blog.golang.org/gopher:

The gopher has no name, and is called just the "Go gopher"

willnorrison Google to Reimplement Curl in Libcrurl

on it: https://news.ycombinator.com/item?id=20228237

willnorrison Google to Reimplement Curl in Libcrurl

Hey, Will from Google's Open Source Office here.

I apologize for the confusion this caused; that was certainly not the intent. Mea culpa! The name "libcrurl" was just an internal working name for this effort that wasn't expected to gain much attention.

This project is still very experimental in nature (as discussed at https://bugs.chromium.org/p/chromium/issues/detail?id=973603...), and there are no plans here to try and replace or compete with libcurl. We have huge respect for the tireless work Daniel does to maintain curl, and didn't mean to cause any confusion or extra work for him.

To make things clearer, the team is renaming the project, and adding some more docs outlining the goals and intent of the project: https://chromium-review.googlesource.com/c/chromium/src/+/16...

willnorrison Software Engineering at Google (2017)

And for anyone that wants to learn more about how Google manages third-party code, all of our docs are public at https://opensource.google.com/docs/thirdparty/

willnorrison GIF for CLI

https://opensource.google.com/docs/releasing/publishing/#dis...

willnorrison Introducing Git protocol version 2

We currently only list project that are or were primarily developed by Google. We decided to include projects that started at Google and were since donated to foundations, such as Kubernetes.

But we aren't yet including projects where we are just heavy contributors, but they're not "Google projects". That includes Linux, git, LLVM, and a host of others. We do want to recognize them in our project directory, but want to make sure that they are distinguished from Google projects so that we're not implying something that is accurate.

willnorrison Google embraces, extends, and extinguishes

> The default google approach to open source is unidirectional source dumps after all the work is done.

I can definitely say that is not our default approach to open source; in fact it's a very small minority of projects that actually operate in that fashion. However, I can understand that it could feel that way to some people.

We've long said and continue to believe that there is no one way to do open source. That's true of nearly every aspect of a project including licensing, governance, community management, etc. Project are released for different reasons, with different motivations and goals, and so the way they are managed often differs.

One area I know we could do better is to set better expectations for projects around many of these topics. How is the project managed, how are decisions made, how committed to this are we (ie. are we using it in production), etc? If those aspects of a given project were clearer, would that address some of your concern (with the understanding that some projects may be be held closer to the vest than others) ? Or are you objecting to the tighter control in general?

willnorrison Google embraces, extends, and extinguishes

Could you expand on this a bit? We've tried to be very transparent with how we approach and think about open source by publishing all of our internal documentation at https://opensource.google.com/docs/. Is there something that's missing from that? Or are you thinking about certain specific projects being opaque in terms of how their managed?

willnorrison A new home for Google Open Source

Thanks. What you said definitely exemplifies the problem we were trying to solve. People often look through one or two of our GitHub organizations, but don't realize that we actually have over 100 of them. Plus many of our projects aren't actually on GitHub (or at least only mirrored to GitHub). The goal of this directory was to help discover those projects.

willnorrison A new home for Google Open Source

The problem is that we have over 2,000 projects, so simply listing them all on one page doesn't work very well. Hence why we built this directory, which allows browsing by category, by tag, by language, as well as full text search.

willnorrison A new home for Google Open Source

The other problem is that we have 100+ GitHub organizations, so browsing them all together is impossible.

willnorrison Operation Rosehub – patching thousands of open-source projects

To clarify the timeline a little bit here... Rosehub wasn't actually motivated by the MUNI hack, as it predated it by 8 months (Rosehub started in March 2016, MUNI hack was announced in November). As noted in the blog post, it was instigated by Justine seeing that open source packages weren't updating their dependencies to protect themselves, then doing some digging and realizing just how widespread the problem was.

However, the MUNI hack certainly did motivate being more public about the project and writing this blog post, since it really helped underscore the severity of this vulnerability in very real, concrete terms.

willnorrison Open-source Funding and Support Questionnaire

There's no indication in the questionnaire of who is actually running it, what is being done with the data, whether results will be published and where, etc. Does anyone have more info? Right now, this just looks like a black hole.

willnorrison Android N is Nougat

http://www.theverge.com/2013/9/3/4691040/android-kitkat-the-...

"There's no exchange of money involved"

willnorrison Nano is no longer a GNU project

Just to be clear on this, Google projects (including side projects of Google employees) do not require copyright assignment in the way that FSF projects to. They require an explicit copyright license, but the author retains the copyright. Full details at https://cla.developers.google.com/about

willnorrison US Senate website says use HTTP instead of HTTPS

Somewhat confusingly, pulse.cio.gov lists senate.gov as supporting HTTPS with an 'A' from SSL Labs. While that is of course technically correct, it doesn't tell the full story, since no actual content is served over HTTPS.

Would it be worth trying to update pulse.cio.gov to detect cases like this? That's non-trivial to do in a reliable automated fashion, but seems like it might be worth the effort?

willnorrison IndieWeb

There are the actual Indie Web Camps that occur several times throughout the year. And each month there is the Homebrew Website Club Meetup (http://indiewebcamp.com/next-hwc, named after the Homebrew Computer Club).

willnorrison Open source license usage on GitHub

Google Code has always been exclusively for open source projects. From https://code.google.com/p/support/wiki/FAQ#Hosting_Your_Open...

> Can I use Google Code to host projects that aren't open source?

> Nope. Open source projects only.

willnorrison GRPC: A high performance, open source, general RPC framework

that's definitely a bug that you can't read the agreement text without logging in. We'll see about getting it fixed.

willnorrison Excellent Open Source Go Projects

nice project... I just updated a couple of minor gofmt, go vet, and golint issues I had overlooked in google/go-github, so the score is a little higher now :)

Just curious, at what level are you raising the cyclomatic complexity as an issue? Looks like around 12?

It might also be worth considering test coverage as another factor.

willnorrison Go is moving to GitHub

CCA?

willnorrison Brad Fitzpatrick on the future of Go

Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.

willnorrison Todo: Talk Openly, Develop Openly

I'd recommend seeing the comments from jamesgpearce (of Facebook) and amateurhuman (of GitHub) on this previous thread: https://news.ycombinator.com/item?id=8321995. Also, this Wired piece does a really good job of capturing the origins of the group and what it's trying to do: http://www.wired.com/2014/09/medieval-style-guilds-will-rema....

Folks are right that the goals are somewhat vague, and some of that is intentional... we're still working it out. But we realize that we all work at companies that have formal open source programs that are solving a lot of the same problems, but we aren't collaborating with each other to the extent that we could. Particularly when it comes to how we run those programs and deal with the challenges that are unique to medium to large companies using and releasing open source. This group is an attempt to start having those discussions.

willnorrison My first Chrome Extension. Looking for constructive criticism and advice

Chrome forcing the user to re-approve the extension when it tries to access more data is a feature, not something to work around. That alone is reason enough for me to say "thanks, but no thanks"

willnorrison Web Starter Kit

Not really... it's about the same amount of work whether it goes to Google Code or GitHub. The teams that have an easier time of it are those that are using Git+Gerrit internally, since a public release is as simple as `git remote add` and `git push`. A number of teams continue to use tools like https://code.google.com/p/make-open-easy/ with varying degrees of success.