Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crête wrote: > Hi, > > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: > > I have been working with robbat2 on solutions to the separate /usr > > issue (That is why I have specifically cc'd him on this email) > > which will allow people to not use an initramfs. If we migrate > > everything off of the root fs to /usr, all of those solutions become > > moot. On the other hand, if we don't migrate, we run the risk of > > eventually having our default configuration not supported by > > upstream. > > I think the general consensus among other distros is that initramfs is > the new /. Many core elements of the Linux system will start > installing themselves in /usr, starting with udev, so we won't have a > choice anyway. Also, I doubt it's currently possible to boot a Gentoo > system without /usr mounted anyway. > > > 1) Start migrating packages along with upstream and have everyone > > who has a separate /usr (including me by the way) start using an > > initramfs of some kind, either dracut or one that we generate > > specifically for gentoo. The reason I suggest the initramfs, is, > > unfortunately if we migrate everything, nothing else would work. > > I also don't see a good reason to not adopt dracut, re-implementing > something that already works and is maintained by a competent upstream > seems wasteful to me. I really don't see why people resist using an > initramfs so much. > > The udev/kmod/systemd/dracut effort to standardise the base userspace > of Linux is probably scary for quite a few Gentoo-ers as it means > that the end result of an installed Gentoo system will be less > differentiated than it was before. But it still is a step in the > right direction as most of these standardized pieces are much better > than what we currently have. The OpenRC/baselayout-2 fiasco, not much > better than baselayout-1 and unmaintained upstream shows that even a > relatively large distribution like us can't maintain a competitive > base system solution, adopting the udev/kmod/systemd way will allow > us to use all the work that they are doing and instead concentrate on > making a better system. > All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 06 Jan 2012 19:59:45 -0500 Olivier Crête wrote: > On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote: > > On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote > > > > > No no no, the idea is that once all binaries are in /usr, you can > > > easily share /usr between different systems and do updates in a > > > sane way.. You can also mount /usr read-only, but still have / be > > > read-write. > > > > One size does not fit all. It breaks Gentoo horribly. Here's my > > setup > > > > waltdnes@d530 / $ du -s /usr > > 3057917 usr > > > > waltdnes@d530 /usr $ du -s /usr/portage > > 1394646 /usr/portage > > > > waltdnes@d530 /usr $ du -s /usr/src > > 665069 /usr/src > > > > In my 3 gig /usr directory, over 2 gigs are devoted to > > Gentoo-specific stuff that a binary distro like Redhat does not > > require. What do we do if /usr is read-only? Symlink or bindmount > > onto it? > > You don't understand the purpose of read-only /usr. It has nothing to > do with source vs binary. It is for when you have many machines that > are identical or at least similar. > > The idea is that you can mount the same /usr on many machines (using > NFS or something like that). So you can have a relatively small / as > a r/w nfsroot (containing /etc, /var, /tmp, etc, etc), and then > share /usr among all the machines in your cluster or machine room or > your many user desktops. > > With the current system, you either have to maintain in sync > the /bin, /sbin, /usr, etc separately, making life harder for > everyone. > > But clearly, you've never been the sysadmin of that kind of setup. > Not saying it's just you, but people should stop being dicks. Being antagonistic against everyone is not getting us anywhere and only serves to divide the community. People shouldn't use the hate in dealing with whether or not to change on other people, use it on the actual argument :D -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 18:03:50 +0100 Michał Górny wrote: > On Wed, 11 Jan 2012 09:44:31 +0100 > Ulrich Mueller wrote: > > > >>>>> On Wed, 11 Jan 2012, Michał Górny wrote: > > > > >> I think it is more like people do that when they have a good > > >> reason to do so. I plan to put mine on /usr when I get the > > >> chance and know that this init crap isn't going to break my > > >> rig. It's not being "awesome" either. > > > > > Remind me of a single good reason. Last time I heard those were > > > mostly hacks and laziness. > > > > /usr can be mounted readonly, while / and /var cannot? > > What is the point of mounting the less important part of the system > read-only while the more important one is writable? > > Also, it should be possible to mount rootfs read-only with > separate /var. Of course, that would require the software to be > actually FHS-compliant and not put runtime-written files in /etc. > security? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
On Tue, 31 Jan 2012 19:58:32 -0500
"Anthony G. Basile" wrote:
> On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> >> I've run nbench on two amd64 systems both running the same kernel
> >> vanilla-3.2.2.
> > i don't think nbench is a good benchmark for this as it isn't
> > really testing what you think it's testing. it's very good at
> > validating math support in the ISA/ABI, optimized compiler output,
> > and supplementary math implementations in libgcc. PIE vs non-PIE
> > will still be able to multiply/divide in pretty much the same
> > amount of time.
>
> I know, but the problem is, what benchmark best approximates common
> every day use? So I wrote the following which really hits the
> problem hard on x86:
>
> int modfac(int n)
> {
> if(n==0) return 1;
> return n * modfac(n-1);
> }
>
> int main()
> {
> int i;
> for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
> return 0;
> }
>
> Using vanilla kernel 3.2.2, userland built with vanilla toolchain,
> gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code
> simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get:
>
> time -p ./test
> real 327.89
> user 327.72
> sys 0.00
>
> Keep everything else the same, even the same hardware, but switch to
> userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus
> error), I get:
>
> time -p ./test
> real 629.68
> user 629.37
> sys 0.00
>
> The hardware is 8 x "Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz" with 12
> GB ram. That's nearly a factor of 2x but how often does one set up
> 4k stack frames in everyday use?
>
> >> So at least on amd64, I don't think that performance is ever an
> >> issue.
> > yes, most likely on systems where the PIC has hardware support in
> > the ISA, the performance hit on PIE is typically low.
> >
> >> I have yet to look at x86.
> > pretty sure this is going to be much more palpable.
> > -mike
>
>
Vanilla userland is simply a stage3 chroot amd64.
hardened kernel/userland
real5m43.402s
user5m42.510s
sys 0m0.002s
hardened kernel/vanilla gcc
real5m29.271s
user5m28.417s
sys 0m0.003s
hardened kernel/vanilla userland
real5m29.495s
user5m28.599s
sys 0m0.030s
vanilla all (disabled pax and grsec on hardened kernel, compiled kernel
with hardened gcc)
real5m34.861s
user5m33.981s
sys 0m0.001s
i686 cflag test, vanilla all
CFLAGS="-O2 -march=i686 -pipe"
gcc modfac.c -o vv-moddfac
real5m42.171s
user5m41.176s
sys 0m0.092s
CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
RAM: 16G
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
[gentoo-dev] Re: Package up for grabs: dev-python/suds
On 20-04-30 17:01:27, Michał Górny wrote: > Hi, > > The following package is now looking for a new maintainer: > > dev-python/suds > > Its revdeps are dev-python/oslo-vmware, sys-cluster/cinder (openstack@ / > prometheanfire@), net-wireless/chirp (zerochaos@ / radio), dev- > python/python-stdnum (cedk@). > > The package is a dead (2014) fork of a dead (2010) package. We're > hacking it to look like the original but it's a really ugly hack. > Whoever wants to take it -- please change it to edit setup.py instead. > > It's broken with modern pytest [1]. The immediate issue should be > fixable via trivial sed but there might more lurking around the corner. > There might be more bugs but Bugzilla just died. > > Py2 removal in this package is blocked by chirp. > > There's humongous number of forks and forks of forks on pypi [1] if > someone wants to look for a better version. > > > [1] https://bugs.gentoo.org/720122 > [2] https://pypi.org/search/?q=suds > dev-python/oslo-vmware and sys-cluster/cinder have suds removed in the next release, which is in a few weeks, so it'll be removed 'soon'. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
