musl 0.9.3 released

musl 0.9.3 released

[Rich Felker]

Hi all,

After a few days' delay, here is the next release, 0.9.3, as promised:

    New experimental MIPS port (32-bit, o32 ABI, static-linked-only at
    this point). Various dynamic linker/loader bugs fixed. Network
    service name lookup support from /etc/services. Wrappers for more
    non-POSIX Linux syscalls. Overhauled crypt() with drastic
    reductions in memory usage and run time. Fixes for several
    important thread bugs including internal lock corruption, spurious
    sem_trywait failure, and race conditions on detached-thread exit,
    as well as various minor bug fixes.

    http://www.etalabs.net/musl/releases/musl-0.9.3.tar.gz

A few pending issues that will be addressed after the release are
fixing the ARM setjmp/longjmp code not to break callers that are using
the fpu, improving memcpy (and other string functions) performance on
x86 with asm, and getting dynamic-linking support into the mips port.
I'd also like to finish and integrate the rest of rdp's porting work
(mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
x86_64) port underway, and integrate additional hash function support
(blowfish, sha, md5) for crypt.

Priority scheduling and related realtime issues are something I
haven't really touched yet, but it's also on the table for later in
the 0.9.x series.

Rich

Re: musl 0.9.3 released

[Gregor Richards]

On 08/02/2012 10:36 PM, Rich Felker wrote:
> Hi all,
>
> After a few days' delay, here is the next release, 0.9.3, as promised:
>
>      New experimental MIPS port (32-bit, o32 ABI, static-linked-only at
>      this point). Various dynamic linker/loader bugs fixed. Network
>      service name lookup support from /etc/services. Wrappers for more
>      non-POSIX Linux syscalls. Overhauled crypt() with drastic
>      reductions in memory usage and run time. Fixes for several
>      important thread bugs including internal lock corruption, spurious
>      sem_trywait failure, and race conditions on detached-thread exit,
>      as well as various minor bug fixes.
>
>      http://www.etalabs.net/musl/releases/musl-0.9.3.tar.gz
>
> A few pending issues that will be addressed after the release are
> fixing the ARM setjmp/longjmp code not to break callers that are using
> the fpu, improving memcpy (and other string functions) performance on
> x86 with asm, and getting dynamic-linking support into the mips port.
> I'd also like to finish and integrate the rest of rdp's porting work
> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
> x86_64) port underway, and integrate additional hash function support
> (blowfish, sha, md5) for crypt.
>
> Priority scheduling and related realtime issues are something I
> haven't really touched yet, but it's also on the table for later in
> the 0.9.x series.
>
> Rich

Updated cross compilers for every supported target are at 
http://bitbucket.org/GregorR/musl-cross/downloads .

With valediction,
  - Gregor Richards

Re: musl 0.9.3 released

[idunham]

> Hi all,
>
> After a few days' delay, here is the next release, 0.9.3, as promised:
>
>     New experimental MIPS port (32-bit, o32 ABI, static-linked-only at
>     this point). Various dynamic linker/loader bugs fixed. Network
>     service name lookup support from /etc/services. Wrappers for more
>     non-POSIX Linux syscalls. Overhauled crypt() with drastic
>     reductions in memory usage and run time. Fixes for several
>     important thread bugs including internal lock corruption, spurious
>     ...
Nice to see all of these!

> A few pending issues that will be addressed after the release are
> fixing the ARM setjmp/longjmp code not to break callers that are using
> the fpu, improving memcpy (and other string functions) performance on
> x86 with asm, and getting dynamic-linking support into the mips port.
> I'd also like to finish and integrate the rest of rdp's porting work
> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
> x86_64) port underway, and integrate additional hash function support
> (blowfish, sha, md5) for crypt.

All of these sound good.
I'm not sure about whether many people would be interested in x32, though?...

