Search Results: "ed"

1 December 2015

Vincent Sanders: HTTP to screen

I recently presented a talk at the Debian miniconf in Cambridge. This was a new talk explaining what goes on in a web browser to get a web page on screen.

The presentation was filmed and my slides are also available. I think it went over pretty well despite the venues lighting adding a strobe ambiance to part of proceedings.

I thought the conference was a great success overall and enjoyed participating. I should like to thank Cosworth for allowing me time to attend and for providing some sponsorship.

Raphaël Hertzog: My Free Software Activities in November 2015

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 21.25 hours on Debian LTS. During this time I worked on the following things: The Debian Administrator s Handbook Now that the English version has been finalized for Debian 8 Jessie (I uploaded the package to Debian Unstable), I concentrated my efforts on the French version. The book has been fully translated and we re now finalizing the print version that Eyrolles will again edit. Paris Open Source Summit On November 18th and 19th, I was in Paris for the Paris Open Source Summit. I helped to hold a booth for Debian France during two days (with the help of Fran ois-R gis and several others).
Fran ois Vuillemin, Juliette Belin and Rapha l HertzogFran ois-R gis Vuillemin, Juliette Belin and Rapha l Hertzog
On the booth, we had the visit of Juliette Belin who created the theme and the artwork of Debian 8 Jessie. We lacked goodies but we organized a lottery to win 12 copies of my French book. Debian packaging work Django. After two weeks of preparation for revers dependencies, I uploaded Django 1.8 to unstable and raised the severity of remaining bugs. Later I uploaded a new upstream point release (1.8.6). I also handled a release critical bug first by opening a ticket upstream and then by writing a patch and submitting it upstream. I uploaded 1.8.7-2 to Debian with my patch. I also submittted another small fix which has been rejected because the manual page is generated via Sphinx and I thus had to file a bug against Sphinx (which I did). A work-around has been found in the mean time. apt-xapian-index NMU. A long time ago, I filed a release critical bug against that package (#793681) but the maintainer did not handle it. Fortunately Sven Joachim prepared an NMU and I just uploaded his work. This resulted in another problem due bash-completion changes that Sven promptly fixed and I uploaded a second NMU a few days later. Gnome-shell-timer. I forwarded #805347 to gnome-shell-timer issue #29 but gnome-shell-timer is abandoned upstream. On a suggestion of Paul Wise, I tried to get this nice extension integrated into gnome-shell-extensions but the request has been turned down. Is there anyone with javascript skills who would like to adopt this project as an upstream developer? It s a low maintenance project with a decent and loyal user base. Misc. I fixed bug #804763 in zim which was the result of a bad Debian-specific patch.
I sponsored pylint-plugin-utils_0.2.3-2.dsc for Joseph Herlant to fix a release critical bug. I filed 806237 against lintian. I filed more tickets upstream, related to my Kali packaging work: one against sddm, one against john Other Debian-related work Distro-Tracker. I finally merged the work of Orestis Ioannou on bug #756766 which added the possibility to browse old news of each package. Debian Installer. I implemented two small features that we wanted in Kali: I fixed #647405 to have a way to disable deb-src lines in generated sources.list files. I also filed #805291 to see how to allow kernel command line preseeding to override initrd preseeding the fix is trivial and it works in Kali. I just have to commit it in Debian, I was hoping to get an ack from someone in charge before doing it. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Michal Čihař: Time for change

It has been seven years since I've joined SUSE (for second time, but that's different story). As everything has to come to the end, I've decided to make a change in my life and leave safety net of being employed and go for new experience with freelancer life. This will give me more time to spend on free software projects where I'm involved. Of course I need to earn some money to live, so many decisions about where to spend my time will be backed by money... First of all I will work on phpMyAdmin, where I was chosen as a contractor (of two for this year). This will be half time job for me and you will see weekly reports in my blog, similar to what Madhura is doing. Second priority will be Weblate, especially the hosting solution. I believe that this is something what can work quite well in the long term, but the tool needs some development to make it as great as I would like to have it. If you want me to extend hosting for free software projects, you can do it by money :-). And nobody knows what projects come next. There is some work to be done on Gammu and Wammu, but given that I don't have any recent device to use it, it's sometimes hard to fix the bugs there. Of course this can change if I get some money to work on that. PS: It's not that SUSE would be bad place to work. It's actually pretty great if you're looking for work with free software. You work there on free software, with great people and you get quite some freedom. As bonus once or twice in a year, there is Hackweek which you can spend on anything. And of course they have lot of open positions :-).

