Re: [gentoo-dev] rfc: oldnet scripts splitting out from OpenRC
I have just one question When "gentoo-oldscripts" is pulled from openrc WHAT will be the default network configuration method? Without the "standard" net scripts, many systems will break. What is being given for network configuration? NetworkManager? (yuck!) -- G.Wolfe Woodbury redwo...@gmail.com
[gentoo-dev] netqmail-1.06 install phase failure -- bugzilla 435334
Installing mail-mta/netqmail-1.06 into a gentoo amd64 stable system fails during the install/setup phase apparently due to a change in the arguments of /usr/bin/queue-repair.py Gentoo Bugzill # 435334 submitted and all available information attached. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/09/2012 07:12 PM, Olivier Crête wrote: > Can we also have a desktop that doesn't us X? That is NOT likely to happen. X Windows is about the only *nix windowing system around. There may be others, but their use is rare. Practically all the graphical interface software uses X and its addons. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 06:14 AM, Rich Freeman wrote: 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). This requirement by M$ is applied to hardware that wants the "Certified for Windows 8" logo. If the OEMs don't care about windows 8 certification, they can provide for UEIF secure boot disabling. Since it is a "voluntary" acceptance in return for granting a consumer-fooling certification, they get away with an anti-competetive practice. They want to keep android off hardware used for Windows 8. Always follow the money. -- G.Wolfe Woodbury
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/03/2012 10:53 AM, Ian Stakenvicius wrote: > On 01/01/12 03:53 AM, Sven Vermeulen wrote: >> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: >>> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My >>> understanding is that they want to move software that is installed in >>> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move >>> everything from /lib to /usr/lib. >> >> I don't like this one bit. Things used to be simple with the "split" >> between >> /bin and /usr/bin (and its related directories), this isn't going to >> make it >> more simple. > > I concurr. I will admit that I've been rather out of touch with what > other distros are doing (and have been for ~3-4 years), but combining > everything into /usr/bin just seems plain backwards and I am rather > shocked that all the distros are moving that way. > > Has the LFH been updated?? Googling seems to say no, as the last mod > seems to have been in 2004... I know that, technically, these are > 'userspace' programs in that they aren't kernel-space, but they're > still 'system' programs so to me it still makes sense for them to be > on the 'system' side of the filesystem hierarchy, doesn't it? The problem is that one group of developers is ignoring years of history and purpose in the separation of /bin and /usr/bin and the ability of having a separate /usr. This is in the udev development team and they /deliberately/ placed or used some programs in /usr/bin instead /bin and requiring that /usr bee in the root partition. I will note that the historical separation of the /usr stems from the days of user home directories being in /usr/home instead of /home. It is getting to the point that the security aspects of having a read-only mount for userspace executables is being overridden by developer fiat. Lay this one at the RedHat/Fedora developers of udev. -- G.Wolfe Woodbury aka redwo...@gmail.com