Something other than standard crypt (isn't that DES, which can be cracked
in a day on the right machine?) would be one of the more interesting ones
from my perspective.  Remembering the recent test results, I'd be hoping
for bcrypt as well (it's where OpenCL cracking gets the least benefit).


> Priority scheduling and related realtime issues are something I
> haven't really touched yet, but it's also on the table for later in
> the 0.9.x series.

I may be sending a patch or two to adjust io.h / io*.c as well.
(move to per-architecture, perhaps; add bits/io.h based on klibc's
sys/io.h (?) )
Also, once I figure out how syscall.list* maps to the syscall() interface
in musl, I may send a patch to support syscalls 113 & 166
(vm86(old)/vm86(plus))
*glibc and some other libc versions just have a list describing the
calling convention, name, and so on for each syscall. This somehow gets
converted to  functions.

Re: musl 0.9.3 released

[John Spencer]

On 08/05/2012 03:00 AM, idunham@lavabit.com wrote:
>
>> I'd also like to finish and integrate the rest of rdp's porting work
>> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
>> x86_64) port underway, and integrate additional hash function support
>> (blowfish, sha, md5) for crypt.
> All of these sound good.
> I'm not sure about whether many people would be interested in x32, though?...
x32 is the latest hype and a lot of work has recently been put into 
toolchain, kernel and debugger support.
this is probably a good opportunity to get the attention of early adopters.

> Something other than standard crypt (isn't that DES, which can be cracked
> in a day on the right machine?) would be one of the more interesting ones
> from my perspective.  Remembering the recent test results, I'd be hoping
> for bcrypt as well (it's where OpenCL cracking gets the least benefit).
which test results are you referring to ?

for my part, i think simple DES crypt() in the libc is sufficient.
busybox 1.20+ ships with a decent set of hash algos to use for login, so 
the libc crypt code isnt used anyway.

Re: musl 0.9.3 released

[idunham]

> On 08/05/2012 03:00 AM, idunham@lavabit.com wrote:
>>
>>> I'd also like to finish and integrate the rest of rdp's porting work
>>> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
>>> x86_64) port underway, and integrate additional hash function support
>>> (blowfish, sha, md5) for crypt.
>> All of these sound good.
>> I'm not sure about whether many people would be interested in x32,
>> though?...
> x32 is the latest hype and a lot of work has recently been put into
> toolchain, kernel and debugger support.
> this is probably a good opportunity to get the attention of early
> adopters.

Well, actually, a lot of work has recently been _finished_, so
glibc/binutils/kernel/... now have stable support.  Early adopters have
been using it for a year or few.
The adoption has been rather minimal as far as I can tell; what I meant to
ask was more if any current/potential users of musl intend to use it if
possible. In other words, if you or someone you are in commmunication with
is going to start using musl x32 for any reason besides "It happens to be
supported".

>> Something other than standard crypt (isn't that DES, which can be
>> cracked in a day on the right machine?) would be one of the more
>> interesting ones from my perspective.  Remembering the recent test
>> results, I'd be hoping for bcrypt as well (it's where OpenCL
>> cracking gets the least benefit).
> which test results are you referring to ?

best discussion:
http://openwall.info/wiki/john/GPU
http://openwall.info/wiki/john/GPU/bcrypt

There are several other articles you can find, if you look up john the
ripper gpu hash bcrypt  (or anything reasonably similar...)

> for my part, i think simple DES crypt() in the libc is sufficient.
> busybox 1.20+ ships with a decent set of hash algos to use for login, so
> the libc crypt code isnt used anyway
1. Is busybox the only login we want to support?
2. Is login (or similar) the only place crypt is used?
3. Do we want to rely on the busybox internal code?
4. This is "If you plan to add hashes (which Rich has stated
that he hopes to do, in the original post), please consider
making bcrypt one of them."

Isaac Dunham

Re: musl 0.9.3 released

[Rich Felker]

