Tag Archives: session

OSCON 2010: License to Fail

Posted on by
2

Robert “r0ml” Lefkowitz

This session is a companion to the session on competition r0ml presented on Wednesday. For those of us who, for whatever reason, were unable to attend the previous session, he provided us with five second summaries:

  • Wednesday: Competition is bad, don’t do it.
  • Thursday: Licensing is bad, don’t do it.

And with that, the session is over.

I’m kidding, of course. The best part of any of r0ml’s talks is the logic he uses to get from his observation to his conclusion. As he noted at the outset, the path typically takes us through the Middle Ages.

I don’t deal with lawyers very much in my day job, since I work in a support role for our engineering departments. However, I know several people in our Open Source group, and have attempted to release some of the Perl modules I’ve written while on the job. Doing so is decidedly non-trivial and, after two years I still haven’t been allowed to release my code. To say I’m disappointed is an understatement.

My experience with lawyers has been that they are extremely cautious. While frustrating, I understand that it’s their job to play it safe and to protect the company. They are scared, almost beyond reason, that an Open Source license will find its way into a piece of intellectual property that they’d rather not release. It can’t be easy trying to bridge the gap between the closed and open ways of doing business.

The topic was introduced with a question: What is the difference between copyright and plagiarism? Plagiarism is forever. I didn’t quite catch what r0ml meant by this, but I suspect it means that copyright (eventually) expires, granting the work in question to the public domain. Plagiarism, if one can get away with it, creates an attribution that lasts forever.

That, if one is an Open Source geek, leads one to think about licenses. Let’s take the attribution clause of the BSD, which contains two sub-clauses, for example. It’s redundant. It effectively means that the recipient of the source code can not claim credit for the author’s work. Under copyright law, this is already the case, so why the redundancy.

In the name of efficiency and refactoring, r0ml mused whether it would be possible to reduce the number of license clauses to one. He found this in the Do What The Fuck You Want To Public License.

Through inductive reasoning, if we can reduce the number of clauses from two to one, we should be able to similarly reduce the number of clauses from one to zero. After all, if we begin with the earlier premise that licenses are bad, this should be the goal, right?

First, briefly, why are licenses bad? There are many reasons and many arguments; too many of each for this post, but to summarize a few important ones, as of this writing, the Open Source Initiative lists 73 approved licenses. Choosing between them can be a daunting task. Neither do all of these licenses play well with each other, further complicating the selection task if one is attempting to integrate differently-licensed source code. Finally, it’s rare that anyone knows all that they are agreeing to in the license.

The Medieval sensibility was that all knowledge came either from God or from the Ancients. As such, no one could claim credit for a work, because, without exception, it would be plagiarism. For this reason, the majority of works produced during the Middle Ages were compilations, a representation of existing information.

We have a modern equivalent of this Medieval concept of copyright, called the Compilation Copyright. A compilation of files in the public domain is assembled with copyright only on the compilation. Further, no one may claim credit on the same collection of files. Instead, a new compilation, or derivative work, must be created.

How bad has copyright gotten? Well, thanks to the Apple development kit, there is a short piece of code, included in every project, that is separately copyrighted by everyone who has used the development kit. This is getting out of hand, to say the least.

So r0ml wrote unlicense.rb, which will scan a directory recursively, removing any licenses it finds. This, of course, is perfectly acceptable under the terms of the licenses being removed, so long as the files aren’t redistributed. It does have the effect of pleasing the obsessive-compulsive user.

Under the laws of many countries, a copyright notice isn’t actually required to have a copyright. This is particularly true in the United States and the European Union. In fact, in the latter one cannot even waive the protections of copyright. This creates the default case: without a license, nobody other than the author has the right to do anything with the code. The default is all rights reserved.

Richard Stallman, founder of the GNU project and the Free Software Foundation, was not trying to protect the author of code from people downloading the code; rather, he created the GNU General Public License to protect the users of the code. He felt that users have an inherent right to have access to the code running on their computer. Thus, the primary reason for the creation of Open Source licenses was to protect the user.

Many companies claim that they have an Open Source business model. Typically what this means is that they offer their software, or some subset of their software for free, under an Open Source license. Then they offer support contracts, for usually high prices. These aren’t really Open Source business models. The SQLite project has the only known true Open Source business model. The software itself is released into the public domain. This is a scary place for lawyers, especially those employed by large companies. To assuage their concerns, the company that employs the author of SQLite will be more than happy to sell them an Open Source license for the code.

