Hi,
On 13/05/2013 17:42, intrigeri wrote:
> Hi,
>
> quidame@??? wrote (13 May 2013 00:57:02 GMT) :
>> Could you try the new version (0.4.11~quidame), please ?
>
> Thanks a lot for your prompt response!
>
> I've tried it, and it works fine for me (and makes "the boot device
> has safe access rights" test pass), so I've merged our feature/bilibop
> branch into the experimental one.
>
> I'd like to fix this bug for 0.18.1 or 0.19.
>
> So, the question now is: do we want to use bilibop to fix this serious
> bug, or develop and maintain a in-house solution?
>
> A. bilibop
>
> pros:
> - already works in a way that I'd be happy to ship in our next
> stable release
> - we don't have tomaintain it: quidame does
> - it supports more hardware / boot media / installation modes
> than we'll ever do ourselves
>
> cons:
> - we (well, I) have to sponsor it in Debian
> - quite a lot of code for something that may look simple
Maybe the last con is the price of the last pro...
> B. home-made solution
>
> pros:
> - less code
>
> cons:
> - the code is not finished (yet)
> - we have to maintain it ourselves
> - only supports the hardware / boot media / installation modes
> that we explicitly add support for
>
> I do prefer to go with plan A.
> What do others think?
>
> quidame, would you be happy to commit to make bilibop-udev support the
> Tails usecase on the long term? (that is, Debian stable + live-build +
> live-boot, GPT, DVD or USB / sd-card, etc.)
Yeah, why not ?
In itself, bilibop-udev is a poor thing, and is not intended to do
anything when running from optical media; but if needed it can, of
course, as long as bilibop-common has support for that; and really, this
shell library doesn't care of GPT or MBR partition tables, DVD or USB
boot media, and so on; it is written to find the physical boot device in
a wide range of situations, that's all.
After what, other bilibop packages perform more or less specific actions
to protect the content of this device from root or user mistakes.
bilibop-udev can protect the whole disk and its partitions from a basic
user mistake when she plays with dd or shred. I don't plan to modify its
core design. But improvements and options based on Tails specifications
could be added. It is even possible to build a specific 'bilibop-live'
package with best integration with live-build and live-boot, detection
of the boot media type (optical, HDD, flash memory), etc. This would let
bilibop-udev as minimal as possible (and usable on non-live systems
running from external media).
So, yes, I would be happy. I don't know what you mean when you say 'on
the long term', but the first draft of the bilibop project was written
five years ago, and I think I will use it in a daily basis for the rest
of my life. Is it enough ?-)
>> If it works as you expect and you plan to ship it with the next
>> release of Tails, you should probably try to base some of your
>> custom scripts on the bilibop shell library (just play with
>> /lib/bilibop/disk and see).
>
>> Tips:
>> - if the symlink /dev/bilibop exists, it means the system is running
>> from a writable media (USB, MMC and the like, but not DVD);
>> - if you don't like 'bilibop' but prefer 'Tails' or 'bootdev', just
>> set up BILIBOP_COMMON_BASENAME to the value of your choice in
>> /etc/bilibop/bilibop.conf
>
> Nice goodies, thanks! This will be useful for the incremental updates
> feature too.
Cheers,
quidame
