[Freedombox-discuss] Intel Compute Stick

[Jonas Smedegaard]

Quoting Sunil Mohan Adapa (2015-01-14 06:25:17)
> On Wednesday 14 January 2015 03:42 AM, Jonas Smedegaard wrote:
>> Quoting Sunil Mohan Adapa (2015-01-13 21:05:38)
>>> On Wednesday 14 January 2015 01:08 AM, Blibbet wrote:
>>>> To me it is unsuitable for a FreedomBox due to firmware, which is 
>>>> probably UEFI-based if hardware comes from Intel.
>>>
>>> Indeed, proprietary firmware is a deal breaker.
>> 
>> You mean UEFI specifically, or that *any* use of proprietary firmware 
>> is a deal breaker?
>
> I meant any proprietary firmware including WiFi firmware needed for 
> most single board computers with WiFi capability (by relying USB WiFi 
> devices).
>
>> Makes sense to me to steer free of proprietary code whereever 
>> possible, and we have enough options not requiring proprietary 
>> firmware injected at boot time, but I think it is too early to set 
>> the bar so high as to require no proprietary firmware exist soldered 
>> onto the board.
>
> If the proprietary firmware is not executed (or can be disabled), say 
> for an optional hardware component, then I guess we can live with it.
>
> I do agree that it might be too early though.  We can confirm a few 
> free working options and then look at this direction.
>
>> 
>> If you mean only UEFI, then why avoid that specifically? Yes, I know 
>> that Free firmware like Coreboot is better when offered (which is not 
>> the case currently), but how is e.g. proprietary BIOS better?
>>
>>
>>> We should consider promising FreedomBox users images and devices 
>>> with only free software and firmware.  Especially since we do seem 
>>> to have some viable hardware options.  In the last meeting everyone 
>>> seem to agree that we should remove non-free repositories from 
>>> FreedomBox images wherever possible.  This would be a step further.
>>
>> What do you mean by "whereever possible" in above?  Is non-free 
>> Debian repositories less of a deal breaker than UEFI or other 
>> pre-loaded proprietary firmware?  If so, why?
>
> We are currently using non-free repositories for all FreedomBox 
> images, even VirtualBox images.  We only had a brief discussion but 
> from what I understand the agreement was to remove non-free 
> repositories from images where it is not needed, such as from 
> VirtualBox and BeagleBone images. There was no discussion on what to 
> do about hardware that requires non-free software.
>
> In my opinion, pre-loaded proprietary firmware is as bad as non-free 
> Debian repositories particularly if that firmware is replaceable.
>
>> ****
>> 
>> 60 boards now for sale arguably match or surpass the DreamPlug.  
>> Makes sense to me to raise the bar higher, but not arbitrarily.
>> 
>> We could add a requirement that the board must not use UEFI (if that 
>> is sensible - see my question above).  That would still leave is with 
>> 55 options.
>
> I believe we should consider generalizing this for any non-free 
> firmware.  The idea is that all software and firmware on FreedomBox 
> shall be free.  If we do this (and pull off a nicely working 
> FreedomBox), many of our users will appreciate the fully freely 
> aspect.
>  It will become a strong point for FreedomBox adoption.

I agree with that - further down the road.  Seems you agree with me that 
it is not realistic to be strict about *now*.


>> We could add a requirement that the board must be Open Hardware.  
>> That would leave us with 12 options from 3 vendors.
>
> I don't think we should do this.  At least, not yet.  We should 
> certainly prioritize Open Hardware though.

So essentially, in your opinion, we should not raise the bar now?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20150114/f5bb7f45/attachment.sig>