Filed under: English Gammu phpMyAdmin SUSE Weblate 2 comments

John Goerzen: Where does a person have online discussions anymore?

Back in the day, way back in the day perhaps, there were interesting places to hang out online. FidoNet provided some discussion groups some local, some more national or international. Then there was Usenet, with the same but on a more grand scale. There were things I liked about both of them. They fostered long-form, and long-term, discussion. Replies could be thoughtful, and a person could think about it for a day before replying. Socially, you would actually get to know the people in the communities you participated in. There would be regulars, and on FidoNet at least, you might bump into them in different groups or even in real life. There was a sense of community. Moreover, there was a slight barrier to entry and that was, perhaps, a good thing; there were quite a lot of really interesting people and not so many people that just wanted answers to homework questions. Technologically, you got to bring your own client. They were also decentralized, without any one single point of failure, and could be downloaded and used offline. You needed very little in terms of Internet connection. They both had some downsides; Usenet, in particular, often lacked effective moderation. Not everyone wrote thoughtful posts. Is there anything like it these days? I ve sometimes heard people suggest Reddit. It shares some of those aspects, and even has some clients capable of offline operation. However, what it doesn t really have is long-form discussion. I often find that if I am 6 hours late to a thread, nobody will bother to read my reply because it s off their radar already. This happens so often that I rarely bother to participate anymore; I am not going to sit at reddit hitting refresh all day long. There are a few web forums, but they suffer from all sorts of myriad problems; no cohesive community, the hot topic vanishing issue of Reddit, the single point of failure, etc. For awhile, Google+ looked like it might head this way. But I don t think it really has. I still feel as if there is a vacuum out there. Any thoughts?

Simon Richter: Debian at the 32C3

In case you are going to 32C3, you may be interested to join us at the Debian Assembly there. As in the last years, this is going to be fairly informal, so if you are loosely affiliated with Debian or want to become a member by the time 34C3 rolls around, you are more than welcome to show up and sit there.

30 November 2015

Lunar: Reproducible builds: week 31 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Reiner Herrmann submitted a patch against debhelper to make dh_installinit source files in a stable order. Chris Lamb found how to make cython output deterministic by ordering the keys used to traverse a dict. Reiner Herrmann proposed a patch for pyside-tools to remove the timestamps embedded by rcc in the generated Python code. Mattia Rizzolo rebased our custom version of debhelper on version 9.20151126. As no objections have been made so far, Mattia Rizzolo has filled #805872 asking -Wdate-time to be turned on by default in dpkg-buildflag. Guillem has since sent a final warning before proceeding as such in the next dpkg upload. Russ Allbery added support for SOURCE_DATE_EPOCH in podlators 4.00 which Niko Tyni intend to backport to Perl 5.22. Packages fixed The following packages have become reproducible due to changes in their build dependencies: fontforge, golang-github-tinylib-msgp, libpango-perl, libparanamer-java, libxaw, sqljet, stringtemplate4, uzbl, zope-mysqlda. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues, but not all of them: Patches submitted which have not made their way to the archive yet: Lunar reported two issues making xz-utils unreproducible (#806328, #806331). reproducible.debian.net A seventh armhf build node has been added (resulting of two more armhf build jobs). Thanks to Vagrant Cascadian for putting this Raspberry Pi 2B to help. (h01ger) jenkins.debian.net has been made more robust against network and proxy failures. (h01ger) A new 100 GB partition has been set up on reproducible.debian.net to prevent disk space issues. Thanks to ProfitBricks for its continuous support to our continuous test system. (h01ger) New graphs showing usertagged bugs have been added on the dashboard to measure the progress without FTBFS issues. Please note that comparing the two graphs might be misleading as more than 1300 FTBFS bugs have been inventoried. (h01ger) Package reviews 78 reviews have been removed, 116 added and 49 updated this week. 25 new FTBFS have been filed by Chris West, Chris Lamb and Santiago Vila. New issues identified this week: timestamps_in_documentation_generated_with_libwibble, copyright_year_in_documentation_generated_by_sphinx, timestamps_in_documentation_generated_by_glib_genpod, random_order_of_tmpfiles_in_postinst, random_order_in_cython_output, timestamps_in_python_code_generated_by_pyside. Reiner Herrmann and Lunar improved the prebuilder script: the script can now be called through a symlink, run parallel builds, calls diffoscope by its new name and ensure to install its recommends, and save the text output aside the HTML one. Reiner also added a script to lookup the last update of notes for a given package. Misc. Santiago Villa has been recently working on making sure that Arch:all packages were properly buildable by running dpkg-buildpackage -A. This uncovered a question that is probably not currently addressed by the policy: on which architectures should architecture-independent be buildable?