Next, r0ml talked about warranties. In some jurisdictions, the default case under the law is that there is an implied warranty, unless stated otherwise. Most of us have seen the disclaimer of warranty, included to protect the author, attached to the license in code we have downloaded (or added it to code we’ve released), usually in all capital letters. While not a strict requirement to be in capital letters, it is a requirement that the disclaimer be made to stand out. Often, licenses are in plain text files, so using a bold face type isn’t possible. Hence, capital letters. The simplest case of a disclaimer is such:

/* This program comes without any warranty, to the extent permitted by law. */

As we recall, the default case under the law is an implied warranty so including the phrase “to the extent permitted by law” is redundant. Also, it should be noted that copyright law, in the United States, is codified at the Federal level, in Title 17 of the United States Code, while warranty law is codified by the states. This leads to many more jurisdictions, and far more potential confusion, for warranty law.

So finally, here is r0ml’s part serious, part humorous take away: don’t include either a copyright or a warranty with your code. If a user sues you for damages under the implied warranty in a state court, counter-sue them in US federal court for copyright infringement. After all, under the law they were not given permission to copy the code anyway.

A question came at the end of the session, from someone who appeared mildly upset and defensive. He pointed out that Stallman created the GNU General Public License for a good reason, which wasn’t mentioned by r0ml during his talk. Someone had taken the code Stallman was freely distributing and sold it. After which, they went back to Stallman to inform him that he could no longer distribute his own code, because he hadn’t licensed it. The questioner appeared to be offended by the whole point of the session, apparently feeling that all the work Stallman has done for Free Software was being ridiculed and that, without these licenses, “capitalists” will simply steal the code for their own nefarious purposes.

To this, r0ml did have a response. Copyright law has changed since Stallman faced the problem that led to his creation of Free Software. It has become more strict and the requirement for registration has been dropped. The point was made that the questioner is actually referring to the concept of provenance, not copyright. However, this concept was not further explored as, unfortunately, time had run out.

OSCON 2010: Awesome Things You’ve Missed in Perl

Posted on by
Reply

Paul Fenwick (Perl Training Australia)

Ever since I saw An Illustrated History of Failure two years ago, I’ve made it a point to see @pjf‘s talks. That’s how I find myself in his mid-afternoon session, Awesome Things You’ve Missed in Perl. Judging by the size of the crowd, I’m not the only one. However, I won’t attempt to pass along his humour in this post. I’d never do it justice.

In his introduction, Piers Cawley asked that we go wild when Paul took the stage, so the folks in the Google Wave session next door would be taken aback, and realize that Perl is not, in fact, dead.

People are still out there writing Perl as if still in the dark ages of 2008. Paul doesn’t want us to write old Perl, but only new and shiny Perl. This talk only covers practices that have come about since Perl Best Practices was released.

Object-oriented Perl is not awesome. Not even close. If you look at the old ways of doing it, all of them are either wrong, stupid, or both. The rest are too hard. There’s a simple way to fix this: use Moose. This module does so much of the infrastructure work of composing classes, it makes object-oriented programming enjoyable again.

Paul spent a lot of time giving a humorous, high-level overview of the features available in Moose.

The Moose module contains a huge number of extension modules in the MooseX namespace.

When I have a problem, I go down to the pub with other Perl mongers and bitch.

One of the limitations of Perl, that is exposed to Moose, is that not everything is an object. This means methods like push() or isa() can’t be called on everything. And checking types defeats the purpose of polymorphism. Enter the autobox module, which turns everything into an object. As a bonus, it operates in lexical scope. Moose exposes autobox through the Moose::Autobox module.

A module that Paul wrote, autodie, which is now included in core. This lexically scoped module removes all of the boilerplate code that goes along with trapping errors from subroutines.

Not only is Perl 5.10 awesome, but Perl 5.10 regular expressions are awesome. In particular, the introduction of named captures (via %+) made regular expressions extremely awesome.

Perl 5.10 also provides grammars in the regular expression engine. This is the basis for Damian Conway’s Regexp::Grammars module.

Referring to an article on SweeperBot in The Perl Review. However, there’s the problem of distributing a program that uses half of CPAN to users of inferior operating systems, such as Microsoft Windows. That’s where the PAR module comes in. It will pack up all of the modules used by the program, including the Perl interpreter itself if necessary, so a single, self-reliant file can be distributed to users who need it.

Remember to never optimize code. Programmer time is far more valuable than CPU time. However, when you must optimize code, profile first. The Devel::NYTProf makes profiling awesome.

