Blog Fiasco

January 25, 2015

Introducing the “Permissive 3000″ license

Filed under: Linux,The Internet — Tags: , , , , , — bcotton @ 6:39 pm

Software licenses aren’t necessarily the easiest texts to understand. This issue is compounded when the person trying to understand the license is in a different jurisdiction or is a non-native speaker of English. A recent thread on the OSI’s license-discuss list brought this issue to light. According to the original poster, a project using the BSD 3-Clause license was used without attribution in a proprietary product. The developer lost the court case because the judge did not understand English well. The poster brought an attempt at a rewrite to the list, but it had some contradictions and other meaningful differences. So I thought I’d give it a try myself.

This weekend, I started from the original BSD 3-Clause license and excised all of the words not on the Oxford 3000™ word list (or reasonably close modifications, e.g. verb tense conjugations). I did make an exception for the word “copyright”, since it seems indispensable to a software license. In all other cases, I used synonyms and circumlocution in order to preserve the meaning while remaining within the constrained word list. This was challenging at times, since circumlocution can end up making the document more difficult to understand than an unknown word might. The difficulty is further compounded by the fact that many words have a distinct legal meaning and a synonym might not have the same weight.

I consoled myself with the fact that software warranties (where most of the real challenge was) are probably not that useful anyway. Furthermore, just because a word has a distinct meaning in American courts, that doesn’t mean that foreign legal systems have the same definitions. Trying to use largely U.S.-centric licenses written in English is a challenge for a global society, but I don’t know that a system of jurisdiction/language-specific licenses would be any better.

In any case, without further ado, I present the Permissive 3000 license. It’s highly experimental and totally unvetted by legal professionals, so nobody should use it for anything except a learning exercise. I’m looking forward to some constructive feedback and hopefully it sparks a discussion about how licenses can be simplified so that they’re more easily understood by judges, developers, and users alike.

January 22, 2015

Using tracer to point out service restart needs

Filed under: Linux — Tags: , , , , — bcotton @ 9:04 pm

If you’re seeing this via Fedora Planet, you probably saw Miroslav Suchý’s post from a few days ago about a project called Tracer. Tracer is a friendly tool to tell you what outdated services are running. With the dnf plugin installed, you get a list at the end of the upgrade process.

For example, right after I installed the plugin and ran an upgrade, I was told that I needed to restart the Samba service. In addition, there were several programs that needed to be manually restarted (KeePassX and Spider Oak, to name two). Plus, one process required a logout, and one required a full system reboot.

I’ve found this to be pretty useful, since I don’t always realize what services need to be restarted after package updates. I have a decade of system administration experience, so it’s not too bad for me. For others, this is a great way to shine light on exactly what needs to be restarted and how.

January 18, 2015

On Linus Torvalds and communities

Filed under: Linux,Musings — Tags: , , , , — bcotton @ 4:06 pm

This week, the Internet was ablaze with reactions to comments made by Linus Torvalds at Linux.conf.au. Unsurprisingly, Torvalds defended the tone he employs on the Linux kernel mailing list, where he holds no punches. “I’m not a nice person, and I don’t care about you. I care about the technology and the kernel—that’s what’s important to me,” he said (as reported by Ars Technica). He later said “all that [diversity] stuff is just details and not really important.”

The reactions were mixed. Some were upset at the fact that an influential figure like Torvalds didn’t take the opportunity to address what they see as a major issue in the Linux community. Others dismissed those who were upset by pointing to the technical quality of Linux, cultural differences, etc.

I don’t subscribe to the LKML, so most of the posts I’ve seen are generally when someone is trying to point out a specific event (whether a behavior or a technical discussion), and I don’t claim to have a good sense for what that particular mailing list is like. Torvalds and the Linux community have developed a great technical product, but the community needs work.

Speaking to open source communities in general, too many people use the impersonal nature of email to mistake rudeness for directness. Direct and honest technical criticisms are a vital part of any collaborative development. Insults and viciousness are not. Some people thrive in (or at least tolerate) those kinds of environments, but they are incredibly off-putting to everyone else, particularly newcomers.