Neil Williams: bashrc-git snippets

Just in case someone else finds these useful, some bash functions I ve got into the habit of having in ~/.bashrc:
mcd()  mkdir "$1"; cd "$1";  
gum()  git checkout "$1" && git rebase master && git checkout master;  
gsb()   LIST= git branch egrep -v '(release staging trusty playground stale)' tr '\n' ' ' tr -d '*' ; git show-branch $LIST;  
gleaf()  git branch --merged master   egrep -v '(release staging trusty playground pipeline review stale)';  
mcd is the oldest one and the simplest. The others are just useful git management shortcuts. I can use gum to bring a feature branch back to master and gsb to show me which branches need to be rebased on master, typically after a pull. The list of excluded branches includes branches which should not be rebased against master (I could do some processing of git branch -r to not have those hardcoded) but the odd one is stale. Sometimes, I get an idea for a feature which is too intrusive, too messy or just too incomplete to be rebased against master. Rather than losing the idea or wasting time rebasing, I m getting into the habit of renaming the branch foo as stale-foo and gsb then leaves it alone. Equally, there are frequently times when I need to have a feature branch based on another feature branch, sometimes several feature branches deep. Identifying these branches and avoiding rebasing on the wrong branch is important to not waste time. gsb takes a bit of getting used to, but basically the shorter and cleaner the output, the less work needs to be done. As shown, gsb is git show-branch under the hood. What I m looking for is multiple commits listed between a branch and master. Then I know which branches to use with gum. Finally, gleaf shows which feature branches can be dropped with git branch -d.

Chris Lamb: Free software activities in November 2015

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):
Debian
  • Presented at MiniDebConf Cambridge 2015 on the current status of Debian's Reproducible Builds effort.
  • Contributed initial Debian support to Red Hat Product Security's repository of certificates shipped by various vendors and Open Source Projects. (#1)
  • Wrote a proof-of-concept version of Guix's challenge command to determine if an installed binary package is reproducible or not. (code)
  • Started initial work on a b2evolution package.
  • Arranged logistics for the Reproducible Builds summit in Athens.
My work in the Reproducible Builds project was also covered in more depth in Lunar's weekly reports (#27, #28, #29, #30).
LTS

This month I have been paid to work 13 hours on Debian Long Term Support (LTS). In that time I did the following:
  • Issued DLA 349-1 for python-django correcting an potential settings leak.
  • Issued DLA 351-1 for redmine fixing a data disclosure vulnerability.
  • Worked on multiple iterations of a fix for CVE-2011-5325 in busybox, not yet complete in order to additionally cover hardlinks.
  • Frontdesk duties.

Uploads
  • redis Addressing CVE-2015-8080, a buffer-overflow security issue.
  • python-django Uploading the latest RC release to experimental.
  • strip-nondeterminism Disable stripping Mono binaries as it is was too aggressive preventing some package installs.
  • gunicorn Correct Python interpreter path references in gunicorn3-debian.
  • python-redis New upstream release.
  • ispell-lt Making the build reproducible.


