Profile cover photo
Profile photo
George Dunlap
178 followers
178 followers
About
George's posts

So I've spent a few months being annoyed by a particular bug that caused my test VMs to hang just after grub. This week I discovered some simple changes that would make things either work or not work, so decided I was going to finally get down to the bottom of it. After probably spending 50% of my time this week on it, I discovered that running the following in the root directory my "master" image fixes the problem:

tar cvfz /tmp/boot.tgz boot/ && rm -rf boot/* && tar xvfz /tmp/boot.tgz

In other words, the problem was a bug in grub that was tickled by the particular filesystem I had. Removing and re-writing the filesystem avoids tickling the bug and everything works fine.

Not the worst bug I've ever had, but certainly one of the more annoying ones.

Post has attachment
So there's been a bit of a dust-up in the last few days about GitHub's new Terms of Service, and claims that they are incompatible with the BSD and the GPL.

IANAL; but the issue for the GPL, as I read it, is here in section D5:

"If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality." [1]

Reading this, it sounds like this: "All code which you upload is assumed to be under the GitHub Hosting License, in addition to whatever other license it is under", where the GHL (as I'm calling it) consists of basically, "Each user of GitHub has a nonexclusive worldwide license to &c".

There are two problems with this. First, if you're uploading GPL code that you didn't write, then you are not legally allowed to issue such a license. Which means no mirroring or moving pre-existing projects to GitHub without getting permission of all copyright holders (which in large projects is nearly impossible).

Secondly, depending on whether "reproduce" includes "with modification", it essentially makes GitHub a loophole through the GPL, like this:

1. Fork GPL repository
2. Remove GPL license file (so that section D6 doesn't apply)
3. Make modifications which are not GPL'ed
4. Distribute via Github

Steps #2 and 3 are valid because you have the "Github Hosting License" granted via the ToS, which does not forbid such changes. Many projects, such as homebrew, actually use Github as a content distribution network. So basically as long as you only use Github, you could end-run round the GPL requirements.

This "attack" does depend on whether you have the right to "reproduce" modified works. On the one hand, the Copyright Act of 1976 [2] explicitly distinguishes between the right to "reproduce" and the right to "create derivative works". So one could argue that the "GHL" allows you to fork a repo, but not make any modifications to it without some other license in place. On the other hand, someone could make the case that since the whole point of GitHub is to fork and modify, that modification would be implied by " as permitted through GitHub's functionality".

I understand that their goals are to make sure that even repos without an explicit license have an implicit license to do normal GitHub-y things (like fork and modify). But I think a better wording would be something like this:

"If you set your pages and repositories to be viewed publicly, they must be under a suitable license. Any specified license must allow any users of GitHub to access, use, and display the Content, as well as reproduce it (without modification) on GitHub as permitted through GitHub's functionality. Any repository without a license will be assumed to be under the Github Hosting License [link] until such a license file is added."

Requiring that it be under such a license solves the problem that you don't own the copyrights; saying that the extra license only applies if no license file is specified gets around the issue of having a "loophole"; as does clarifying that reproduction does not include creating derivative works.

[1] https://help.github.com/articles/github-terms-of-service/
[2] https://en.wikipedia.org/wiki/Copyright_Act_of_1976

Post has attachment
Article I wrote summarizing my talk at LinuxCon NA next Monday. Come hear me speak for the full details!

I like Go (the programming language) a lot. But one of the things that seems really brain-dead to me is that the name of your PACKAGE is tied to the name of the PUBLIC GIT REPO where it's hosted. Host it on github personal account? Your package name is now "github.com/gwd/foo". Want to switch to gitorious? Move it from your personal account to a group project? Transfer maintenance to someone else? You have to RENAME your package -- every and every Go source file that refers to it must be changed. And if your package ended up in a Debian package named goland-github-gwd-foo, now the DISTRO PACKAGE needs to be renamed too.

Post has attachment
What about XenSummit? Come hear my talk: "Patch review for non-maintianers"

Post has attachment
Going to LinuxCon North America in August? Come hear my talk: "Making Community Decisions Without Consensus"

"It turns out that some of those attempts to clear sensitive information (like private keys) out of memory using memset() and bzero() were optimized away by some compilers. Clang/LLVM and GCC 5 use an optimization known as "dead store elimination" that gets rid of store operations to memory that is never read again."

It's incredible to me that with all the advancements in safety in languages as a whole, and in important warnings for "risky behavior" in gcc itself, that these sorts of compiler security bugs are still tolerated.

And bugs -- design bugs -- is what they are. If the OpenSSH team -- one of the most paranoid, security-focused teams on the planet -- can trip over it, nobody si safe. No 0.5% performance improvement is worth opening up this kind of massive security hole.

Post has attachment
Hmm, so apparently there's an update to Windows 2008 in which an updated virtio block driver from SuSE will replace the virtio block driver from RedHat, causing your VM not to be able to boot on RedHat systems any longer. 

Post has attachment
So the SFC is doing a fundraiser. According to their blog post [1], "We have structured the campaign with two make-or-break levels: a lower level that will just sustain the organization for a "bare minimum" service plan to our member projects, and a separate, higher level to continue doing copyleft enforcement. If we don't meet these goals we'll be forced to radically restructure."

Why this sudden need for funding? According to the same blog post, "...since we launched the VMware suit some of our corporate funding has been pulled because we tackle important but controversial issues, like GPL compliance. We have even have had talks blocked or cancelled at conferences."

They haven't named any names, but according to some clever sleuths [2], only two companies have recently dropped their SFC membership: a company called appendto.com (who appears to have been acquired by another company), and the Linux Foundation.

VMWare is a silver member of the Linux Foundation. [3]

[1] http://sfconservancy.org/blog/2015/nov/24/faif-carols-fundraiser/

[2] https://lwn.net/Articles/665855/

[3] http://www.linuxfoundation.org/about/members

"Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)’s applicability to circumstances like these." -- the US DoJ simultaneously demonstrates the knowledge and ignorance about computer programming
Wait while more posts are being loaded