Code reviews are important, but Perl programmers are lazy. Fortunately, the Perl::Critic module has read Perl Best Practices for you and will complain about where your code violates the practices in the book. At my day job, it does about half the work of code reviews for me, loudly announcing violations of the coding standards that I enforce with an iron fist.

If you find an awesome module, buy the author a beer if you have the opportunity. There’s also CPAN Ratings to leave feedback or perlthanks in recent versions of Perl.

OSCON 2010: 21st Century Systems Perl

Posted on by
2

Matt Trout (Shadowcat Systems Limited)

The full title of this session is, 21st Century Systems Perl – the New Perl Enlightment for sysadmins

Introduction

While Perl isn’t dying, “PERL” most certainly is dying. This is a good thing, because it includes all the really crappy stuff, such as Matt’s Script Archive. Thank goodness for that. To be fair, this code would have been horrible written in any language. Remember, blame the artist, not the tool.

We have a very mature community, which means we also have very mature practices. We are also converging on a standard platform, even if there are more than one ways to do something.

Part 1: Minimising Developer Fatalities

As a developer, we should do what we can to make our sysadmins’ lives easier.

Right off the bat, we should use the local::lib module, which allows an application to use custom library areas without polluting the system installation areas. It can even work with /etc/skel. Matt is a big fan of using a local library path, included with the application, so it can be maintained separately from both the operating system vendor’s modules and even other applications.

Improve module installation using Module::Install.

Package modules for your distribution of choice using cpan2dist.

Improve the CPAN experience using App::cpanminus, which is amazing easy to bootstrap:

> wget cpanmin.us
> ./cpanm

Start using all of the modules associated with best practices by installing Task::Kensho.

Vendors are getting better at distributing Perl and keeping up with module releases. The Debian Perl team is the strongest, with Fedora lagging quite a bit far behind. Fedora is finally getting better, now that members of the Perl community have a say in the packaging of Perl and the modules.

After many debug sessions, Matt has come to the conclusion that mod_$lang is evil. Jamming languages into the web server is a bad, bad idea. However, actually hooking into the different handlers can be useful. Matt’s preference now is now FastCGI.

Part 2: Maximising Automation Banality

“In the systems world, shiny and exciting is not good.”

Use the autodie (in core as of 5.10) and the IPC::System::Simple modules to reduce the repetitiveness and the common errors of systems programming.

Use IO::All to fix the syntax and semantics of I/O operations.

Systems script shouldn’t need to be deployed. It should be possible to just drop the script onto a host and it will Just Work. That’s where PAR::Packer.

OSCON 2010: Dist::Zilla

Posted on by
Reply

Ricardo Signes (Pobox.com)

The full title of this talk is, Dist::Zilla – Maximum Overkill for CPAN Distributions.

Every CPAN distribution contains a significant amount of crap. It’s infrastructure used for the distribution tools.

ExtUtils::MakeMaker has been the traditional way to work on the infrastructure code. By necessity, it contains a lot of legacy, which can be cumbersome to maintain. Enter Module::Install, which can look in the expected places for the necessary information, such as the author name. But, the author still must write all the boilerplate. Module::Starter was written to address this, composing all the boilerplate on behalf of the author. There is so much boilerplate that, by default, Module::Starter also provides a boilerplate test to detect it.

Why are we doing all of this? How much repetitive work are we doing?

What can Dist::Zilla do for us? For starters, we can remove some files:

  • LICENSE
  • MANIFEST.SKIP
  • Makefile.PL
  • README
  • t/pod.t
  • t/pod-coverage.t

Leaving us with only our Changes file, our code, and our tests. The non-infrastructure parts. On top of that, Dist::Zilla does all of the boring distribution bits for us. It only handles the make dist command. It does not handle the make install command, which means the users who install the module don’t need all of the dependencies.

Dist::Zilla puts all of its functionality into plugins, which will be the meat of the rest of this session. It also uses a very simple INI-style configuration file.

The main command provided by the module is dzil build. This bundles the distribution, which will contain all of the infrastructure necessary for users to install the module. When building, it follows a simple work flow:

  1. Gather files
  2. Munge files
  3. Collect metadata
  4. Write out

There is no default configuration, but there is a Basic plugin bundle that will include all of the most common plugins.

What followed were examples of what the plugins can do. Of course, all of them are designed to reduce cruft—the non-code, non-documentation bits that we’re forced to maintain. The philosophy is the same one I advocate to anyone who will listen: computers are good at doing boring, repetitive tasks with derived data; why don’t we let them do more of that stuff?