On Sun, Aug 05, 2012 at 12:56:24AM -0400, idunham@lavabit.com wrote:
> > On 08/05/2012 03:00 AM, idunham@lavabit.com wrote:
> >>
> >>> I'd also like to finish and integrate the rest of rdp's porting work
> >>> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
> >>> x86_64) port underway, and integrate additional hash function support
> >>> (blowfish, sha, md5) for crypt.
> >> All of these sound good.
> >> I'm not sure about whether many people would be interested in x32,
> >> though?...
> > x32 is the latest hype and a lot of work has recently been put into
> > toolchain, kernel and debugger support.
> > this is probably a good opportunity to get the attention of early
> > adopters.
> 
> Well, actually, a lot of work has recently been _finished_, so
> glibc/binutils/kernel/... now have stable support.  Early adopters have
> been using it for a year or few.
> The adoption has been rather minimal as far as I can tell; what I meant to
> ask was more if any current/potential users of musl intend to use it if
> possible. In other words, if you or someone you are in commmunication with
> is going to start using musl x32 for any reason besides "It happens to be
> supported".

If I were going to switch to x86_64 cpu, which I will probably do in
the next few years, x32 would certainly be appealing. Not decided for
sure, but it seems very nice to get all the important benefits of a
64-bit cpu with none of the bloat. I think this sounds appealing to
a big part of musl's target userbase too...

> >> Something other than standard crypt (isn't that DES, which can be
> >> cracked in a day on the right machine?) would be one of the more
> >> interesting ones from my perspective.  Remembering the recent test
> >> results, I'd be hoping for bcrypt as well (it's where OpenCL
> >> cracking gets the least benefit).
> > which test results are you referring to ?
> 
> best discussion:
> http://openwall.info/wiki/john/GPU
> http://openwall.info/wiki/john/GPU/bcrypt
> 
> There are several other articles you can find, if you look up john the
> ripper gpu hash bcrypt  (or anything reasonably similar...)
> 
> > for my part, i think simple DES crypt() in the libc is sufficient.
> > busybox 1.20+ ships with a decent set of hash algos to use for login, so
> > the libc crypt code isnt used anyway
> 1. Is busybox the only login we want to support?

No, and in fact login is utterly useless. It never gets used unless
you're logging in at the physical console, or with some horribly
insecure legacy protocol like telnet...

> 2. Is login (or similar) the only place crypt is used?

No, sshd is the main place it's used.

> 3. Do we want to rely on the busybox internal code?
> 4. This is "If you plan to add hashes (which Rich has stated
> that he hopes to do, in the original post), please consider
> making bcrypt one of them."

How bloated is it? Sadly crypto folks seem to love giant bloated
tables...

Rich

x32 (was: Re: [musl] musl 0.9.3 released)

[John Spencer]

On 08/05/2012 06:56 AM, idunham@lavabit.com wrote:
>> On 08/05/2012 03:00 AM, idunham@lavabit.com wrote:
>>>
>>> All of these sound good.
>>> I'm not sure about whether many people would be interested in x32,
>>> though?...
>> x32 is the latest hype and a lot of work has recently been put into
>> toolchain, kernel and debugger support.
>> this is probably a good opportunity to get the attention of early
>> adopters.
> Well, actually, a lot of work has recently been _finished_, so
> glibc/binutils/kernel/... now have stable support.  Early adopters have
> been using it for a year or few.
untrue, gcc 4.7 which was released a couple weeks ago and the upcoming 
gdb 7.5 are the first to support x32.
the kernel supports it since a few months.
this is all brand-new, and definitely not "stable" yet.
i haven't yet seen a x32 distro yet, so anybody using it already lives 
on bleeding edge.

Re: x32 (was: Re: [musl] musl 0.9.3 released)

[Daniel Cegiełka]

2012/8/5 John Spencer <maillist-musl@barfooze.de>:
>
> untrue, gcc 4.7 which was released a couple weeks ago and the upcoming gdb
> 7.5 are the first to support x32.
> the kernel supports it since a few months.
> this is all brand-new, and definitely not "stable" yet.

> i haven't yet seen a x32 distro yet, so anybody using it already lives on
> bleeding edge.

http://www.gentoo.org/news/20120608-x32_abi.xml

regards,
daniel

Re: x32 (was: Re: [musl] musl 0.9.3 released)

[Kurt H Maier]

On Sun, Aug 05, 2012 at 02:46:08PM +0200, Daniel Cegiełka wrote:
> http://www.gentoo.org/news/20120608-x32_abi.xml

I wouldn't exactly call that a release.

Re: x32 (was: Re: [musl] musl 0.9.3 released)

