[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140418210038.GN26358@brightrain.aerifal.cx>
Date: Fri, 18 Apr 2014 17:00:38 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: New domain!
On Thu, Apr 17, 2014 at 09:36:54AM +0100, Laurent Bercot wrote:
> On 17/04/2014 05:18, Rich Felker wrote:
>
> >I agree, but that takes a little bit of work transitioning links and
> >getting search engines to recognize the move, and it's been a long
> >time since I've done such a move so I have to figure out how it works
> >again.
>
> Transitioning links is a perl one-liner, and putting in a redirection
> should also be a one-liner in the web server configuration.
I meant links from other third-party sites and especially getting
search engines to return the new canonical site. If you do it wrong,
you'll drop in the search results; right now we're #2 for musl which
is pretty good considering #1 is musl.com and #3 is musl.net. BTW
having libc.org might eventually put musl at #1 for "libc"; right now
we're #7. :)
> >So I'm leaning towards an approach that uses them in conjunction with
> >musl.libc.org being the musl site and libc.org being something that's
> >not misrepresented as fully independent of musl, but that's also more
> >general.
>
> That sounds like the best way to go about it.
That seems to be the general consensus so far.
> >For the revamp though I think it would be nice to put some more effort
> >into reducing bias in the choice of what to compare. I'm not sure if
> >it would make sense to ask glibc and/or uclibc to suggest additions
> >but that would at least be one thought for how to do it.
>
> It would at least make sense to ask. If only to read the hilarious
> subsequent bikeshedding discussion on the glibc mailing-list. :)
OK. A couple ideas for things to add that come to mind:
- Compatibility with major proprietary dynamic-linked software (glibc
full, musl partial, others none)
- Sizes with minimal configuration (would show how small you can get
uclibc if you cripple it as much as possible)
- Time to compile (probably reflects most positively on musl)
- Time to compile a given medium-size app against the libc (measures
header bloat cost) but it's hard to factor out toolchain differences
that might not be caused by libc, and even harder if you also want
to measure configure time
> >You're the second to request this. It depends on some mail server
> >setup and thinking through which systems should be responsible for
> >having mail going thru them, but it's something I hope to add before
> >too long.
>
> I wasn't thinking about mail hosting, but only about mail aliases.
> I can help with that too (definitely aliases, and even hosting to some
> extent).
Well the current setup has the mx going to a system that's not setup
for forwarding mail back out at all (only local delivery). I would
probably move it to the musl vps to add more features, so hosting
isn't so much of a problem, but setup is. Securing a mail system that
can end up sending outgoing mail is a big deal and really sucks if you
get it wrong (spam liability).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