Michael Vogt: APT 1.1 released

After 1.5 years of work we released APT 1.1 this week! I m very excited about this milestone. The new 1.1 has some nice new features but it also improves a lot of stuff under the hood. With APT 1.0 we did add a lot of UI improvements, this time the focus is on the reliability of the acquire system and the library. Some of the UI highlights include: Under the hood: Whats also very nice is that apt is now the exact same version on Ubuntu and Debian (no more delta between the packages)! If you want to know more, there is nice video from David Kalnischkies Debconf 2015 talk about apt at https://summit.debconf.org/debconf15/meeting/216/this-apt-has-super-cow-powers/. Julian Andres Klode also wrote about the new apt some weeks ago here. The (impressive) full changelog is available at http://metadata.ftp-master.debian.org/changelogs/main/a/apt/apt_1.1.3_changelog. And git has an even more detailed log if you are even more curious :) Enjoy the new apt!

Andrew Shadura: Support Software Freedom Conservancy

The Software Freedom Conservancy are desperately looking for financial support after one of their corporate supporters have stopped their sponsorship. This week, there s an anonymous pledge to match donations from new supporters. Becoming an SFC supporter will help them fight for our software freedom. I have signed up for a monthly donation, and I suggest you do so too here.

Mark Brown: Unconscious biases

Matthew Garrett s recent very good response to Eric Raymond s recent post opposing inclusiveness efforts in free software reminded me of something I ve been noticing more and more often: a very substantial proportion of the female developers I encounter working on the kernel are from non-European cultures where I (and I expect most people from western cultures) lack familiarity with the gender associations of all but the most common and familiar names. This could be happening for a lot of reasons it could be better entry paths to kernel development in those cultures (though my experience visiting companies in the relevant countries makes me question that), it could be that the sample sizes are so regrettably small that this really is just anecdote but I worry that some of what s going on is that the cultural differences are happening to mask and address some of the unconscious barriers that get thrown up.

Petter Reinholdtsen: The GNU General Public License is not magic pixie dust

A blog post from my fellow Debian developer Paul Wise titled "The GPL is not magic pixie dust" explain the importance of making sure the GPL is enforced. I quote the blog post from Paul in full here with his permission:
Become a Software Freedom Conservancy Supporter!
The GPL is not magic pixie dust. It does not work by itself.
The first step is to choose a copyleft license for your code.
The next step is, when someone fails to follow that copyleft license, it must be enforced
and its a simple fact of our modern society that such type of work
is incredibly expensive to do and incredibly difficult to do.
-- Bradley Kuhn, in FaiF episode 0x57 As the Debian Website used to imply, public domain and permissively licensed software can lead to the production of more proprietary software as people discover useful software, extend it and or incorporate it into their hardware or software products. Copyleft licenses such as the GNU GPL were created to close off this avenue to the production of proprietary software but such licenses are not enough. With the ongoing adoption of Free Software by individuals and groups, inevitably the community's expectations of license compliance are violated, usually out of ignorance of the way Free Software works, but not always. As Karen and Bradley explained in FaiF episode 0x57, copyleft is nothing if no-one is willing and able to stand up in court to protect it. The reality of today's world is that legal representation is expensive, difficult and time consuming. With gpl-violations.org in hiatus until some time in 2016, the Software Freedom Conservancy (a tax-exempt charity) is the major defender of the Linux project, Debian and other groups against GPL violations. In March the SFC supported a lawsuit by Christoph Hellwig against VMware for refusing to comply with the GPL in relation to their use of parts of the Linux kernel. Since then two of their sponsors pulled corporate funding and conferences blocked or cancelled their talks. As a result they have decided to rely less on corporate funding and more on the broad community of individuals who support Free Software and copyleft. So the SFC has launched a campaign to create a community of folks who stand up for copyleft and the GPL by supporting their work on promoting and supporting copyleft and Free Software. If you support Free Software, like what the SFC do, agree with their compliance principles, are happy about their successes in 2015, work on a project that is an SFC member and or just want to stand up for copyleft, please join Christopher Allan Webber, Carol Smith, Jono Bacon, myself and others in becoming a supporter. For the next week your donation will be matched by an anonymous donor. Please also consider asking your employer to match your donation or become a sponsor of SFC. Don't forget to spread the word about your support for SFC via email, your blog and or social media accounts.
I agree with Paul on this topic and just signed up as a Supporter of Software Freedom Conservancy myself. Perhaps you should be a supporter too?