[Daniel Cegiełka]

interesting thoughts...

http://blog.flameeyes.eu/2012/07/what-could-have-been-a-time-travel-story-of-x32-and-fatelf


2012/8/5 Kurt H Maier <khm-lists@intma.in>:
> On Sun, Aug 05, 2012 at 02:46:08PM +0200, Daniel Cegiełka wrote:
>> http://www.gentoo.org/news/20120608-x32_abi.xml
>
> I wouldn't exactly call that a release.

Re: x32

[Anthony G. Basile]

On 08/05/2012 08:58 AM, Kurt H Maier wrote:
> On Sun, Aug 05, 2012 at 02:46:08PM +0200, Daniel Cegiełka wrote:
>> http://www.gentoo.org/news/20120608-x32_abi.xml
>
> I wouldn't exactly call that a release.

We are no where near implementing x32 in gentoo.  I would not get too 
excited about it.

Off topic, I just started playing with building a minimal gentoo system 
around musl.  The gcc wrapper + spec file approach makes it easy to 
cross compile a system.  I am hitting issues, so except bug reports :P

The overlay is here ->

http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=tree;h=ba9a6a92bffa7f0950b6b9f1eab262f7ec16c72e;hb=ba9a6a92bffa7f0950b6b9f1eab262f7ec16c72e

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: x32

[Anthony G. Basile]

On 08/05/2012 09:15 AM, Daniel Cegiełka wrote:
> interesting thoughts...
>
> http://blog.flameeyes.eu/2012/07/what-could-have-been-a-time-travel-story-of-x32-and-fatelf
>
>
> 2012/8/5 Kurt H Maier<khm-lists@intma.in>:
>> On Sun, Aug 05, 2012 at 02:46:08PM +0200, Daniel Cegiełka wrote:
>>> http://www.gentoo.org/news/20120608-x32_abi.xml
>>
>> I wouldn't exactly call that a release.

Sorry guys, hope this isn't a dup.  I forgot that I didn't use my 
@gentoo.org email to subscribe to this list.  Here's my first post:

We are no where near implementing x32 in gentoo.  I would not get too 
excited about it.

Off topic, I just started playing with building a minimal gentoo system 
around musl.  The gcc wrapper + spec file approach makes it easy to 
cross compile a system.  I am hitting issues, so except bug reports :P

The overlay is here ->

http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=tree;h=ba9a6a92bffa7f0950b6b9f1eab262f7ec16c72e;hb=ba9a6a92bffa7f0950b6b9f1eab262f7ec16c72e


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: x32

[Daniel Cegiełka]

> Off topic, I just started playing with building a minimal gentoo system
> around musl.  The gcc wrapper + spec file approach makes it easy to cross
> compile a system.  I am hitting issues, so except bug reports :P

-D_GNU_SOURCE -D_BSD_SOURCE helps a lot! :)

I've a lot of problems especially with net stuff (try to compile
ethtools) and with pam*/shadow... grep (regex.h)...

best regards,
Daniel

Re: musl 0.9.3 released

[orc]

On Sun, 5 Aug 2012 01:22:20 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> If I were going to switch to x86_64 cpu, which I will probably do in
> the next few years, x32 would certainly be appealing. Not decided for
> sure, but it seems very nice to get all the important benefits of a
> 64-bit cpu with none of the bloat.

Somewhat bloated, but not so much. Often I see only that massive apps
like web browsers eat much of RAM usually. 2G usually enough for me to
run 3-4 qemu-kvm's and bloated Firefox 12 (eats about 700M usually,
critical was 1G and 100M swap, 1 month of it's uptime). Now I use 4G
(additional 2G is for tmpfs. I like to store large blobs in /tmp often).
I use x86_64 for 3 years without any problems. If Firefox (or any
application of same class, chromium probably) will continue to grow,
then five or seven years will be enough to make x32 be obsoleted
(compared with ff3, it's maximum memusage was 300M, and for 3.6 it was
400M).