I’ve followed @rjbs on Twitter for a while, and I’ve seen him talk about Dist::Zilla. I’ve wanted to try it out for a while, to simplify my distributions—both for CPAN and for my day job—but I didn’t realize until this session just how awesome the tool is. It’s a complete framework for managing Perl module distributions. Dist::Zilla will give my Laziness score a huge bump.

OSCON 2010: Building Applications with the Simple Cloud API

Posted on by
Reply

Doug Tidwell (IBM)

http://www.oscon.com/oscon2010/public/schedule/detail/13976

I finally left the Perl track. I attended Tim Bunce’s presentation on Devel::NYTProf at OSCON two years ago and, while there have been many enhancements made to module since that time, I expect this year’s talk won’t differ much from the previous one.

This session on Simple Cloud is being presented by IBM’s Cloud Computing Evangelist. The drivers behind this product (is it a product?) are the development and promotion of a standard cloud API. There is some relevancy with my day job, not only because of the possibility of using cloud services, but as a way of getting ideas for the API I develop for our engineers to interact with the batch compute system.

There are several levels of where we can work. The levels start at the wire, where we have to generate and parse data ourselves. From there, we have vendor-specific APIs, service-specific APIs, and finally service-neutral APIs. This last level is where we want to be.

The Simple Cloud API covers three areas: file storage, document storage, and simple queues. Once thought of in these simplified concepts, there really isn’t any reason the interface used by a program can’t be standardized. A program should no more need to concern itself with the implementation details of an individual cloud provider than it does the details of the file system of the computer on which it runs.

The API uses the Factory and Adapter design patterns, with a configuration file used by the Factory object to determine which Adapter should be created. These patterns are exactly what I’ve been looking at for the API I work on at my day job.

A demo of the Simple Cloud API followed. There wasn’t much to these demos. The first showed listing data stored at two different providers. The second showed queue manipulation.

After the demo, the Apache libcloud, which is getting a good deal of vendor support.

OSCON 2010: Cool Perl 6 Today

Posted on by
Reply

Patrick Michaud (pmichaud.com)

I’m just back from lunch at Burgerville with Juan and Jonathan. On the way back into the convention center, I ran into Alasdair, who has been attending the hardware hacking sessions. That made me think that I may want to try to find non-Perl sessions to attend. After all, I tend to keep up with Perl news, so the sessions are of marginal usefulness. Unfortunately, nothing on the schedule looked very interesting to me. I was curious about the session on Open Source Tool Chains for Cloud Computing until I read the description. While it looked cool, it wouldn’t be useful for me in my work. The session would go through provisioning, setup, and maintenance of hosts, all of which we already have well-entrenched solutions for in my day job. So, I ended up back in the Perl track. My friends in the San Diego Perl Mongers group will appreciate that, I think.

Anyway, on to the session.

The name Perl 6 is a language specification, rather than any particular implementation. All of the references and links off-handedly mentioned in this post are available from the Perl 6 website.

Patrick is the lead developer of Rakudo Perl, which is the most feature complete and up-to-date.

Perl 6 has a language specification and a test suite. There are still many places in Perl 6 that are not being tested yet.

Rakudo * (Star) is scheduled to be released a week from tomorrow, targeted at being a useful, usable, early adopter distribution.

At this point, Patrick began to enumerate the new language features and how they work in Perl 6, such as variables, loops, interpolation, and so on. I won’t go into these here, since there are numerous places on the Web where this has been documented.

About half way through this session, I realized that “r0ml” was presenting in another room. If I’d noticed that before, I would have attended that session.

OSCON 2010: Perl 5.12

Posted on by
Reply

Jesse Vincent (Best Practical)

This talk could be titled something along the lines of “Lessons Learned from Project Management.”

Jesse Vincent is the current Perl 5 pumpking, which for the moment can be thought of as the project janitor.

People who say “Perl is dead” or that Perl hackers are “desperate” are behind the times.

There are a lot of exiting things happening that are not in the Perl core. Audrey Tang has said that “CPAN is the language, Perl is the syntax.” Like Piers in the previous session, Jesse enumerated a handful of things that make Perl awesome:

While some of the coolest new things happening in the CPAN world, it merely scratches the surface of what is available.

About three months ago, Jesse uploaded Perl 5.12. Amazingly, no one has reported any critical regressions.

