Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. and the kernel is held to a much higher standard of stability and interoperability. In addition, the top-level developers of systemd (and GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed by a for-profit company (Red Hat), which has a vested interest in shaping Linux as a platform. They and other corporations cannot be trusted with stuff like this... hm, Redhat is one of the companies investing the most money into linux kernel, userland, graphics... if you 'don't trust them' you are pretty much 20 years too late. Investing money does not make them any more qualified or deserving of making decisions. Red Hat is not the sole user of Linux. They should consider themselves lucky that they are even able to profit from something that's free. You're right, though. They've been around for a while, and I've never trusted them or any other corporate interest in *nix. There's always a catch when dealing with a business. I'd like to see what Linus has to say about this if/when he finds out. He's not impressed with Sievers or Poettering. Personally I'd like to see them ostracized from the community and contained to their own distro, where they belong. so much about zealotry. When a tumor is growing, if you cannot excise it, you must make its environment so harsh that it recedes. I have strong opinions, but I don't go around shoving my software in peoples' faces or tell people they're wrong to not use my software. Even Linus, who's known for his ego, wouldn't cross that line. If I'm a zealot of anything, it's freedom of choice.
Re: [gentoo-user][SOLVED] Print PDF or PS to file ignores directory selection
On 10/19/13 11:55, Joseph wrote: After recent upgrade print PDF or PS to file ignores directory selection. Before, the problem is caused by: x11-libs/gtk+-2.24.16 and downgrade to x11-libs/gtk+-2.24.12 solved the problem or upgrade to gtk+-2.24.17 worked as well. But now, gtk+-2.24.12 is gone and gtk+-2.24.17 is causing the same problem. What to do? Unmasking: gtk+-2.24.21 and gtk+-2.24.22 requires dev-libs/glib-2.36.4-r1 ~amd64 to be unmasked. Once I do that other packages needs to be unmasked. I don't want to go to far this road as this is my stable system. SOLVED! Compiling gtk+-2.24.19.ebuild from attic, solves this problem. -- Joseph
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for.
Re: [gentoo-user] Re: New mobo change
Am 20.10.2013 07:39, schrieb Dale: Volker Armin Hemmann wrote: Am 18.10.2013 05:54, schrieb Dale: Walter Dnes wrote: On Thu, Oct 17, 2013 at 04:40:52PM -0500, Dale wrote Well, this is interesting. I swapped out the mobo. First, it has the UEFI BIOS thing. That was interesting for sure. I'm not complaining but not used to it and wasn't expecting it either. Second, it works except for the third part. Third thing is, no mouse worky. It works in the BIOS but not in the OS. I have gpm set to start and it doesn't work in a console or a GUI. I tried everything I can think of, no mouse. I had to swap again. I'm back to my old mobo. Here is the kicker. I plugged the USB mouse into the old mobo, it works just fine. It works in KDE, console etc. It just works. The only kernel change I made was for the chipset on the mobo. I left the USB stuff alone. I've run into this in the past. The USB 2.0 drivers are *SUPPOSED* to provide support for lowspeed USB 1.X devices, like mice and keyboards. But it doesn't always work that way. There is direct USB 1.X driver support in the kernel. In make menuconfig, got to... Device Drivers --- [*] USB support --- OHCI HCD support UHCI HCD (most Intel and VIA) support I don't see any mention in your message whether the motherboard cpu is AMD or Intel. Generally, build UHCI for Intel+VIA, OHCI for AMD. Try it out and see what happens. Mine is AMD based. I have this right now but tried every other version I could find too. * xHCI HCD (USB 3.0) support * EHCI HCD (USB 2.0) support * OHCI HCD support [*] Generic OHCI driver for a platform device there you go. platform driver. Take that one out. Make the rest modules. Amd board? kill uhci while you are at it. Change made. I plan to give this a shot again before to long. I got a few thigns to try out now. I updated sysrecue and Knoppix. I also put them both on CD/DVD to just in case it is a USB issue. At least I can test some things and hopefully find one that works. Thanks for all the help. I'll post back what happens. If it doesn't work next time or fails from sysrescue/Knoppix, I plan to RMA the board for another one. If it doesn't work with either of those, then I suspect hardware issues again. no, the mouse works in bios - so it is not a hardware issue, but in worst case a bios setting issue.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. While editing and updating configs is a normal part of system maintenance, turning a system on its head and screwing it out of network accessibility until the new default is reversed (by means of a `kernel` line in GRUB, requiring a reboot) is straight-up wrong design. Conversely, keeping old behavior, even for systems that *do* have multiple NICs, will at least be functional (for one of the NICs, anyway) until they set the option to get their expected behavior sorted out. Multi-NIC systems are less common than single-NIC systems, and that alone should've been enough motivation to leave old behavior as default, with the new behavior a simple config switch away. The way the new behavior was introduced may have led users of single-NIC systems to believe that the old way was broken, when as demonstrated through past use, works *just fine* for single-NIC machines. It was *multi-NIC* use that wasn't as predictive and needed the fix, not *single*. It's basically using poor design/defaults decisions to smear existing
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
Am 20.10.2013 08:34, schrieb Daniel Campbell: hm, Redhat is one of the companies investing the most money into linux kernel, userland, graphics... if you 'don't trust them' you are pretty much 20 years too late. Investing money does not make them any more qualified or deserving of making decisions. Red Hat is not the sole user of Linux. They should consider themselves lucky that they are even able to profit from something that's free. You're right, though. They've been around for a while, and I've never trusted them or any other corporate interest in *nix. There's always a catch when dealing with a business. 'have been around for a while' - replace that with 'are financing more core developers than anybody else'.
[gentoo-user] OT: Tablets
Hello, use someone a tablet with Gentoo or alternatives? I want me buy a tablets, but im not sure i can familiar use Android. Has someone a tablet with gentoo or other Distri running? Which tablet i can buy, advice? Thanks Greetings Silvio
[gentoo-user] Re: [O/T] RAID help - now won't boot
On Wednesday 16 Oct 2013 21:14:38 Nicolas Sebrecht wrote: On Wed, Oct 16, 2013 at 08:10:40PM +0200, Nicolas Sebrecht wrote: On Tue, Oct 15, 2013 at 10:42:18PM +0100, Mick wrote: mdadm --create --auto=mdp --verbose /dev/md_d0 --level=mirror --raid-devices=2 /dev/sda /dev/sdb which is thereafter partitioned with fdisk. This is the one I have used in the past. Which one is preferable, or what are the pros cons of each? For a basic RAID1, the best is to keep it as simple as possible. So mirroring while disk looks better. It will also keep MBR/GPT synced. s/while/the whole/ I tend to make manual partitions that I mirror but this is because I usually require to do more complex setups (e.g. mixing mirror types), or because I need to have the setup more flexible. OK, I spent some time to experiment in a VM. Two small un-partitioned virtual disks which I used to create /dev/md0 as RAID 1 using sysrescuecd. Then I used fdisk to create a MSDOS partition table on /dev/md0, followed by 4 partitions on /dev/md0: == ~$ fdisk -l Disk /dev/sda: 10.5 GB, 10522460160 bytes 255 heads, 63 sectors/track, 1279 cylinders, total 20551680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Disk /dev/sda doesn't contain a valid partition table Disk /dev/sdb: 10.5 GB, 10522460160 bytes 255 heads, 63 sectors/track, 1279 cylinders, total 20551680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Disk /dev/sdb doesn't contain a valid partition table Disk /dev/md0: 10.5 GB, 10521337856 bytes 2 heads, 4 sectors/track, 2568686 cylinders, total 20549488 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000c3148 Device Boot Start End Blocks Id System /dev/md0p1 *2048 718847 358400 83 Linux /dev/md0p2 718848 3790847 1536000 82 Linux swap / Solaris /dev/md0p3 379084818470911 7340032 83 Linux /dev/md0p41847091220549487 1039288 83 Linux == So, no partition tables on /dev/sda or /dev/sdb drives and of course no partitions at all. The partitions were created on the /dev/md0 block device. I then rebooted with a Ubuntu server CD and installed the OS in the above filesystem. It seemed to have recognised the RAID1 array as /dev/md127, instead of /dev/md0. Trying to install GRUB on /dev/sda, or /dev/sdb, or /dev/md127p1 failed. The only way to install GRUB and complete the Ubuntu server OS installation was to install it on /dev/md127, which it accepted. However, on rebooting it failed with: FATAL: No boot medium found! System halted. Rebooting with sysrescueCD and selecting to scan and boot any linux OS it could find, it picks up the RAID1 installation and it boots into it without any problem. This is what I can see now: == ~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 9.8G 0 disk └─md0 9:00 9.8G 0 raid1 ├─md0p1 259:00 350M 0 md/boot ├─md0p2 259:10 1.5G 0 md[SWAP] ├─md0p3 259:20 7G 0 md/ └─md0p4 259:30 1015M 0 md/home sdb 8:16 0 9.8G 0 disk └─md0 9:00 9.8G 0 raid1 ├─md0p1 259:00 350M 0 md/boot ├─md0p2 259:10 1.5G 0 md[SWAP] ├─md0p3 259:20 7G 0 md/ └─md0p4 259:30 1015M 0 md/home == == ~$ df -h -T Filesystem Type Size Used Avail Use% Mounted on /dev/md0p3 ext4 6.9G 1.2G 5.4G 18% / udev tmpfs 10M 8.0K 10M 1% /dev none tmpfs 146M 352K 146M 1% /run none tmpfs 5.0M 0 5.0M 0% /run/lock none tmpfs 730M 0 730M 0% /run/shm /dev/md0p1 ext2 329M 27M 285M 9% /boot /dev/md0p4 ext4 999M 18M 931M 2% /home == == ~$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 sda[0] sdb[1] 10274744 blocks super 1.2 [2/2] [UU] unused devices: none == == ~$ sudo blkid /dev/sr0: LABEL=sysrcd-3.8.0 TYPE=iso9660 /dev/sda: UUID=59195572-751a-3bd9-7771-6e5411b032c8 UUID_SUB=3acd1b2c-1c95-7c07-a8b2-8aa1b2a0a169 LABEL=sysresccd:0 TYPE=linux_raid_member /dev/sdb: UUID=59195572-751a-3bd9-7771-6e5411b032c8 UUID_SUB=c63e97ba-42cb- c4f8-550d-f1effae33d3f LABEL=sysresccd:0 TYPE=linux_raid_member /dev/md0p1: UUID=d9dbe2bc-0453-46e4-a5b0-779e55246004 TYPE=ext2 /dev/md0p2:
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 12:24, Daniel Campbell wrote: On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. It's not forced upon you. You received a news item that had instructions on howto assign names you want, like lan0, internet1, wireless3, and so forth. And it also described howto turn off udev from completely renaming the devices, to keep kernel assigned names. What they did was they dropped the *broken* feature called 'persistent rule_generator' which never worked correctly, and in race conditions still flipped eth0 - eth1 around -- that was a *security* flaw that *needed* to go. It would have gone even without providing the alternative of providing biosdevname -like new name optionality to the users. Kernel and kernel drivers are designed in a way it's not supported to flip in-place kernel names and udev tried to workaround that. https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html While editing and updating configs is a normal part of system maintenance, turning a system on its head and screwing it out of network accessibility until the new default
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/20/2013 04:55 AM, Samuli Suominen wrote: On 20/10/13 12:24, Daniel Campbell wrote: On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. It's not forced upon you. You received a news item that had instructions on howto assign names you want, like lan0, internet1, wireless3, and so forth. And it also described howto turn off udev from completely renaming the devices, to keep kernel assigned names. What they did was they dropped the *broken* feature called 'persistent rule_generator' which never worked correctly, and in race conditions still flipped eth0 - eth1 around -- that was a *security* flaw that *needed* to go. It would have gone even without providing the alternative of providing biosdevname -like new name optionality to the users. Kernel and kernel drivers are designed in a way it's not supported to flip in-place kernel names and udev tried to workaround that. https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html Like I mentioned in a prior e-mail, the change didn't affect me when it was pushed, and doesn't affect me
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote: Am 20.10.2013 08:34, schrieb Daniel Campbell: hm, Redhat is one of the companies investing the most money into linux kernel, userland, graphics... if you 'don't trust them' you are pretty much 20 years too late. Investing money does not make them any more qualified or deserving of making decisions. Red Hat is not the sole user of Linux. They should consider themselves lucky that they are even able to profit from something that's free. You're right, though. They've been around for a while, and I've never trusted them or any other corporate interest in *nix. There's always a catch when dealing with a business. 'have been around for a while' - replace that with 'are financing more core developers than anybody else'. That's less reason to trust, not more. That's like citing the popularity of something as proof of its quality, when oftentimes it's the exact opposite that's true. So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
Am 20.10.2013 12:52, schrieb Daniel Campbell: On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote: Am 20.10.2013 08:34, schrieb Daniel Campbell: hm, Redhat is one of the companies investing the most money into linux kernel, userland, graphics... if you 'don't trust them' you are pretty much 20 years too late. Investing money does not make them any more qualified or deserving of making decisions. Red Hat is not the sole user of Linux. They should consider themselves lucky that they are even able to profit from something that's free. You're right, though. They've been around for a while, and I've never trusted them or any other corporate interest in *nix. There's always a catch when dealing with a business. 'have been around for a while' - replace that with 'are financing more core developers than anybody else'. That's less reason to trust, not more. That's like citing the popularity of something as proof of its quality, when oftentimes it's the exact opposite that's true. So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind. without Redhat, there would be no linux. gnu software would be massively lacking and X would be without drivers. So calm down.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote: Am 20.10.2013 12:52, schrieb Daniel Campbell: On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote: Am 20.10.2013 08:34, schrieb Daniel Campbell: hm, Redhat is one of the companies investing the most money into linux kernel, userland, graphics... if you 'don't trust them' you are pretty much 20 years too late. Investing money does not make them any more qualified or deserving of making decisions. Red Hat is not the sole user of Linux. They should consider themselves lucky that they are even able to profit from something that's free. You're right, though. They've been around for a while, and I've never trusted them or any other corporate interest in *nix. There's always a catch when dealing with a business. 'have been around for a while' - replace that with 'are financing more core developers than anybody else'. That's less reason to trust, not more. That's like citing the popularity of something as proof of its quality, when oftentimes it's the exact opposite that's true. So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind. without Redhat, there would be no linux. gnu software would be massively lacking and X would be without drivers. So calm down. Linux was created and released in 1991, built with GNU tools. Red Hat didn't come along until 1993. Linux and GNU would both still be here; their quality without Red Hat involvement is speculative at best. I maintain that motives matter more than money and that they (motives) should continually be audited, especially when receiving contributions from a company. They may already be; I don't know. Re: drivers, do you expect me to believe Red Hat is responsible for every X11 driver out there? How many of this list?[1] What of radeon and nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm sure Red Hat has contributed plenty to X11, but your statement is flat-out false. [1]: http://www.usinglinux.org/x11-drivers/ [2]: http://sourceforge.net/apps/mediawiki/linuxwacom/
Re: [gentoo-user] Re: [O/T] RAID help - now won't boot
Am 20.10.2013 11:54, schrieb Mick: Any ideas why the Ubuntu installation won't boot? My guess would be, you cannot boot, because if you install grub in /dev/md0. Upon boot the bios cannot find stage1 of the bootloader, which normally lies in the MBR (which also houses the partition table). Is a setup as you wish - sda and sdb as raid1, and partitions only on md0 - bootable in general? signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 13:47, Daniel Campbell wrote: On 10/20/2013 04:55 AM, Samuli Suominen wrote: On 20/10/13 12:24, Daniel Campbell wrote: On 10/20/2013 02:37 AM, Samuli Suominen wrote: On 20/10/13 09:34, Daniel Campbell wrote: On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: Am 19.10.2013 17:02, schrieb Daniel Campbell: On 10/17/2013 11:27 PM, Mark David Dumlao wrote: https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign Not sure if I read that just right... but since nobody is doing cgroup management besides systemd, in practice the cgroups implementation in Linux wasn't very consistent. So since systemd is doing it, their work is helping shape the kernel's cgroups api? Interesting... From my perspective it looks like systemd developers are trying to push their ideas into the kernel, almost like they intend to merge systemd *with* the kernel. from what I read in the article cgroups are a mess and are cleaned up anyway. The only real user of cgroups at the moment is systemd. Others are welcome to make use of cgroups too. But in the current state nobody blames them for not jumping in. No complaints here in improving something, but consider the source is all I'm saying. If systemd is the only implementation of cgroups and their developers are working on cgroup support in the kernel, it spells calamity given their history of evangelism and zealotry. well, going over some old ml threads on fedora mailing lists all I could find was that Poettering and Sievers DID listen and DID make changes if the demand was high enough. Sure, I dislike systemd. Sure what happened with udev was a dick move. But their 'zealotry' is a lot less developed than the zealotry of those who exploded about using an 'init-thingy' in the future. I'd say their zealotry is less loud and more persistent. Their way is best, UNIX (and its philosophy) is outmoded, people are thinking 30 years behind where we are, etc etc etc. Those who have separate /usr and blame systemd for pushing them to use an initramfs aren't seeing the real problem (upstreams not putting things where they belong, FHS no longer *really* being worked on, generally just the filesystem being played with like a toy) I truly wish I understood why a single userland program and its developers are being given the keys to an entire subsystem of the kernel. they aren't. Of the people who have committed to the cgroup subsystem of the kernel, how many are not members of the systemd, GNOME, or Red Hat projects? I'll let that speak for itself. Their changes to udev have proven to be a headache for users, yes? which ones? Persistent NIC naming, for starters. The former maintainer's idea to merge with systemd (which was influenced by Mr. Poettering in the first place) when the two are completely separate pieces of software that do two completely different jobs, and various other troubles with udev 175 that one can Google for and find tons of results. I can't find anything that would be true. Can you point out some? A lot of FUD[1] and outright lies coming from people, who, for example, don't like systemd. [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt I know for a fact udev-208 is a full replacement for udev-171 in terms that both work on same kernels, same libcs, and so forth. That's why 171 is no longer in Portage, because it's completely useless from users (and developers) point of view. Adjusting some configs and enabling some kernel options that have been around for a long time is just part of normal maintenance process, that's what we have admins for. Do you know the design consequences of opt-in versus opt-out? I'll keep this short: When evolving a codebase, new behavior for core parts of the system should not be pushed or forced on users. If you must, keep the old behavior around as a default and allow users to try the new thing by explicitly opting in. The new naming in whichever udev started the mess did it the exact opposite (and wrong) way. It's not forced upon you. You received a news item that had instructions on howto assign names you want, like lan0, internet1, wireless3, and so forth. And it also described howto turn off udev from completely renaming the devices, to keep kernel assigned names. What they did was they dropped the *broken* feature called 'persistent rule_generator' which never worked correctly, and in race conditions still flipped eth0 - eth1 around -- that was a *security* flaw that *needed* to go. It would have gone even without providing the alternative of providing biosdevname -like new name optionality to the users. Kernel and kernel drivers are designed in a way it's not supported to flip in-place kernel names and udev tried to workaround that. https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html Like I mentioned in a prior e-mail, the change didn't affect me when
Re: [gentoo-user] Re: [O/T] RAID help - now won't boot
On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote: Am 20.10.2013 11:54, schrieb Mick: Any ideas why the Ubuntu installation won't boot? My guess would be, you cannot boot, because if you install grub in /dev/md0. Upon boot the bios cannot find stage1 of the bootloader, which normally lies in the MBR (which also houses the partition table). I see ... so installing the MBR code in the /dev/md0 block device is further down the disk than where BIOS is looking for it and that's why it errors out? Meanwhile, there is no MBR or partition table on /dev/sda or /dev/sdb for BIOS to jump to. Hmm ... It seems to me then that I *have* to create normal partitions on /dev/sda /dev/sdb, or I would need a different boot drive. Is there another way to overcome this problem. Is a setup as you wish - sda and sdb as raid1, and partitions only on md0 - bootable in general? Yes, in this case. It makes easy to set a faulty drive in failed state and remove it from RAID in a single step, rather than the alternative which would involve removing multiple /dev/mdX, one for each partition. I could I guess install LVM on top of RAID, but this adds complexity for a functionality (increasing LV sizes) which will not be used in this implementation. Any suggestions welcome. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [O/T] RAID help - now won't boot
Am 20.10.2013 15:13, schrieb Mick: On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote: Am 20.10.2013 11:54, schrieb Mick: Any ideas why the Ubuntu installation won't boot? My guess would be, you cannot boot, because if you install grub in /dev/md0. Upon boot the bios cannot find stage1 of the bootloader, which normally lies in the MBR (which also houses the partition table). I see ... so installing the MBR code in the /dev/md0 block device is further down the disk than where BIOS is looking for it and that's why it errors out? That would be my guess. Maybe someone more knowledgeable on how mdadm writes stuff on the disk can jump in and provide additional info. But I'm pretty sure, if you install grub in md0, it's not in that place on the disk where the bios is actually looking for. It seems to me then that I *have* to create normal partitions on /dev/sda /dev/sdb, or I would need a different boot drive. Is there another way to overcome this problem. Maybe create two mds. md1 (sda1, sdb1) is a small boot partition which contains stage2+, the kernel and the initramfs. And md2 (sda2, sdb2) which acts as another block device with partition table, etc... In this setup you could install grub in the mbr of sda and sdb (grub-install /dev/sda...) A quick google on this subject returned no usable results. But I am off now until tomorrow. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 20/10/13 13:47, Daniel Campbell wrote: Like I mentioned in a prior e-mail, the change didn't affect me when it was pushed, and doesn't affect me now. I did recently have to reinstall Gentoo, however (note, going from testing to stable isn't fun ;p), and noticed it when I found Gentoo ships with systemd-udev instead of eudev. Yep, no plans on changing the default sys-fs/udev to anything else, no reason to. To be clear - you are saying that the new default init system for a new gentoo install is systemd? When did this happen? I thought that OpenRC was still the default? Perhaps the next time I need to install Gentoo, I'll find a way to get eudev on there before even the first proper boot and avoid the problem altogether. It's true that sys-fs/eudev restored the *broken* rule_generator from old sys-fs/udev, you can get it by USE=rule-generator. But it's lot saner to keep using sys-fs/udev and just write custom rules to rename interfaces based on MACs to like lan*, internet* so all in all, currently, using sys-fs/eudev doesn't make sense unless you are experimenting/developing for it. The problem with this is, what happens if (or maybe *when*?) the systemd maintainers make a change that then breaks udev for anything but systemd?
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 17:01, Tanstaafl wrote: On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 20/10/13 13:47, Daniel Campbell wrote: Like I mentioned in a prior e-mail, the change didn't affect me when it was pushed, and doesn't affect me now. I did recently have to reinstall Gentoo, however (note, going from testing to stable isn't fun ;p), and noticed it when I found Gentoo ships with systemd-udev instead of eudev. Yep, no plans on changing the default sys-fs/udev to anything else, no reason to. To be clear - you are saying that the new default init system for a new gentoo install is systemd? No, I'm saying the default /dev manager in Gentoo has been sys-fs/udev and will be sys-fs/udev When did this happen? I thought that OpenRC was still the default? It is. Perhaps the next time I need to install Gentoo, I'll find a way to get eudev on there before even the first proper boot and avoid the problem altogether. It's true that sys-fs/eudev restored the *broken* rule_generator from old sys-fs/udev, you can get it by USE=rule-generator. But it's lot saner to keep using sys-fs/udev and just write custom rules to rename interfaces based on MACs to like lan*, internet* so all in all, currently, using sys-fs/eudev doesn't make sense unless you are experimenting/developing for it. The problem with this is, what happens if (or maybe *when*?) the systemd maintainers make a change that then breaks udev for anything but systemd? That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 20/10/13 17:01, Tanstaafl wrote: It's true that sys-fs/eudev restored the *broken* rule_generator from old sys-fs/udev, you can get it by USE=rule-generator. But it's lot saner to keep using sys-fs/udev and just write custom rules to rename interfaces based on MACs to like lan*, internet* so all in all, currently, using sys-fs/eudev doesn't make sense unless you are experimenting/developing for it. The problem with this is, what happens if (or maybe *when*?) the systemd maintainers make a change that then breaks udev for anything but systemd? To continue my previous reply. That has already happened once. That's why we implemented /dev tmpfiles.d support for OpenRC 0.12, that's why =sys-apps/kmod-15 is now requiring =sys-apps/openrc-0.12. So it's case-by-case basis.
[gentoo-user] Gentoo on ARM Tablets
Silvio Siefke siefke_listen at web.de writes: use someone a tablet with Gentoo or alternatives? I want me buy a tablets, but im not sure i can familiar use Android. Has someone a tablet with gentoo or other Distri running? Tablets mostly use ARM processors... You have to do some research. I've merely collected up some links that may be of interest to you. Look here to see what vendors are developing together for Arm-Linux. http://www.linaro.org http://www.archos.com/ http://www.openaos.org/~kevin/archos_angstrom_docs/index.html http://www.samygo.tv/ You could had a touch screen to this system: http://www.ti.com/tool/omap5432-evm?DCMP=omap-5432evm-130521HQS=omap-5432evm-b-sw Or this kit http://www.phytec.com/products/system-on-modules/phycore/omap5430/#kits The A15 is the smoking new Arm chip. Most cell phones and tablets use and ARM SOC (system on a chip). http://www.chromebook-linux.com/2011/11/gentoo-is-ready-for-chromebook.html Post back what you do or find that is new. Good hunting! hth, James
Re: [gentoo-user] Re: [O/T] RAID help - now won't boot
Michael Hampicke m...@hadt.biz wrote: Am 20.10.2013 15:13, schrieb Mick: On Sunday 20 Oct 2013 13:57:34 Michael Hampicke wrote: Am 20.10.2013 11:54, schrieb Mick: Any ideas why the Ubuntu installation won't boot? My guess would be, you cannot boot, because if you install grub in /dev/md0. Upon boot the bios cannot find stage1 of the bootloader, which normally lies in the MBR (which also houses the partition table). I see ... so installing the MBR code in the /dev/md0 block device is further down the disk than where BIOS is looking for it and that's why it errors out? That would be my guess. Maybe someone more knowledgeable on how mdadm writes stuff on the disk can jump in and provide additional info. But I'm pretty sure, if you install grub in md0, it's not in that place on the disk where the bios is actually looking for. It seems to me then that I *have* to create normal partitions on /dev/sda /dev/sdb, or I would need a different boot drive. Is there another way to overcome this problem. Maybe create two mds. md1 (sda1, sdb1) is a small boot partition which contains stage2+, the kernel and the initramfs. And md2 (sda2, sdb2) which acts as another block device with partition table, etc... In this setup you could install grub in the mbr of sda and sdb (grub-install /dev/sda...) A quick google on this subject returned no usable results. But I am off now until tomorrow. I would suggest trying it by usong the older metadata format. Check the man pages, but I thinl it would be --metadata=0.90 (or similar) during creation. That might put the metadata at the end, rather then at the front. (Or it's the other way round and new metadata does it at the end.) -- Joost Ps. I have never tried it this way (full disk raid for boot device) using linux software raid. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 2013-10-20 6:52 AM, Daniel Campbell li...@sporkbox.us wrote: So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind. Well, once I understood their (Redhat's) motivation, which was/is enterprise/cloud/vm oriented (which is why they were so concerned about parallelism for startup, etc) - I dropped the conspiracy theory aspect of it all... it actually does make sense in that context. And as long as Linus is at the helm of kernel development, I'm not too worried about the systemd guys doing too much damage there - I just can't see him letting it happen. If I were the type to worry just for the sake of worrying, I'd be wondering what may happen down the road, if Linus were to suddenly lose interest in kernel development (for whatever reason) and walk away from it - who/what would take over the reins? But that would be pointless...
[gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo
Hi, I just migrated to grub2 which works fine thanks to the good Gentoo docs! :) But... I need to increase the resolution of the boot screen to see what is going on there. The docs say, that with the command vbeinfo from the grub console I can see the valid modes of my grpahics card. Now...the current resolution of the grub console compbined with the unfortunate sorting of the output of vbeinfo I am currently only able to read the last entries of this realy long list. Therefore...I need the whole output of vbeinfo to set the console resulotion that way, so I will be able to read the output of vbeinfo deadlock? Nice things like 'less' or such are not available What can I do? Thank you very much in advance for any help! Best regards, mcc
Re: [gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo
meino.cra...@gmx.de schrieb am 20.10.2013 19:17: Hi, I just migrated to grub2 which works fine thanks to the good Gentoo docs! :) But... I need to increase the resolution of the boot screen to see what is going on there. The docs say, that with the command vbeinfo from the grub console I can see the valid modes of my grpahics card. Now...the current resolution of the grub console compbined with the unfortunate sorting of the output of vbeinfo I am currently only able to read the last entries of this realy long list. Therefore...I need the whole output of vbeinfo to set the console resulotion that way, so I will be able to read the output of vbeinfo deadlock? Nice things like 'less' or such are not available What can I do? Try this: set pager=1 http://www.gnu.org/software/grub/manual/grub.html#pager -- Regards Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] grub2: need the output of vbeinfo to be able to read the output of vbeinfo
Daniel Pielmeier bil...@gentoo.org [13-10-20 19:32]: meino.cra...@gmx.de schrieb am 20.10.2013 19:17: Hi, I just migrated to grub2 which works fine thanks to the good Gentoo docs! :) But... I need to increase the resolution of the boot screen to see what is going on there. The docs say, that with the command vbeinfo from the grub console I can see the valid modes of my grpahics card. Now...the current resolution of the grub console compbined with the unfortunate sorting of the output of vbeinfo I am currently only able to read the last entries of this realy long list. Therefore...I need the whole output of vbeinfo to set the console resulotion that way, so I will be able to read the output of vbeinfo deadlock? Nice things like 'less' or such are not available What can I do? Try this: set pager=1 http://www.gnu.org/software/grub/manual/grub.html#pager -- Regards Daniel Pielmeier Hi Daniel! LIFESAVER! Thanks a lot! Didnt saw this... Best regards, mcc
[gentoo-user] openoffice-bin-4.0.1 - no menu text on top
I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ -- Joseph
Re: [gentoo-user] Re: Console won't un-blank
On Fri, Oct 18, 2013 at 10:40:32PM +0200, Holger Hoffstaette wrote: On Thu, 17 Oct 2013 21:02:13 -0400, Michael J. Barillier wrote: If I leave my laptop unattended (at a console, not X) and the screen blanks, pressing a key won't un-blank the terminal. As a test, I ssh'ed into the laptop and ran: # setterm -blank poke /dev/tty$N Very likely kernel or DRM subsystem. I have an T60 Thinkpad with old ATI graphics and since kernel ~3.7.1 (approx.) it won't unblank any more, just as you described. I tested some time ago with an early 3.10.x and it still did not work. Everything works correctly on a second machine without KMS (plain VESA) and a third system with newer Radeon card, so I always attributed it to the stone age hardware and bitrot. There were quite a lot of changes to the Radeon and DRM machinery over the last few kernel releases. I have here a Samsung P30 (first Centrino generation) with a Radeon 9200 and radeon driver in KMS mode, Kernel 3.10.11. Unblanking works normal. I [br]arely use that machine, only keep it up to date from time to time in case I may need it in lieu of my normal laptop. So its setup is fairly default stage3. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Friends may come and go, but enemies accumulate. signature.asc Description: Digital signature
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
Joseph syscon...@gmail.com wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ -- Joseph Sounds like a font issue. You could try 'emerge -vae small package showing this problem' I wouldn't try this with openoffice right away. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ Is there any helpful output on the console if you start LO from there? What about revdep-rebuild? -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Automation is man’s attempt of shaping work so that women can do it. signature.asc Description: Digital signature
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
On 10/20/13 20:09, J. Roeleveld wrote: Joseph syscon...@gmail.com wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon l og in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normall y :-/ Sounds like a font issue. You could try 'emerge -vae small package showing this problem' I wouldn't try this with openoffice right away. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity. Do you mean: emerge -vae app-office/openoffice-bin or emerge -vae slim In both cases I get 306 packages needs rebuilding, this will be a log way to try to fix this problem :-/ -- Joseph
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
On 10/20/13 20:09, J. Roeleveld wrote: Joseph syscon...@gmail.com wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon l og in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normall y :-/ Sounds like a font issue. You could try 'emerge -vae small package showing this problem' I wouldn't try this with openoffice right away. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity. In addition I have tried fc-list and try to compare font on the same systems, they are all the same. system called atom - not effected system called syscon2 - effected by not showing text the menu. All fonts that are in atom are present in syscon2 so I don't think this is problem with the fonts. -- Joseph
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
On 10/20/13 20:42, Frank Steinmetzger wrote: On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ Is there any helpful output on the console if you start LO from there? What about revdep-rebuild? -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Automation is man’s attempt of shaping work so that women can do it. What is LO ? I've tried to start the oowriter from the command line, there are no errors reported :-/ -- Joseph
[gentoo-user] Re: New mobo change
Dale wrote: Howdy, I ordered the new mobo as much as I needed to wait. The mobo is the same brand but a different chipset and a couple other things are different. I have already built a kernel for those changes. I plan to put everything on the old mobo on the new mobo. That includes the CPU. I'm pretty sure this will not be needed but want to ask to be sure. Do I need to do a emerge -e world or should it just work like it is? Since the CPU is going to be the exact same CPU, I'm thinking it is not needed. I do have march=native set in make.conf. Thoughts? Thanks. Dale :-) :-) P. S. I think this is the most I have ever spent on a mobo. $120.00 with shipping. Here is another update. I currently have the new mobo in the puter. The only port that works is the 3.0 ports. None of the other ports work. I mean nothing. When I plug my cell phone in, it doesn't even get power much less see it. When I plug the mouse in, the light doesn't come on. It's just plain dead. While in the BIOS, the mouse works in any USB port. So, I got the USB 3 ports working but something is killing the other ports. Nothing I plug into the USB 1/2 ports works outside of BIOS. I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ What do I need to post so someone can compare this to something that works? I'll post the whole kernel config if needed/requested. If you just need certain parts, just let me know what to grep for. Thanks. I'll be beating on it until I hear some more ideas from y'all. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: New mobo change
On 10/20/2013 2:19 PM, Dale wrote: I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ Hello, Have you tried booting into a linux distro that offers a recent live cd to see if that distro can properly detect and load the needed drivers? And If they work, then you can find out which drivers were loaded.
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
On 10/20/13 20:42, Frank Steinmetzger wrote: On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ Is there any helpful output on the console if you start LO from there? What about revdep-rebuild? -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Automation is man’s attempt of shaping work so that women can do it. Solved. This is a problem with xorg-server-1.14.3 Downgrading to x11-base/xorg-server-1.13.4-r1 solved the problem. -- Joseph
Re: [gentoo-user] Re: New mobo change
Edward M wrote: On 10/20/2013 2:19 PM, Dale wrote: I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ Hello, Have you tried booting into a linux distro that offers a recent live cd to see if that distro can properly detect and load the needed drivers? And If they work, then you can find out which drivers were loaded. I did once before and it failed to boot with a error. I didn't write it down. I may try that later on tho. I have since updated sysrescue. While it is not like I want it, the mouse does move when I poke it. lol Thanks for the reminder tho. I'll post results when I try it. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On Oct 20, 2013 10:44 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-20 6:52 AM, Daniel Campbell li...@sporkbox.us wrote: So they spend a lot of money hiring developers. The more important question is what is their agenda? What do they tell those developers to *make*? You don't hire people without a business plan in mind. Well, once I understood their (Redhat's) motivation, which was/is enterprise/cloud/vm oriented (which is why they were so concerned about parallelism for startup, etc) - I dropped the conspiracy theory aspect of it all... it actually does make sense in that context. And as long as Linus is at the helm of kernel development, I'm not too worried about the systemd guys doing too much damage there - I just can't see him letting it happen. If I were the type to worry just for the sake of worrying, I'd be wondering what may happen down the road, if Linus were to suddenly lose interest in kernel development (for whatever reason) and walk away from it - who/what would take over the reins? But that would be pointless... Linus isnt actually actively developing the kernel nowadays. Mostly he just merges commits from his trusted lieutenants in charge of various subsystems. The notion of Linus as being at the helm is mostly just a convenient fiction that corporate culture (and by extension, the media) - which is used to strong leadership - uses to make sense of open source development. That's partly why he finds it funny when people take his flames too seriously, as if they were Word of God. If he took were cut down by a sith lord, most likely morton's tree would seamlessly be the new upstream.
Re: [gentoo-user] Re: New mobo change
On 21/10/13 07:52, Dale wrote: Edward M wrote: On 10/20/2013 2:19 PM, Dale wrote: I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ Hello, Have you tried booting into a linux distro that offers a recent live cd to see if that distro can properly detect and load the needed drivers? And If they work, then you can find out which drivers were loaded. I did once before and it failed to boot with a error. I didn't write it down. I may try that later on tho. I have since updated sysrescue. While it is not like I want it, the mouse does move when I poke it. lol Thanks for the reminder tho. I'll post results when I try it. Dale :-) :-) sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a better spread of capabilities. Have you checked the bios for usb parameters (i.e., defaults to off, or wrong mode?) - whats on offer in the bios may not be the same as when you exit it. Billk
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens. That's not always possible, e.g. GNOME 3.8. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: New mobo change
William Kenworthy wrote: On 21/10/13 07:52, Dale wrote: Edward M wrote: On 10/20/2013 2:19 PM, Dale wrote: I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ Hello, Have you tried booting into a linux distro that offers a recent live cd to see if that distro can properly detect and load the needed drivers? And If they work, then you can find out which drivers were loaded. I did once before and it failed to boot with a error. I didn't write it down. I may try that later on tho. I have since updated sysrescue. While it is not like I want it, the mouse does move when I poke it. lol Thanks for the reminder tho. I'll post results when I try it. Dale :-) :-) sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a better spread of capabilities. Have you checked the bios for usb parameters (i.e., defaults to off, or wrong mode?) - whats on offer in the bios may not be the same as when you exit it. Billk I rebooted and the newest sysrescue still wouldn't boot up. It says it can't find /sysrcd.dat which I think is caused because it can't use the USB port that the sysrescue stick is plugged into. So, I booted Knoppix instead from DVD. Success. I got a list of drivers from lspci and plan to research them and see if I am missing something. If not, I may just start with a fresh config and see if that helps. At least the mobo is working tho. That's a good thing. It's a start at least. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: New mobo change
On 21/10/13 11:09, Dale wrote: William Kenworthy wrote: On 21/10/13 07:52, Dale wrote: Edward M wrote: On 10/20/2013 2:19 PM, Dale wrote: I still think this is a kernel issue. I just don't know which part. I have tried switching stuff on/off and such but nothing works. I'm thinking about putting my sledge hammer to work. :/ Hello, Have you tried booting into a linux distro that offers a recent live cd to see if that distro can properly detect and load the needed drivers? And If they work, then you can find out which drivers were loaded. I did once before and it failed to boot with a error. I didn't write it down. I may try that later on tho. I have since updated sysrescue. While it is not like I want it, the mouse does move when I poke it. lol Thanks for the reminder tho. I'll post results when I try it. Dale :-) :-) sysrescuecd is gentoo based ... try ubuntu or linuxmint to provide a better spread of capabilities. Have you checked the bios for usb parameters (i.e., defaults to off, or wrong mode?) - whats on offer in the bios may not be the same as when you exit it. Billk I rebooted and the newest sysrescue still wouldn't boot up. It says it can't find /sysrcd.dat which I think is caused because it can't use the USB port that the sysrescue stick is plugged into. So, I booted Knoppix instead from DVD. Success. I got a list of drivers from lspci and plan to research them and see if I am missing something. If not, I may just start with a fresh config and see if that helps. At least the mobo is working tho. That's a good thing. It's a start at least. Dale :-) :-) Ive found that with gentoo/sysrescuecd before - the other distros do a better job of detection - I have a dell system here that wont work on SRD for instance. But after using ubuntu to find what was missing, its running gentoo fine. Billk
Re: [gentoo-user] Re: New mobo change
William Kenworthy wrote: On 21/10/13 11:09, Dale wrote: I rebooted and the newest sysrescue still wouldn't boot up. It says it can't find /sysrcd.dat which I think is caused because it can't use the USB port that the sysrescue stick is plugged into. So, I booted Knoppix instead from DVD. Success. I got a list of drivers from lspci and plan to research them and see if I am missing something. If not, I may just start with a fresh config and see if that helps. At least the mobo is working tho. That's a good thing. It's a start at least. Dale :-) :-) Ive found that with gentoo/sysrescuecd before - the other distros do a better job of detection - I have a dell system here that wont work on SRD for instance. But after using ubuntu to find what was missing, its running gentoo fine. Billk Well, I have enabled everything I could find from the Knoppix test and it still does not work. I'm likely going to just try to config a kernel from scratch later on. That or go back to the one from my old mobo and just change the chipset. See if that works. Thanks for the help. I'll post updates when I can. I may be pretty busy for a few days. Could be a bit. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] openoffice-bin-4.0.1 - no menu text on top
Joseph syscon...@gmail.com wrote: On 10/20/13 20:42, Frank Steinmetzger wrote: On Sun, Oct 20, 2013 at 11:45:26AM -0600, Joseph wrote: I have been hit by a bug that I don't know how to go about it. First my login manager slim is not showing any username / password text upon log in; now Openoffice-bin has no menu text on top. How to go about this bug? I have four systems two x86 and two amd64 one x86 and one amd64 are effected by this bug, two other system working normally :-/ Is there any helpful output on the console if you start LO from there? What about revdep-rebuild? -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Automation is man’s attempt of shaping work so that women can do it. Solved. This is a problem with xorg-server-1.14.3 Downgrading to x11-base/xorg-server-1.13.4-r1 solved the problem. -- Joseph Glad to hear it. I had similar issues in the past. Those were solved by a full rebuild. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: New mobo change
Dale wrote: William Kenworthy wrote: On 21/10/13 11:09, Dale wrote: I rebooted and the newest sysrescue still wouldn't boot up. It says it can't find /sysrcd.dat which I think is caused because it can't use the USB port that the sysrescue stick is plugged into. So, I booted Knoppix instead from DVD. Success. I got a list of drivers from lspci and plan to research them and see if I am missing something. If not, I may just start with a fresh config and see if that helps. At least the mobo is working tho. That's a good thing. It's a start at least. Dale :-) :-) Ive found that with gentoo/sysrescuecd before - the other distros do a better job of detection - I have a dell system here that wont work on SRD for instance. But after using ubuntu to find what was missing, its running gentoo fine. Billk Well, I have enabled everything I could find from the Knoppix test and it still does not work. I'm likely going to just try to config a kernel from scratch later on. That or go back to the one from my old mobo and just change the chipset. See if that works. Thanks for the help. I'll post updates when I can. I may be pretty busy for a few days. Could be a bit. Dale :-) :-) Update. I did some googling and found out that I have to add iommu=pt to the kernel command line. When I do that, it works fine. It seems that this mobo doesn't play well with 64 bit Linux. Some even said it appears to be a windoze only mobo. So, my question is this. I just spent $120 on a mobo that it appears it doesn't work up to its full value. Should I swap this mobo for another board, brand to most likely, and be done with it? I like my last Gigabyte mobo but if this one isn't going to support what I use, maybe I need to rethink this selection. What are the thoughts of some mobo gurus? I bought it from newegg so return shouldn't be to big of a issue if I get this started pretty soon. I'll check for BIOS updates but the posts I found said it didn't help a bit. Thoughts? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 10/20/2013 09:34 PM, Walter Dnes wrote: On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote That's a bridge we will cross when there is a bridge to be crossed, but from top of my head: We will maintain a minimal patchset that reverts the offending code. As in, that's nothing to be worried about before it happens. That's not always possible, e.g. GNOME 3.8. I think that's an exception to the rule. I mean, upstream deliberately chose to depend on systemd/logind and whatnot. In such a situation there's literally no way to fix it without a fork, and I doubt Gentoo as an organization is interested in that.
Re: [gentoo-user] Re: [O/T] RAID help - now won't boot
On Sunday 20 Oct 2013 15:31:12 jo...@antarean.org wrote: I would suggest trying it by usong the older metadata format. Check the man pages, but I thinl it would be --metadata=0.90 (or similar) during creation. That might put the metadata at the end, rather then at the front. (Or it's the other way round and new metadata does it at the end.) -- Joost Ps. I have never tried it this way (full disk raid for boot device) using linux software raid. Ha! Yes, this made a difference, thanks! With metadata 0.90 I can see the same partitions I set up on /dev/md0, also on /dev/sda and /dev/sdb. The only problem now is that the Ubuntu server CD wants to format /dev/sda2 as swap and fails at that stage. :-/ Not sure how to by-pass this. I may also try metadata=1.0 to see if this makes a difference, which also positions the RAID data superblock at the end of the device: Sub-Version Superblock Position on Device --- - 0.9 At the end of the device 1.0 At the end of the device 1.1 At the beginning of the device 1.2 4K from the beginning of the device -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: New mobo change
Dale rdalek1...@gmail.com wrote: Dale wrote: William Kenworthy wrote: On 21/10/13 11:09, Dale wrote: I rebooted and the newest sysrescue still wouldn't boot up. It says it can't find /sysrcd.dat which I think is caused because it can't use the USB port that the sysrescue stick is plugged into. So, I booted Knoppix instead from DVD. Success. I got a list of drivers from lspci and plan to research them and see if I am missing something. If not, I may just start with a fresh config and see if that helps. At least the mobo is working tho. That's a good thing. It's a start at least. Dale :-) :-) Ive found that with gentoo/sysrescuecd before - the other distros do a better job of detection - I have a dell system here that wont work on SRD for instance. But after using ubuntu to find what was missing, its running gentoo fine. Billk Well, I have enabled everything I could find from the Knoppix test and it still does not work. I'm likely going to just try to config a kernel from scratch later on. That or go back to the one from my old mobo and just change the chipset. See if that works. Thanks for the help. I'll post updates when I can. I may be pretty busy for a few days. Could be a bit. Dale :-) :-) Update. I did some googling and found out that I have to add iommu=pt to the kernel command line. When I do that, it works fine. It seems that this mobo doesn't play well with 64 bit Linux. Some even said it appears to be a windoze only mobo. So, my question is this. I just spent $120 on a mobo that it appears it doesn't work up to its full value. Should I swap this mobo for another board, brand to most likely, and be done with it? I like my last Gigabyte mobo but if this one isn't going to support what I use, maybe I need to rethink this selection. What are the thoughts of some mobo gurus? I bought it from newegg so return shouldn't be to big of a issue if I get this started pretty soon. I'll check for BIOS updates but the posts I found said it didn't help a bit. Thoughts? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Of the general consensus is that it is a ms windows only board. Then I would return it. I have had good experiences with ASUS and Tyan boards. The latter are more expensive, but Tyan does officially support Linux. (The Linux driver section is as easy to find as the ms windows driver section.) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.