Hi, On 13/05/2013 17:42, intrigeri wrote: > Hi, > > [email protected] 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