Michal Čihař: Gammu 1.36.7

Yesterday, Gammu 1.36.7 has been released. This time the list of changes got bigger, improving compatibility with many devices: You an support further Gammu development at Bountysource salt.

Filed under: English Gammu Wammu 0 comments

Stein Magnus Jodal: November contributions

The following is a short summary of my open source work in November. My hope is that keeping better track of what I m doing will help me reflect on how I spend my time, and help me to focus my efforts better.

Debian

Mopidy
  • Released Mopidy-Spotify 2.2.0: Fixes related to duplicate Starred playlists and albums from year 0.
  • Moved Mopidy s Travis CI testing from Ubuntu 12.04 to Ubuntu 14.04, to prepare for GStreamer 1.x, and eventually testing with Python 3.4. PR #1341
  • Worked on porting Mopidy from GStreamer 0.10 to PyGI and GStreamer 1.x. PR #1339
  • Briefly looked at what remains to get Mopidy running on both Python 2.7 and 3.4+ when we ve landed the port to GStreamer 1.x. Doesn t look too bad, except that ConfigParser doesn t want to work with bytes in Python 3, so there s no easy way to read a config file referring to a path on a non-UTF-8 file system.

Comics
  • Fixed two old crawlers. Added two new crawlers.
  • Needs to upgrade to Django 1.8 before the Django 1.7 security support ends this December.

29 November 2015

Dirk Eddelbuettel: gtrends 1.3.0 now on CRAN: Google Trends in R

Sometime earlier last year, I started to help Philippe Massicotte with his gtrendsR package---which was then still "hiding" in relatively obscurity on BitBucket. I was able to assist with a few things related to internal data handling as well as package setup and package builds--but the package is really largely Philippe's. But then we both got busy, and it wasn't until this summer at the excellent useR! 2015 conference that we met and concluded that we really should finish the package. And we both remained busy... Lo and behold, following a recent transfer to this GitHub repository, we finalised a number of outstanding issues. And Philippe was even kind enough to label me a co-author. And now the package is on CRAN as of yesterday. So install.packages("gtrendsR") away and enjoy! Here is a quiick demo:
## load the package, and if options() are set appropriately, connect
## alternatively, also run   gconnect("someuser", "somepassword")
library(gtrendsR)
## using the default connection, run a query for three terms
res <- gtrends(c("nhl", "nba", "nfl"))
## plot (in default mode) as time series
plot(res)
## plot via googeVis to browser
## highlighting regions (probably countries) and cities
plot(res, type = "region")
plot(res, type = "cities")
The time series (default) plot for this query came out as follows a couple of days ago:
Example of gtrendsR query and plot
One really nice feature of the package is the rather rich data structure. The result set for the query above is actually stored in the package and can be accessed. It contains a number of components:
R> data(sport_trend)
R> names(sport_trend)
[1] "query"     "meta"      "trend"     "regions"   "topmetros"
[6] "cities"    "searches"  "rising"    "headers"  
R>
So not only can one look at trends, but also at regions, metropolitan areas, and cities --- even plot this easily via package googleVis which is accessed via options in the default plot method. Furthermore, related searches and rising queries may give leads to dynamics within the search. Please use the standard GitHub issue system for bug reports, suggestions and alike.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Steve McIntyre: Supporting the Software Freedom Conservancy too!