Jesse has been assured that Rakudo * will be out next week, on 29 July. However, Perl 6 will not replace Perl 5, which has paid Jesse’s mortgage for many, many years. Also, thanks to Perl 5.12, Perl 5.10 is no longer “too new to use.”

Perl 5.12 marks the latest release in the process of cleaning up the inernals and adding much desired features. Some of the highlights:

  • Deprecations warn by default
  • suidperl is dead
  • package Foo::Bar 1.0; – better version import syntax
  • Y2038 compliant – thanks to Schwern
  • Unicode improvements; upgrade to 5.2
  • Pluggable keywords
  • Overridable function lookup
  • Dtrace support
  • Deprecated modules – Class::ISA, Pod::Plainer, Shell, Switch (but still on CPAN)
  • Yadda, yadda, yadda operator

Jesse believes the best new thing in Perl 5.12 is the release process, including him as the pumpking. Twenty years ago, Perl didn’t use version control. He recommends learning from this mistake.

It took five years to release Perl 5.10, after burning through two pumpkings.

Before 5.12, maintenance releases contained all sorts of bug fixes and updates, but could not break binary compatibility. Doing so was a huge task, was very difficult, and, contrary to its name, is unmaintainable. Even without all this work, the pumpking’s job is a lot of work. Jesse really doesn’t want to burn out after a release of Perl.

Traditionally, the process of turning someone with the necessary skills to be the pumpking involves preventing them from using those skills and replacing them with management skills. It’s a shame.

The system is broken and Perl 5 isn’t going anywhere, so how can it be fixed? We can reinvent it, but that’s already being done by Perl 6. Alternatively, we can refactor it. There is no reason many of the skills and duties required of the pumpking can’t be delegated out to people with those skills. In effect, the most important skill and duty for the pumpking is project management.

The 5.9 releases, leading up to 5.10, were haphazard. The 5.11 releases, leading up to 5.12, have settled into a new release every month on the twentieth, with a couple of exceptions. The 5.13 series has followed suit. One of the reasons this was possible was documenting the entire release process.

Releases in the 5.12 series are on a fixed schedule, every three months. A release schedule has been created for 5.14, too.

One of the things I’ve learned working in an enterprise and my observations of the Fedora Project is that good project management is vital. Jesse Vincent is exactly what Perl needed and he continues to demonstrate that, with regular, high quality releases of Perl. What’s more, he is a good spokesman for the project, being able to come to OSCON and give a session on all of this detail in a cojent and interesting format.

OSCON 2010: New Beginnings in Perl 5

Posted on by
2

Piers Cawley (BBC)

After reviewing today’s session schedule, I quickly came to the conclusion that I will spend my entire day sitting in the room “Portland 256.” This is, apparently, where the Perl track is located.

Paul Fenwick introduced Piers in song, to the tune of Gilligan’s Island.

Piers switched from Perl to Ruby a while back and swore that he wouldn’t return to Perl until 6. Facetiously, the reason he switched to Ruby was the handsome community associated with it and he reason he switched back to Perl was the amazingly supportive community associted with it. He began with a point about programming style. We think of code as describing what we are doing, but in reality the majority of our code actually describes how we are doing it. This infrastructure code is noise.

More seriously, he absolutely hated unrolling the @_ variable in every function. In such a high level language like Perl, why must we pop arguments off the stack in the same manner we would in an assembly language? This leads to long subroutines, every single one containing anti-patterns designed to implement the language infrastructure, instead of the language doing the work for us.

Moose does a lot to improve writing classes, using a more declarative syntax. However, even within Moose methods we need to write the infrastructure code. The MooseX::Declare module solves this problem, giving method syntax a more declarative style. By moving the infrastructure code out of sight, we can better focus on what we are trying to do, rather than how we are doing it.

Piers proceeded to list the modules that “rock” and brought him back to Perl:

Perl’s object-orientation absolutely “sucks.” However, this turns out to be a good thing. It allows very clever people to create modules that extend the semantics of the language. In a language like Ruby, which has a good object-orientation built-in, it’s essentially stuck. If, in the future better ideas of object-orientation are developed, they can be implemented in Perl far more easily than in Ruby. An interesting point: sometimes when the tool sucks, things are better. People develop layers of tools that enhance and extend the original.

It also helps that the Perl release schedule has accelerated.

Piers continued with a high-level, hand-waving explanation of how MooseX::Declare works. While not informative, it was entertaining. Including a video of Matt Trout attempting to hypnotize the room.

Piers ended by thanking the Perl community and expressing how good it feels to be back into it and developing in Perl again.