Tuesday, April 10th, 2012
Just a quick announcement that the newest version of QuickRelease has shipped!
(Lucky!) 0.13, most notably, has the following updates/improvements:
- Entries from your release configuration files can now be coerced by the ConfigSpec class into dictionaries; you can do this be defining an item in the configuration file with the syntax [key1 value1] [key2 value2]
- You can now define command-line overrides for variables; you must set allow_config_overrides to true in your config file to allow this behavior, but after doing so, you can redefine variables from the commandline, like so: quickrelease -p SomeProcess -c myconfig.cfg -DoverrideVariable=overrideValue -DanotherOverride=somethingElse. This is especially useful for processes that are used daily, and thus need minor configuration changes.
- Addition of a chdir() utility method that follows shell semantics; this is a bit of a random feature, but some programs (Perforce’s p4 command line utility, most notably) rely on a correctly-set PWD environment variable instead of getcwd(3) to know which directory they’re operating in; this function provides a compatibility layer for such programs.
- You can now pass either a filename or an input stream to RunShellCommand(), and it will hook this up to the calling process. This is useful for some programs (again, notably, p4) where you can script their behavior by giving them commands via STDIN.
Packages can be grabbed directly from github. (We’ll be publishing “proper” packages for future releases.)
As always, if you run into any problems, don’t hesitate to let us know
And if you’re interested in the project, feel free to follow/fork us on github!
The focus on 0.14 will be something many have been asking for: more documentation, and examples, including a sample set of processes, steps, and configuration to build Firefox!
open source, quickrelease, Releases, tools
Releases | No Comments »
V1055
Thursday, August 5th, 2010
Slashdot ran a Your Rights Online post a couple months ago posing the question “Do Build Environments Give Companies an End Run Around the GPL?”
The upshot: are companies1 basing their device firmwares on Linux breaking the GPL by posting only their source code, but omitting details2 regarding the environment required to to build that firmware, much less flash a device with these customized firmware.
It’s certainly an interesting question.
Ask any developer and they probably wouldn’t consider the build environment as at all related to GPL-compliance requirements. That’s likely because the vast majority of open source software builds on any standard GNU/Linux machine3; the context of “GPL-compliance” is version 2 of the GPL, released in 1991, when Linux-using embedded devices wasn’t on anyone’s radar.
But as embedded and mobile consumer electronics companies have leveraged the wealth of open source software to bring products to market quickly, this has become a very real issue, and the keepers of the GPL, the Free Software Foundation, have realized that could be a problem.
One of the main issues is “tivoization“, named after the obvious reference after they disallowed the execution of firmware containing modifications on their hardware. Such behavior is specifically restricted in version 3 of the GPL.
In the latest version of the GPL, this behavior was specifically called out as a allowable use of the end user and/or developer.
This problem doesn’t just affect embedded devices.
A common starting point for an open source hacker poking at these types of products it to try to reproduce what a company ships to its users4. But these days, that may not even be possible in software.
Mozilla Corporation, for example, now builds some of its builds with profile guided optimizations. This requires building Firefox, running it in an instrumented fashion, and using that data to guide the optimization of hot spots.
To provide a good, real world set of runtime data, Mozilla tests with a static page set of about 200 websites on the web. But it can’t release this archived content—now used in the build process—due to copyright restrictions.
So, even though open source developers are building Firefox on Win32, it won’t match what Mozilla Corporation actually ships to millions of users5.
To be sure, the issue of build systems, specifically, involves a very narrow interpretation of the GPL. Even in the cases the GPLv3 specifically addresses, there isn’t broad agreement among open source developers that such use should be disallowed7.
It may be annoying to open source hackers to be unable to fully experiment with custom firmwares their shiny new embedded, consumer product whiz-bang device.
It may take more time to reverse engineer how to flash these devices8 to get firmwares on them.
This sort of “freedom” may require a tradeoff in terms of enjoyment or functionality of these devices as manufacturers move more functionality into service offerings in the cloud, they can refuse access by these custom firmwares10.
But up to now, users have voted with their dollars and download clicks: they don’t care.
Most open source developers apparently don’t either.
_______________
1 who have the resources, but not the resolve
2 Either images or documentation
3 The venerable ./configure && make && make install triad
4 The so-called identity proof
5 To be fair, I cite Firefox as an example of this problem because it’s one I’m familiar with; Mozilla requires probably one of the most complex open source build environments around, and they’ve done a good job of, especially, documenting their build environments to the extent possible6 and making it easier to build on Win32.
6 Something I have no qualms asserting a large chunk of responsibility for having made happen
7 Linus Torvalds, for one, has stated that he doesn’t consider such restrictions on the use of the hardware to be a problem
8 And make no mistake, there are open source hackers out there, that totally get off on that sort of stuff, so they will find a way to do it9
9 Even if it nets them a few bricked devices
10 As Sony has done with its “Other Operating System” feature, and now routinely does with the Playstation Network and PS3 updates
gpl, hardware, licensing, open source
Community, Preed on Build/Release Engineering, mozilla | 5 Comments »
V514
Monday, July 12th, 2010
Last week marked that time of the year again: the week where everyone heads to the Mozilla Summit, and the Mozilla Project all but shuts down.
This was the second year the Summit was held in Whistler, BC.
It has a reputation for being a raucously great time, even if getting home can be a bit… complicated.
Mozilla began holding summits in Whistler after my tenure, so I’ve never attended. I know my name has been submitted to the proposed attendee-list1, but I’ve never gotten an invitation. I always just imagined it had just gotten lost in the mail.
But maybe not?
Recently, the project manager for one of the Mozilla’s core projects, SeaMonkey, unceremoniously announced he would not be attending the Summit this year, despite being one of the Mozilla project’s oldest, most involved and committed members. This was not by his choice; Mozilla’s project leaders “vetoed [his] being invited.”
Disallowing a core member of one of your community’s own projects2 to attend a summit being held for your community certainly seems antithetical to the purpose of such a gathering.
It also raises an interesting, but seldom discussed issue: how, exactly, does one pass the gauntlet to get on the Summit-approved list?
For a company who continually touts3 its openness4, and an open source project, it’s a detail of the Summit’s planning that is surprisingly opaque.
An oft-cited reason for the secrecy around this selection process is that paying for each person’s flight, room, and board for a week is expensive.
That’s certainly understandable.5
But it’s also an easily solvable problem.
If the goal of such a gathering is to build bonds and increase communication within the Mozilla community, the project could provide clear, objective, succinct criteria by which any and all community members who actively contribute6 would be able to attend.
For those contributors Mozilla Corporation doesn’t feel it appropriate to sponsor, a “summit fee” could be calculated, just like any other conference. Those individuals would be responsible for their own transportation costs; the hotel can give them the same discount it provides to Mozilla Corporation. The Mozilla Foundation could even win bonus points by offering a couple “scholarships.”
But with this current closed, black-box process, it doesn’t feel like an open source project hosting a gathering that is interested in and welcoming of everyone’s ideas, discourse7, and participation.
It’s much more like a corporate retreat8.
And there’s absolutely nothing wrong with that.
But if Mozilla has decided it only wants certain individuals involved in its main showcasing, planning, and community-building event, I suggest they follow @rands‘ advice, and stop trying to sell the Summit as anything else.
_______________
1 By multiple people
2 SeaMonkey is listed prominently on the Foundation’s website, right behind the products its corporate arms steward
3 “To achieve these goals, we use a highly transparent, extremely collaborative process that brings together thousands of dedicated volunteers around the world”
4 And, indeed, whose mission is The Open WebTM
5 Figures for the Summit’s cost aren’t public, at least that I’ve ever seen; it wouldn’t surprise me if it were upper-six digits, though. Maybe a 7th digit?
6 in the myriad colorful ways Mozilla community members contribute
7 Even if “lively”
8 With “special guest appearances”
Community, mozilla, open source
Community, mozilla | 3 Comments »
V496