Software Freedom Conservancy Supporter I'm happy to chip in and help the awesome folks at the Software Freedom Conservancy with funding for their work, standing up for copyleft. It's clear that there are a lot of people who will ignore the terms of Free Software licensing, whether by oversight or deliberately, so the SFC are doing an important job working to defend the Freedoms that lots of us are using every day as developers and users. It seems that some of SFC's corporate supporters have stopped sponsorship since the beginning of their lawsuit in Germany against VMware for GPL violations. Maybe some folks are happy to support SFC, but not when they really push things like this. Let's hope that we can find many more individual supporters to cover SFC's funding needs instead. This week, there's an anonymous pledge to match donations from new supporters so right now is an even better time to sign up! Thanks to Paul Wise for posting about this and indirectly prodding me to sign up too.

Matthew Garrett: What is hacker culture?

Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.

This argument is simply wrong.

Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.

These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.

The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.

In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.

Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.

Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.

Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.

When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.

Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.

The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.

(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)

comment count unavailable comments

Steve Kemp: Spent the weekend improving the internet

This weekend I've mostly been tidying up some personal projects and things.
http://debian-administration.org/
This was updated to use recaptcha on the sign-up page, which is my attempt to cut down on the 400+ spam-registrations it receives every day. I've purged a few thousand bogus-accounts, which largely existed to point to spam-sites in their profile-pages. I go through phases where I do this, but my heuristics have always been a little weak.
http://dhcp.io/
This site offers free dynamic DNS for a few hundred users. I closed fresh signups due to it being abused by spammers, but it does have some users and I sometimes add new people who ask politely. Unfortunately some users hammer it, trying to update their DNS records every 60 seconds or so. (One user has spent the past few months updating their IP address every 30 seconds, ironically their external IP hadn't changed in all that time!) So I suspended a few users, and implemented a minimum-update threshold: Nobody can update their IP address more than once every fifteen minutes now.
Literate Emacs Configuration File
Working towards my stateless home-directory I've been tweaking my dotfiles, and the last thing I did today was move my Emacs configuration over to a literate fashion. My main emacs configuration-file is now a markdown file, which contains inline-code. The inline-code is parsed at runtime, and executed when Emacs launches. The init.el file which parses/evals is pretty simple, and I'm quite pleased with it. Over time I'll extend the documantion and move some of the small snippets into it.
Offsite backups
My home system(s) always had a local backup, maintained on an external 2Tb disk-drive, along with a remote copy of some static files which were maintained using rsync. I've now switched to having a virtual machine host the external backups with proper incrementals - via attic, which beats my previous "only one copy" setup.
Virtual Machine Backups
On a whim a few years ago I registered rsync.io which I use to maintain backups of my personal virtual machines. That still works, though I'll probably drop the domain and use backup.steve.org.uk or similar in the future.
FWIW the external backups are hosted on BigV, which gives me a 2Tb "archive" disk for a 40 a month. Perfect.

Russ Allbery: podlators 4.00

podlators is the distribution that includes the Pod::Man and Pod::Text modules for Perl, plus the pod2man and pod2text driver scripts (among a few other, more minor things). I've been working on a new release of this for a couple of years and got trapped in a cycle of always wanting to finish up one more thing before making a release. (Really need to fix Unicode handling once and for all! Oh, I have a much better idea for how to do testing! I should really revise all of this code for my current coding style!) But some discussions elsewhere reminded me of the merits of release early and often, so I decided to finally put something out. There are quite a few accumulated changes, although not as many as the major version increase would indicate. I did that so that I could standardize on the same version number in all of the modules and switch to a much simpler versioning scheme. That required increasing the major version to something higher than all the component modules. Other than that, there are mostly a bunch of bug fixes, but also a lot of changes to Pod::Man to support Debian's reproducible build effort. The code is now more predictable and reliable about how it generates dates, and supports two new ways of forcing the date in generated documentation to a particular value so that builds are more predictable. I also changed the build system over to Module::Build, although it also provides a Makefile.PL file so that it can be built as part of Perl core. You can get the latest version from the podlators distribution page.

28 November 2015

Thorsten Glaser: FixedMisc [MirOS] for GNU GRUB2

If you install the xfonts-base package from my APT repository you now not only get the FixedMisc [MirOS] type from The MirOS Project type foundry for the X Window System, but now also for GNU GRUB2: (read more )

Next.

Previous.