Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel

[Andy Lutomirski <luto@amacapital.net>]

On Tue, May 13, 2014 at 8:52 AM, Levente Kurusa <levex@linux.com> wrote:
> Hi,
>
> On Tue, May 13, 2014 at 12:08:51AM -0700, Josh Triplett wrote:
>> On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
>> > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> > > I'd like the URL to be valid (meaning base64 the compressed data) so
>> > > that we can get the data to the kernel.org server as easily as possible.
>> > > Making the app a requirement for reporting is too onerous for
>> > > non-developers.  I see no reason we can't link to (Open in/Install) it
>> > > on the webform though.
>> >
>> > So from what I can understand, the QR code has an URL that has the
>> > base64 of the compressed Oops message. Right? I see three problems
>> > with this approach:
>> >
>> > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
>> > characters + padding). One issue with QR codes is that they have a
>> > limited amount of characters they can hold so that's why I do the
>> > compression in the first place
>>
>> Putting base64-encoded data in a URL in a binary-format QR code with 8
>> bits per character does indeed waste quite a bit of space.  However, you
>> could put base32-encoded data into an alphanumeric-formatted QR code
>> with 5.5 bits per character, which would waste very little space.  (Or,
>> more efficiently but less conveniently, base40 or so.)
>>
>
> Base32 does sound good until you realize that it requires roughly 20%
> more space than Base64 does. We would need some calculations to
> decide if we were to go down this path.

I think the idea is that base32 requires 20% more *characters* than
base64, but it also enables the use of alphanumeric QR codes, which
can store more characters for the same number of pixels.

--Andy