Open source communities, like any community, need to be welcoming to new members. This allows for the infusion of new ideas and new perspectives: some of which will be obnoxiously naive, some of which will be positively transformative. The naive posts of newcomers can be taxing when you’ve seen the same thing hundreds of times, but everyone has to learn somewhere. The solution is to have a team armed with pre-written responses in order to prevent frustrated emails.

Not being a jerk doesn’t just mean tolerating noobs, though. Communities should have an established code of conduct which addresses both annoying and mean actors. When the code of contact is being repeatedly breached, the violator needs to be nudged in the right direction. When a community is welcoming and actively works to remain that way, it thrives. That’s how it can get the diversity of ideas and grow the technical competency that Linus Torvalds so desires.

January 2, 2015

In defense of the bazaar

Filed under: Linux,Musings,Project Management — Tags: , , — bcotton @ 9:22 pm

Earlier this week, I came across a 2012 article from Poul-Henning Kamp entitled “A generation lost in the bazaar“. This is a reference to Eric S. Raymond’s seminal The Cathedral and the Bazaar, which advocates for making the sausage, so to speak, in public. Using the Linux kernel and his own fetchmail program as examples, Raymond emphasizes the benefits of rapid, iterative development and of fostering a user community that acts as co-developers. This stands in contrast to the “cathedral” style of development where a product is worked on by a small number of people until it is ready to be revealed to the public.

Kamp’s point (and subtitle) is “quality happens only when someone is responsible for it,” which I endorse wholeheartedly. However, he is mistaken to blame Raymond’s bazaar for “a clueless generation of IT ‘professionals’ who wouldn’t recognize sound IT architecture if you hit them over the head with it.” What he observes is the democratization of programming, which is due to ever-cheaper hardware, free (as in beer) software, and the Internet. Had The Cathedral and the Bazaar never been written I doubt the world would look dramatically different, at least in this respect.

IT is in its awkward teenage years. It has been around long enough that it can do pretty cool things, but not so long that it has accumulated much wisdom. The fact that anyone can write software (or copypasta snippets from various example sites and fora) and make it available to others is simultaneously a wonderful and terrible thing. Nonetheless, that doesn’t make the bazaar style wrong.

Kamp described the end result of the bazaar as “a pile of old festering hacks,” and I’ll agree that its an apt description for a lot of software. It’s probably just as apt for a lot of software developed in the cathedral style. Raymond devotes a fair portion of his book to quality and good design, and it’s unfair to blame him for people not following that part (assuming they’re even aware of his work at all).

Raymond makes many unsubstantiated claims that the bazaar style of development leads to higher-quality software. That may or may not be the case. My own view is that the bazaar style is well-suited for open source projects. After all, open source is about more than code.

November 17, 2014

Mozilla’s new ad feature

Filed under: Linux,The Internet — Tags: , , , — bcotton @ 8:55 pm

Edited to remove erroneous statements about what gets sent to Mozilla based on Matthew Miller’s comment below.

Mozilla’s release last week of in-browser ads has caused quite the discussion on the Fedora development mailing list. Firefox now will show sponsored “tiles” on the default home screen when a new or cleared profile is used. Although Mozilla claims to collect data in such a way that it’s not personally identifiable, there are reasons to be concerned. Sure, this can be disabled, but the default behavior is the only thing most users will experience.

The reactions on Fedora-devel spanned the gamut from indifference to insistence that Firefox be removed from the repository entirely. My own take (which was already represented on the mailing list, so I refrained from “me too”-ing) is that the right answer is to disable this feature in the Firefox build that ships in Fedora, effectively making it opt-in instead of opt-out. Mozilla has a history of being a good actor and I don’t begrudge them trying to make some money. However, I’d prefer that the user have to consciously enable such tracking.

Though I disapprove of the implementation, I find it hard to get very worked up about this. The Internet is awash in tracking. Google and Facebook probably know more about me than I do about myself. But that’s because I decided the value I get from those sites (well, not so much Facebook) is worth the data I give them. I respect the right of others to come to their own decision, which is why opt-in is preferred.

