On Mon, 19 Oct 2015 01:29:36 +0200 "Julian H. Stacey" <j...@berklix.com> wrote:
> > Yonas Yanfa wrote: > > Hi, > > > > It seems geli is the standard way of encrypting disks. It's extremely > > flexible and usually recommended by the community over gbde. Moreover, > > geli is mentioned a lot more in the mailing lists and forums. > > & global community uses DOS-FS more, & mentions MS more than BSD. ;-) > Popularity is not sole index of what everyone should be constrained to use. > > > > gbde's man page explicitly says that gbde is experimental and should be > > considered suspect. > > Just an old cautious initial description, that I recall long predates geli. An indicator for the fact that the documentation is not well maintained and probably the source for many confusion! Descriptions and concepts seem to have a state as when the developer issued its code/project - and then never came back maintaining documentation as the service/system/package evolves ... The main question here is: do I need to dip deeply into system's development and poke from the "nerds" informations for the usage of FreeBSD - or should someone new or more superficial consult documentation? > > > > That seems reason enough to finally depreciate and > > remove it in favour of geli. > > No, very naieve. No need to remove gbde & disrupt existing users. > Perhaps a reason to re-balance cautious description in both. Well, for avoiding disruptions and having progress there is the invention of releases and associated numbers. Sometimes it is innovative to cut of stuff in favour of progression. That is my overall opionion. Legacy releases can also be maintained. Back to the subject: The documentation of both GELI and GBDE lack in explaining why the one is better/more suitable than the other! I have just sneaked into Luca's book and he drowns both encrypting systems in a sea of words without a clear workout of the benefits. When I looked for FreeBSD's encryption, I stopped by GELI. Because of it's easy-to-use AND the 'experimental' tag in the handbook! For me, I'd like to know what is the benefit/performance of each technique and a clear preparation of each ones advantages over the other. That would make the decission process much easier and hopefully would not scare people away and announce "FreeBSD does not have a, b, c, ..." ... > > > > The Encrypting Disk Partitions page in the Handbook discusses gbde > > first, and describes geli as an alternative. This seems odd, shouldn't > > this be the other way around? > > It was written in historical order. My suggestion would be: Set atop a small section describing the benefits of each system and then dip into deeper waters later for each one. > > > > Is there any objection to removing gbde? > > Yes. Daft to disrupt users. > > > > How many people use gbde? > > Not so useful to ask on Current@ which tends to use the latest tools > eg geli; try hackers@ or questions@ etc, realise usage of BSD does > not require registration or membership of Any BSD mail list or > forum. Usage of GBDE more so. Gbde could well be essential on > production servers, but unless admins are also programmers on > current@, they won't even see your idea to remove gdbe. > > > > When > > have you used gbde over geli, and why? > > Gbde came first, some won't have needed more or wasted time to learn an > alternate they did not need. Others may have reasons they may not publish. > > Without analysis, deprecating gbde is not sensible, & removal worse. > Please research & contribute a handbook section, with URLs & text > comparing gbde & geli (& other crypt FS in ports/ ?), including eg: > > - Processor & IO load of both, > - Crack testing of both if any, > - History of code review & quality of both. etc > - Patent liabilities of either ? licensing ? > - Compatability of both with other OSs if any, > - Any possiblities for standards approvals of either by any bodies (that > usually requires funding, so with 2 maybe more chance of 1 being funded ?) > > Cheers, > Julian > -- > Julian Stacey, BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com > Reply After previous text to preserve context, as in a play script. > Indent previous text with > Insert new lines before 80 chars. > Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc. > _______________________________________________ > firstname.lastname@example.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"