Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

I wrote 15 months ago
thanking
Canonical for their release of Launchpad. However, in the interim,
a part of the necessary codebase was made proprietary, namely the
authentication system used in the canonical instance of Launchpad hosted
by Canonical. (Yes, I still insist on using canonical in the canonical
way despite the company name making it confusing. :).
I added this fact to
my list of reasons of abandoning Ubuntu and other Canonical
products.

Fortunately, I’ve now removed this reason from the list of reasons I
switched back to Debian from Ubuntu,
since Jono
Bacon announced release of this code today. According
to Jono, this release means that Launchpad and its
dependencies are again fully Free Software. This is a step forward.
And, I did promise many people at Canonical that I’d make a point about
thanking them for doing Free Software releases when they do them, since
I do make a point of calling them out about negative things they do.

Like any mixed proprietary/Free Software company, there is tons more to
be released. I remain most concerned about UbuntuOne’s server side
code, but I very much hope this release today marks a bounce-back for
Canonical to its roots in the 100% Free Software world.

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

Launchpad Single Sign On Released

2010-04-21 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/21/canonical-sign-on.html

A Few Notes on Bloom Filters

2010-04-20 Lennart Poettering

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/bloom.html

For future reference (mostly for myself), here’s a little summary of how to
use Bloom filters in
real world applications.

Most references are terse and vague on how to pick the hash functions for
bloom filters, so here’s some detail about that: For small filters, just use a
boring and fast hash function like the djb hash
function and split up the 32bit result into smaller independent chunks for
each of the k hash indexes you’ll need. Often those 32 bits already provide
enough hash bits to get enough independent bloom filter indexes. And if they
don’t you basically have three options:

Use multiple different hash functions, and then MurmurHash seems to be a
very good choice. It’s simple, readily usable code (even in C, though the
reference implementation claims to be C++), and properly licensed. It is a hash
function that takes a seed parameter which can be used to create as many
independent hash functions as needed.
Use a cryptographic hash function. Most of them can be implemented really
fast on modern CPUs and are already available in some library you use anyway.
SHA512 for example outputs plenty bits you can split into k chunks as you need
them for your k bloom filter indexes. (Of course, if you are afraid of US
export regulations this might be a choice you want to avoid.)
Use two independent hash functions and combine them
linearly.

The size of the bloom filter and the number of hash functions you should be
using depending on your application can be calculated using the formulas on the
Wikipedia page:

m = -n*ln(p)/(ln(2)^2)

This will tell you the number of bits m to use for your filter, given the
number n of elements in your filter and the false positive probability p you
want to achieve. All that for the ideal number of hash functions k which you
can calculate like this:

k = 0.7*m/n

And that’s already everything you need to know to build good bloom filters.
If you know the p and n for your use case the above will tell you the m and k, and
how to choose the k hash functions.

Bloom filters are a really really useful tool, and given their simplicity
something every developer should be aware of.

(And in case you were wondering what this all is about, Kay Sievers and I
were discussing using bloom filters in the libudev netlink BSD socket filters,
to allow monitoring a certain subset of devices that is orthogonal to the usual
subsystem hierarchy, and all that in a way where the number of wakeups in
listening clients is minimized)

Human Women

2010-04-18 Oglaf! -- Comics. Often dirty.

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/human-women/

emancipation

2010-04-11 Oglaf! -- Comics. Often dirty.

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/emancipation/

Proprietary Licenses Are Even Worse Than They Look

2010-04-07 Bradley M. Kuhn

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/04/07/proprietary-licenses.html

There are lots of evil things that proprietary software companies might
do. Companies put their own profit above the rights and freedoms of
their users, and to that end, much can be done that subjugates
users. Even as someone who avoids proprietary software, I still read
many proprietary license agreements (mainly to see how bad they are).
I’ve certainly become numb to the constant barrage of horrible
restrictions they place on users. But, sometimes, proprietary licenses
go so far that I’m taken aback by their gratuitous cruelty.

Apple’s licenses are probably the easiest example of proprietary
licensing terms that are well beyond reasonableness. Of course, Apple’s
licenses do the usual things like forbidding users from copying,
modifying, sharing, and reverse engineering the software. But even
worse, Apple also forbid users from running Apple software on any
hardware that is not produced by Apple.

The decoupling of one’s hardware vendor from one’s software vendor was
a great innovation brought about by the PC revolution, in which,
ironically, Apple played a role. Computing history has shown us that when
your software vendor also controls your hardware, you can easily be
“locked in“ in ways that make mundane proprietary software
licenses seem almost nonthreatening.

Film image from Tron of the Master Control Program (MCP)

Indeed, Apple has such a good hype machine that
they even
have convinced some users this restrictive policy makes computing
better. In this worldview, the paternalistic vendor will use its
proprietary controls over as many pieces of the technology as possible
to keep the infantile users from doing something that’s “just bad
for them”. The tyrannical
MCP
of Tron comes quickly to my mind.

I’m amazed that so many otherwise Free Software supporters are quite
happy using OSX and buying Apple products, given these kinds of utterly
unacceptable policies. The scariest part, though, is that this practice
isn’t confined to Apple. I’ve been recently reminded that other
companies, such
as IBM, do exactly the same thing. As a Free Software advocate, I’m
critical of any company that uses their control of a proprietary
software license to demand that users run that software only on the
original company’s hardware as well. The production and distribution of
mundane proprietary software is bad enough. It’s unfortunate that
companies like Apple and IBM are going the extra mile to treat users
even worse.