I appreciate the opinion of those who think the only appropriate response is to remove Firefox entirely, but I find that to be a wholly impractical solution. If Fedora wants casual desktop users (and I see no reason to not court that use case), having Firefox is and important part of a welcoming environment. A great deal of casual computing is done in the browser these days and Firefox is a well-known browser (even if some people call it “Foxfire”). Sure, there are other FLOSS browsers (including IceWeasel), but few of them work as well for casual users as Firefox and none of them have the familiarity and name recognition. Given the good Mozilla has done for free software over the years, this hardly seems like a bridge worth burning.

August 16, 2014

Fedora Board proposal

Filed under: Linux — Tags: , — bcotton @ 2:04 pm

In an email to the Fedora community this week, the Fedora Board asked for comments on a proposed change to how Fedora is governed. Although I haven’t been as active in Fedora as I’d like, I still contribute and I still have opinions on the proposal. The following post is the feedback I provided on the board-discuss mailing list. In accordance with the desire to keep discussion from fragmenting, I have disabled comments on this post.

My initial reaction to this proposal was “what did I just read?” At first glance, it looked like a move from a democracy to a dictatorship. I even used the phrase “the Shuttleworthization of Fedora.” Having taken the time to process the proposal, as well as look at the the accompanying material, my reaction has shifted. In the process of writing about the parts of the proposal I’d like to keep, I realize that I essentially came up with the same proposal in different terms. My two point summary:

  • Lengthen board terms to reduce turnover (I’m not necessarily in favor of the indefinite terms as presented, but one year is too short)
  • Change the board from being entirely at-large to being representative of major constituencies

The Fedora Board, at least from the perspective of an irregular contributor, is indeed a very passive organization. To some degree, I find that appropriate for our community, but I can appreciate the arguments that a more active board would benefit the community and the product we labor to produce. The questions that arise are: “how active should the board be?” and “how do we structure the board such that it meets this need?”

My concern is that we’re addressing the second question before addressing the first. We don’t know where we’re going, but we know how we’re going to get there! The thread on board-discuss back in September was unclear about the intended relationship between a re-imagined board and FESCo. The proposal as presented offers no additional clarity. The proposal talks of leading and doing without really talking about the scope of responsibility. Perhaps that’s the main problem with the board as currently constructed?

February 13, 2013

How do you measure software quality?

Filed under: Linux — Tags: , , , , — bcotton @ 10:30 am

There are two major license types in the free/open source software world: copyleft (e.g. GPL) and permissive (e.g. BSD). Because of the different legal ramifications of the licenses, it’s possible to make theoretical arguments that either license would tend to produce higher quality software. For my master’s thesis, I would like to investigate the quality of projects licensed under these paradigms, and whether there’s a significant difference. In order to do this, I’ll need some objective mechanism for measuring some aspect(s) of software quality. This is where you come in: if you have any suggestions for measures to use, or tools to get these measures, please let me know. It will have to be language-independent and preferably not rely on bug reports or other similar data. Operating on source would be preferable, but I have no objections to building binaries if I have to.

The end goal (apart from graduating) is to provide guidance for license selection in open source projects when philosophical considerations are not a concern. I have no intention or desire to turn this into a philosophical debate on the merits of different license types.

January 15, 2013

Deploying Fedora 18 documentation: learning git the hard way

Filed under: Linux,The Internet — Tags: , , , , — bcotton @ 5:49 pm

If you haven’t heard, the Fedora team released Fedora 18 today. It’s the culmination of many months of effort, and some very frustrating schedule delays. I’m sure everyone was relieve to push it out the door, even as some contributors worked to make sure the mirrors were stable and update translations. I remembered that I had forgotten to push the Fedora 18 versions of the Live Images Guide and the Burning ISOs Guide, so I quickly did that. Then I noticed that several of the documents that were on the site earlier weren’t anymore. Crap.

Here’s how the Fedora Documentation site works: contributors write guides in DocBook XML, build them with a tool called publican, and then check the built documents into a git repository. Once an hour, the web server clones the git repo to update the content on the site. Looking through the commits, it seemed like a few hours prior, someone had published a document without updating their local copy of the web repo first, which blew away previously-published Fedora 18 docs.