(someone can note that 2G is too overkill, but I don't care)

Re: musl 0.9.3 released

[orc]

On Mon, 6 Aug 2012 00:31:12 +0800
orc <orc@sibserver.ru> wrote:

> On Sun, 5 Aug 2012 01:22:20 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > If I were going to switch to x86_64 cpu, which I will probably do in
> > the next few years, x32 would certainly be appealing. Not decided
> > for sure, but it seems very nice to get all the important benefits
> > of a 64-bit cpu with none of the bloat.
> 
> Somewhat bloated, but not so much. Often I see only that massive apps
> like web browsers eat much of RAM usually. 2G usually enough for me to
> run 3-4 qemu-kvm's and bloated Firefox 12 (eats about 700M usually,
> critical was 1G and 100M swap, 1 month of it's uptime). Now I use 4G
> (additional 2G is for tmpfs. I like to store large blobs in /tmp
> often). I use x86_64 for 3 years without any problems. If Firefox (or
> any application of same class, chromium probably) will continue to
> grow, then five or seven years will be enough to make x32 be obsoleted
> (compared with ff3, it's maximum memusage was 300M, and for 3.6 it was
> 400M).
> 
> 
> 
> 
> (someone can note that 2G is too overkill, but I don't care)

Also, does x32 run on plain x86_64? If it does, then probably that
large apps like Firefox can be compiled and run in that mode can have
benefits. If it is required that you must run only x32 kernel, then I
see no it's benefits currently. It will be much easier to run plain 32
bits Firefox.

Re: musl 0.9.3 released

[Rich Felker]

On Mon, Aug 06, 2012 at 12:31:12AM +0800, orc wrote:
> On Sun, 5 Aug 2012 01:22:20 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > If I were going to switch to x86_64 cpu, which I will probably do in
> > the next few years, x32 would certainly be appealing. Not decided for
> > sure, but it seems very nice to get all the important benefits of a
> > 64-bit cpu with none of the bloat.
> 
> Somewhat bloated, but not so much. Often I see only that massive apps
> like web browsers eat much of RAM usually. 2G usually enough for me to
> run 3-4 qemu-kvm's and bloated Firefox 12 (eats about 700M usually,
> critical was 1G and 100M swap, 1 month of it's uptime). Now I use 4G
> (additional 2G is for tmpfs. I like to store large blobs in /tmp often).
> I use x86_64 for 3 years without any problems. If Firefox (or any
> application of same class, chromium probably) will continue to grow,
> then five or seven years will be enough to make x32 be obsoleted
> (compared with ff3, it's maximum memusage was 300M, and for 3.6 it was
> 400M).

Assuming the market is shifting to battery-powered mobile devices
possibly intended to run for days or even weeks without charging, I
think we're going to start seeing some more efficient apps. I don't
doubt the old behemoths will still be around for a while, but musl is
developed with the assumption/intention that efficiency is going to be
one of the important design criteria for future software. If we were
happy with the level of bloat you're describing above, I think lots of
people in this community would just forget about musl and use glibc...

Rich

Re: musl 0.9.3 released

[Daniel Cegiełka]

2012/8/5 orc <orc@sibserver.ru>:
> On Mon, 6 Aug 2012 00:31:12 +0800
> orc <orc@sibserver.ru> wrote:
>
> Also, does x32 run on plain x86_64?

This is similar to the multilib mode (lib64 + libx32 etc.).

> If it does, then probably that
> large apps like Firefox can be compiled and run in that mode can have
> benefits. If it is required that you must run only x32 kernel, then I
> see no it's benefits currently. It will be much easier to run plain 32
> bits Firefox.

Re: musl 0.9.3 released

[orc]

On Sun, 5 Aug 2012 12:46:52 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Mon, Aug 06, 2012 at 12:31:12AM +0800, orc wrote:
> > On Sun, 5 Aug 2012 01:22:20 -0400
> > Rich Felker <dalias@aerifal.cx> wrote:
> > 
> > > If I were going to switch to x86_64 cpu, which I will probably do
> > > in the next few years, x32 would certainly be appealing. Not
> > > decided for sure, but it seems very nice to get all the important
> > > benefits of a 64-bit cpu with none of the bloat.
> > 
> > Somewhat bloated, but not so much. Often I see only that massive
> > apps like web browsers eat much of RAM usually. 2G usually enough
> > for me to run 3-4 qemu-kvm's and bloated Firefox 12 (eats about
> > 700M usually, critical was 1G and 100M swap, 1 month of it's
> > uptime). Now I use 4G (additional 2G is for tmpfs. I like to store
> > large blobs in /tmp often). I use x86_64 for 3 years without any
> > problems. If Firefox (or any application of same class, chromium
> > probably) will continue to grow, then five or seven years will be
> > enough to make x32 be obsoleted (compared with ff3, it's maximum
> > memusage was 300M, and for 3.6 it was 400M).
> 
> Assuming the market is shifting to battery-powered mobile devices
> possibly intended to run for days or even weeks without charging, I
> think we're going to start seeing some more efficient apps. I don't
> doubt the old behemoths will still be around for a while, but musl is
> developed with the assumption/intention that efficiency is going to be
> one of the important design criteria for future software. If we were
> happy with the level of bloat you're describing above, I think lots of
> people in this community would just forget about musl and use glibc...

I agree with you here. I hope that shift will force appmakers to
make their software much more better and efficient.

> 
> Rich

Re: musl 0.9.3 released

[Rich Felker]

On Mon, Aug 06, 2012 at 12:43:36AM +0800, orc wrote:
> Also, does x32 run on plain x86_64? If it does, then probably that

It's a separate ABI in userspace (and has some new syscalls for
situations where it's necessary to interface with the kernel using a
structure that looks different in userspace due to containing
pointers), but it runs on a standard 64-bit kernel that's new enough
to have x32 support.

It's possible to mix x32 and normal x86_64 ABI binaries on the same
system, but for dynamic linking they need their own separate library
paths.

> large apps like Firefox can be compiled and run in that mode can have
> benefits. If it is required that you must run only x32 kernel, then I
> see no it's benefits currently. It will be much easier to run plain 32
> bits Firefox.

Plain 32-bit apps are moderately slower due to not having access to
64-bit arithmetic and the really inefficient i386 ABI. I've heard the
difference can be 5-20% depending on the application.

Rich

Re: musl 0.9.3 released

[Isaac Dunham]

On Sun, 5 Aug 2012 01:22:20 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Aug 05, 2012 at 12:56:24AM -0400, idunham@lavabit.com wrote:
> > > On 08/05/2012 03:00 AM, idunham@lavabit.com wrote:
> > >>
> > >>> I'd also like to finish and integrate the rest of rdp's porting
> > >>> work (mips64, ppc, and microblaze) and possibly get an x32
> > >>> (32-bit ABI on x86_64) port underway, and integrate additional
> > >>> hash function support (blowfish, sha, md5) for crypt.
> > >> All of these sound good.
> > ...In other words, if you or someone you are in
> > commmunication with is going to start using musl x32 for any reason
> > besides "It happens to be supported".
> 
> If I were going to switch to x86_64 cpu, which I will probably do in
> the next few years, x32 would certainly be appealing. Not decided for
> sure, but it seems very nice to get all the important benefits of a
> 64-bit cpu with none of the bloat. I think this sounds appealing to
> a big part of musl's target userbase too...

OK, that's what I was asking.


> > >> Something other than standard crypt (isn't that DES, which can be
> > >> cracked in a day on the right machine?) would be one of the more
> > >> interesting ones from my perspective.  Remembering the recent
> > >> test results, I'd be hoping for bcrypt as well (it's where OpenCL
> > >> cracking gets the least benefit).
> > > which test results are you referring to ?
> > 
> > best discussion:
> > http://openwall.info/wiki/john/GPU
> > http://openwall.info/wiki/john/GPU/bcrypt
<snip>

> > 4. This is "If you plan to add hashes (which Rich has stated
> > that he hopes to do, in the original post), please consider
> > making bcrypt one of them."
> 
> How bloated is it? Sadly crypto folks seem to love giant bloated
> tables...
Well, now that I look it up, bcrypt() is blowfish crypt() (at least,
it's the primary blowfish-based crypt()--it does have a few
peculiarities of its own)
It is somewhat expensive in terms of resources, per the results
mentioned.