The fix seemed simple enough: I’d just revert to a few commits prior and then we could re-publish the most recent updates. So I git a `git reset –hard` and then tried to push. It was suggested that a –force might help, so I did. That’s when I learned that this basically sends the local git repo to the remote as if the remote were empty (someone who understands git better would undoubtedly correct this explanation), which makes sense. For many repos, this probably isn’t too big a deal. For the Docs web repo, which contains many images, PDFs, epubs, etc. and is roughly 8 GB on disk, this can be a slow process. On a residential cable internet connection which throttles uploads to about 250 KiB/s after the first minute, it’s a very slow process.

I sent a note to the docs mailing list letting people know I was cleaning up the repo and that they shouldn’t push any docs to the web. After an hour or so, the push finally finished. It was…a failure? Someone hadn’t seen my email and pushed a new guide shortly after I had started the push-of-doom. Fortunately I discovered the git revert command in the meantime. revert, instead of pretending like the past never happened, makes diffs to back out the commit(s). After reverting four commits and pushing, we were back to where we were when life was happy. It was simple to re-publish the docs after that, and a reminder was sent to the group to ensure the repo is up-to-date before pushing.

The final result is that some documents were unavailable for a few hours. The good news is that I learned a little bit more about git today. The better news is that this should serve as additional motivation to move to Publican 3, which will allow us to publish guides via RPMs instead of an unwieldy git repo.

January 11, 2013

A wrinkle with writing your resume in Markdown

Filed under: Linux — Tags: , , , , — bcotton @ 11:59 pm

For Sysadvent 2011, Phil Hollenback wrote an excellent post called “Write Your Resume in Markdown Already!” Ever since I read it, I’ve been using a Markdown file as the source for my resume, which gets rendered to HTML and PDF as necessary. Recently, someone using Windows tried to open the PDF of my resume in Acrobat Reader. When she did, she got errors about missing fonts. “How odd,” I thought. In the course of several job applications over the past year-plus, I hadn’t heard of any problems. (It’s possible that nobody reviewing my resume used a Windows machine to do it.)

I fired up my Windows XP virtual machine that I keep around for playing Sim City 2000 and installed Adobe Reader. I was able to reproduce the problem, which is always comforting. It didn’t shed any light on the matter, though. I actively avoid doing anything “cute” so that my resume (and other documents) can easily be read by anyone on any platform. After examining the workflow, I figured that the problem had to be in the LaTeX template used to generate the PDF.

One of the features of the template is the conditional use of packages and font settings. Since the pandoc package in Fedora 17 (version 1.9.4.2) no longer includes the markdown2pdf command in previous versions, the –xetex argument that Phil passed isn’t necessary. Removing the control structure resulted in a PDF that looked qualitatively the same, but would open on Windows. Phil’s instructions are still good overall, but they need some tweaks for newer versions of Pandoc.

Here’s a diff, for those of you who are interested:
7,9d6
< $if(xetex)$
< \usepackage{ifxetex}
< \ifxetex
15d11
< \else
18,22d13
< \fi
< $else$
< \usepackage[mathletters]{ucs}
< \usepackage[utf8x]{inputenc}
< $endif$

 

October 2, 2012

Proposed change to Fedora docs schedule

Filed under: Linux — Tags: , , , — bcotton @ 7:59 pm

In the most ideal situations, project management can be a challenge. In a fast-moving, community-driven, highly-visible project like Fedora, it can be near-madness. Although the Docs group tries to keep to the schedule when producing guides, the unfortunate reality is that guides rarely meet the scheduled milestones. I’m a firm believer in the idea that if the schedule is never met, it’s the schedule that’s wrong, not the contributors.

With that in mind, it was proposed in this week’s Docs meeting that the branching of guides be 4 weeks prior to the final release date, instead of shortly after the Alpha release. This buys guide writers more time to incorporate the changes a new release brings. Unfortunately, it puts an extra crunch on translators since they then only have four weeks to update translations if guides are to ship in concert with the OS.

The reality is that it doesn’t change much, I expect. Since the reality is that the guides don’t come in on time, it does little harm to have the schedule reflect that fact. I hope. I posted a message to the Docs and Translation teams earlier this week requesting comment. Modified schedule proposals are available at http://bcotton.fedorapeople.org/docs_schedule/.

Older Posts »

Powered by WordPress