Re: [gentoo-user] BUG : kernel 4.5.1 and ALSA
21.04.2016 11:28, Alexander Kapshuk wrote: On Thu, Apr 21, 2016 at 10:59 AM, Yuri K. Shatroff <yks-...@yandex.ru> wrote: Hi gentoo-users, A few days ago I updated linux kernel to 4.5.1. Yesterday I got a disk space overflow in my /home partition. Cleaned it up and rebooted, just to run into the same issue today morning. Investigations revealed that the `.xsessions-errors` had grown to tremendous 100G full of messages like: AL lib: (EE) ALCplaybackAlsa_mixerProc: start failed: File descriptor in a bad state It is - *50G per DAY!* Thinking about a possible cause and bearing in mind I've not updated ALSA recently rather than the kernel, I went to the kernel's changelog and found that version 4.5.2 fixes several ALSA-related bugs. I upgraded immediately and got rid of the error. So I advise everyone not to install the 4.5.1 kernel and suggest removing it from portage ASAP. If anyone knows how I could submit such a request, I'm all ears. Thanks for your attention! -- Regards, Yuri K. Shatroff That's interesting. That was certainly not my experience running vanilla 4.5.1. Although I compiled the kernel sources I had previously downloaded from the kernel.org's git repository. How did you obtain your kernel sources? I emerged gentoo-sources==4.5.1. I believe this is the related commit: ALSA: hda - Fix regression of monitor_present flag in eld proc file This can be wrong, but anyway, I listed some facts supporting the hypothesis of a problem in the 4.5.1 version. -- Regards, Yuri K. Shatroff
[gentoo-user] BUG : kernel 4.5.1 and ALSA
Hi gentoo-users, A few days ago I updated linux kernel to 4.5.1. Yesterday I got a disk space overflow in my /home partition. Cleaned it up and rebooted, just to run into the same issue today morning. Investigations revealed that the `.xsessions-errors` had grown to tremendous 100G full of messages like: AL lib: (EE) ALCplaybackAlsa_mixerProc: start failed: File descriptor in a bad state It is - *50G per DAY!* Thinking about a possible cause and bearing in mind I've not updated ALSA recently rather than the kernel, I went to the kernel's changelog and found that version 4.5.2 fixes several ALSA-related bugs. I upgraded immediately and got rid of the error. So I advise everyone not to install the 4.5.1 kernel and suggest removing it from portage ASAP. If anyone knows how I could submit such a request, I'm all ears. Thanks for your attention! -- Regards, Yuri K. Shatroff
Re: [gentoo-user] KDE and the new plasma 5 thing
14.04.2016 11:36, Dale wrote:
Yuri K. Shatroff wrote:
14.04.2016 10:43, J. Roeleveld wrote:
No idea here, logs?
I didn't see anything relevant in Xorg.?.log (neither in messages) and
since there was no kdm which usually tracks all KDE messages I didn't
know where to look. Neither any new log files appeared.
Since kdm is gone, it's now sddm.log in the same place where kdm was.
This is what my log looks like. Yours should look something like it I
would think.
[23:29:06.330] (II) DAEMON: Initializing...
[23:29:06.334] (II) DAEMON: Starting...
[23:29:06.334] (II) DAEMON: Adding new display on vt 7 ...
[23:29:06.334] (II) DAEMON: Display server starting...
[23:29:06.334] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{baadb08a-2764-4aec-b839-6c2b7283ef79} -background none
-noreset -displayfd 17 vt7
[23:29:06.838] (II) DAEMON: Running display setup script
"/usr/share/sddm/scripts/Xsetup"
[23:29:06.842] (II) DAEMON: Display server started.
[23:29:06.842] (II) DAEMON: Socket server starting...
[23:29:06.842] (II) DAEMON: Socket server started.
[23:29:06.842] (II) DAEMON: Greeter starting...
[23:29:06.842] (II) DAEMON: Adding cookie to
"/var/run/sddm/{baadb08a-2764-4aec-b839-6c2b7283ef79}"
[23:29:06.847] (II) HELPER: [PAM] Starting...
[23:29:06.847] (II) HELPER: [PAM] Authenticating...
[23:29:06.847] (II) HELPER: [PAM] returning.
[23:29:06.848] (II) DAEMON: Greeter session started successfully
[23:29:06.865] (II) DAEMON: Message received from greeter: Connect
[23:29:22.968] (II) DAEMON: Message received from greeter: Login
[23:29:22.969] (II) DAEMON: Reading from
"/usr/share/xsessions/plasma.desktop"
[23:29:22.969] (II) DAEMON: Session
"/usr/share/xsessions/plasma.desktop" selected, command: "/usr/bin/startkde"
[23:29:22.975] (II) HELPER: [PAM] Starting...
[23:29:22.975] (II) HELPER: [PAM] Authenticating...
[23:29:23.012] (II) HELPER: [PAM] Preparing to converse...
[23:29:23.012] (II) HELPER: [PAM] Conversation with 1 messages
[23:29:23.323] (II) HELPER: [PAM] returning.
[23:29:23.353] (II) DAEMON: Authenticated successfully
[23:29:23.360] (II) HELPER: Starting: "/usr/share/sddm/scripts/Xsession"
"/usr/bin/startkde"
[23:29:23.362] (II) HELPER: Adding cookie to "/home/dale/.Xauthority"
[23:29:23.366] (II) DAEMON: Session started
[23:29:23.384] (II) HELPER: [PAM] Ended.
[23:29:23.384] (II) DAEMON: Auth: sddm-helper exited successfully
[23:29:23.385] (II) DAEMON: Greeter stopped.
I think I got a complete section of it.
Ah, I remember that one, but no, there wasn't anything related to black
screens.
I believe it was some internal problem with nvidia drivers and plasma-5
3D effects. This can explain the presence of mouse pointer and menus
flickering-through the black screen.
I'll probably repeat that a while later when I have more time. That
first post of mine was too emotional, I like to be on the bleeding edge,
even despite such faux pas. Thanks everyone for your replies!
Dale
:-) :-)
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] KDE and the new plasma 5 thing
14.04.2016 10:43, J. Roeleveld wrote: On Thursday, April 14, 2016 10:33:10 AM Yuri K. Shatroff wrote: 14.04.2016 00:49, Dale wrote: Yuri K. Shatroff wrote: Hi Dale, I'm not sure on where you got the black screen. If it is when X started, did you switch to sddm or some other compatible display manager? The old kdm isn't supported and from what I read, doesn't work. That may explain the black screen. Sddm worked as expected, not to mention its veeery slow interface (for that nvidia drivers can be blamed, but whatever). The black screen appeared after logging in. Slow interface? It works quite well on my laptop. Did you add the "sddm" user to the "video" group as mentioned in the upgrade guide? No I didn't because I had a much more blatant issue with the whole desktop than the 'SDDM display issues', I just didn't get to that. Thanks for pointing it out, next time I'll give it a try. If it after you login, did you select the write session? At first, I wasn't sure which one to pick. There is a couple at least KDE related. I think I had one that said plasma and one that said KDE wayland. I have seen wayland talked about and tried it but I got a black screen. I had to restart xdm to reset it. Then I chose plasma from the list and it worked. So, make sure you pick the right one. There were three choices for the session. By default plasma was selected, this was the one that gave me the black screen. Others didn't plain work (returned to sddm). No idea here, logs? I didn't see anything relevant in Xorg.?.log (neither in messages) and since there was no kdm which usually tracks all KDE messages I didn't know where to look. Neither any new log files appeared. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] KDE and the new plasma 5 thing
14.04.2016 00:49, Dale wrote: Yuri K. Shatroff wrote: Hi guys, 12.04.2016 08:38, Dale wrote: Howdy, Well, I went and did it. So I went and did it, too. Thank gods I made a backup. After emerging plasma-meta which wasn't too easy because of dependency hell with eg networkmanager (Use-flag on plasma-meta was off but it turned out that another dependency (`plasma-workspace`) has a quite irrelevant use-flag (`geolocation`) which pulls in networkmanager) and ruby and all, I just got a black screen with a sole mouse pointer. When I click mouse buttons, it flickers and shows a glimpse of what the desktop should be, but then again switches to black screen. I tried to remove ~/.kde4 but nothing effectively changed. Thanks but No thanks, I prefer to restore my backup. Not gonna repeat this at home. Hi Dale, I'm not sure on where you got the black screen. If it is when X started, did you switch to sddm or some other compatible display manager? The old kdm isn't supported and from what I read, doesn't work. That may explain the black screen. Sddm worked as expected, not to mention its veeery slow interface (for that nvidia drivers can be blamed, but whatever). The black screen appeared after logging in. If it after you login, did you select the write session? At first, I wasn't sure which one to pick. There is a couple at least KDE related. I think I had one that said plasma and one that said KDE wayland. I have seen wayland talked about and tried it but I got a black screen. I had to restart xdm to reset it. Then I chose plasma from the list and it worked. So, make sure you pick the right one. There were three choices for the session. By default plasma was selected, this was the one that gave me the black screen. Others didn't plain work (returned to sddm). I might add, I don't solely depend on KDE for my desktop. I have Fluxbox and some other one as a backup. If for some reason KDE doesn't work, I use one of the backup desktops to get help. Sometimes, it can be something simple to fix which is better than losing everything that was already done. For me, it doesn't matter what that backup is as long as my web browser and email program will run and is usable. If I have that, I can google and if needed post on this list for help. Thanks for the hint, it's a good idea, I also had a couple of times when a working X would be helpful but failed to start due to kde related issues. As for the new plasma stuff, I have almost all possible kde packages updated to 5.x (unstable), with the exception of kdm, kwin, settings and several others. My emerge of plasma-meta replaced these and additionally installed 78 packages, the larger half of which wasn't kde related (ruby, . What could have caused a black screen, I have no slightest idea and since it prevented me from work I gave it up. Dale :-) :-) -- Regards, Yuri K. Shatroff
Re: [gentoo-user] KDE and the new plasma 5 thing
Hi guys, 12.04.2016 08:38, Dale wrote: Howdy, Well, I went and did it. So I went and did it, too. Thank gods I made a backup. After emerging plasma-meta which wasn't too easy because of dependency hell with eg networkmanager (Use-flag on plasma-meta was off but it turned out that another dependency (`plasma-workspace`) has a quite irrelevant use-flag (`geolocation`) which pulls in networkmanager) and ruby and all, I just got a black screen with a sole mouse pointer. When I click mouse buttons, it flickers and shows a glimpse of what the desktop should be, but then again switches to black screen. I tried to remove ~/.kde4 but nothing effectively changed. Thanks but No thanks, I prefer to restore my backup. Not gonna repeat this at home. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] emerge kde-plasma/kscreenlocker: permission denied [SOLVED]
11.04.2016 17:09, Alan McKinnon wrote: On 11/04/2016 15:15, Yuri K. Shatroff wrote: Hi gentoo users, Got a strange problem. While emerging kde-plasma/kscreenlocker (as part of upgrading to the brand new plasma desktop), the build fails with the following error: * Applying kscreenlocker-5.4.90-no-SUID-no-GUID.patch ... /var/tmp/portage/kde-plasma/kscreenlocker-5.6.2/temp/environment: line 1217: /var/portage/tree/kde-plasma/kscreenlocker/files/kscreenlocker-5.4.90-no-SUID-no-GUID.patch: Permission denied I tried to run the ebuild manually and changed all permissions to a+w, but to no avail. (The patch itself applied successfully from the command line.) I don't believe it's a permissions issue. There haven't been any such issues before, and I just did a fresh eix-sync. Should I file a bug? I have the same settings as you and kscreenlocker merges for me. Alan, thanks for your quick reply! Basic checks: ls -al all the files in /var/portage/tree/kde-plasma/kscreenlocker/files/ and parent directories. Make sure they are OK, especially look for literal question marks. then run "ebuild /var/portage/tree/kde-plasma/kscreenlocker/kscreenlocker-5.6.2 prepare" and see what's at line 1217 of /var/tmp/portage/kde-plasma/kscreenlocker-5.6.2/temp/environment plus a few lines above and below. This won't be executable permissions - ebuilds are sourced, not executed. I suspect file corruption. Actually, I started to panic too early. I logged into the `portage` user and it turned out that the whole /var/portage/tree/kde-plasma directory was inaccessible to it due to 0720 permissions (I have set up rsync to use my own user and add g+w perms to `portage` group), but apparently that dir had 0700 on the rsync mirror and g+w isn't just enough :) So the problem was solved by chmod'ing the kde-plasma dir to g+rwx. As usual, an easy solution is easily overlooked. Sorry for the noise. -- Regards, Yuri K. Shatroff
[gentoo-user] emerge kde-plasma/kscreenlocker: permission denied
2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/var/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build --quiet-unmerge --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org; LANG="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j6" PKGDIR="/var/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--no-p --chmod=g+w" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X alsa amd64 avx berkdb bzip2 cli cracklib cxx dbus dri fortran gdbm iconv icu jpeg lzma mmx modules multilib ncurses nptl opengl openmp pam pcre png qt3support qt5 readline seccomp session sqlite sse sse2 sse3 sse4_1 ssl ssse3 tcpd udev unicode xorg zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2 sse3 ssse3 sse4_1 avx" DRACUT_MODULES="lvm" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc efi-64" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4 python3_5" RUBY_TARGETS="ruby20" USERLAND="GNU" VIDEO_CARDS="vesa nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON -- Regards, Yuri K. Shatroff
Re: [gentoo-user] A non-root user can delete files belonging to root. What's going on?
13.02.2015 17:31, Alan Mackenzie пишет: Hi, Gentoo. I'm clearing out dross from my home directory, as me (not as root) and I've just deleted this file: -rw-r--r-- 1 rootroot 0 Apr 11 2011 grep , simply by typing $ rm grep. I was prompted with: rm: remove write-protected regular empty file ■grep■? , to which I responded 'y'. The file is now gone. So, as a non root user, I've managed to delete a file belonging to root, to which I have no write access. This is crazy! I'm not happy about this. What's going on? The owner of a directory is able to delete any files in it. It would really be weird otherwise. -- Regards, Yuri K. Shatroff
[gentoo-user] google-chrome fails under kernel 3.18
Hi gentoo-users, Yesterday I installed and compiled gentoo-sources-3.18.0, everything seems to be in order but google-chrome just doesn't display any page (even settings), showing a blue screen with Oops instead. In Firefox, everything works as before. I tried reinstalling chrome, removing its config directory and even installing chrome-beta, but all to no avail. Yet, simply rebooting back to 3.17.4 reverted it to order. Maybe there's some important kernel config parameter or smth I've missed? (I just used make oldconfig) -- Regards, Yuri K. Shatroff
Re: [gentoo-user] [OT] LiveCDs for Uni students
On 08.03.2014 05:57, Andrew Lowe wrote: [ ... ] Too complicated. What I mean by this is that the user upon booting has options!!! Do you kick into a graphical environment, do you copy everything to memory, do you. you get the idea. The problem is that these are first year students in a common first year, they have not yet decided upon their stream, could be Civil, Chem, Mech etc and don't see any benefit in doing programming but have to pass the subject. My requirement is that it boots into a GUI, preferably straight into the environment, no username/password, has dhcp, a decent editor, a browser and gcc or clang. Andrew Hi Andrew, I could suggest you create a virtual machine image for e.g. virtualbox, with all the stuff you need. This way you ensure the student has everything you expect him/her to have, and it may be more acceptable for layman to install an emulator with the image, while being able to use his/her own OS, than to reboot each time, and this setup allows to easily save configuration options/work results. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 16:39, Mark David Dumlao пишет: On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: 24.02.2014 02:32, Alan McKinnon wrote: [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. it's obvious you haven't thought this through. consider, for a moment, that the one thing well that an init daemon is supposed to do is run programs that do arbitrary things to get the system to an arbitrary state. do you not see a problem? No. As you say, ``an init daemon is supposed to do is run programs``, until here you're right, but then you start talking about things the init doesn't do but the programs do. In your wording, an init daemon is also a DBMS, an MTA, a network startup daemon, a firewall, a getty and whatever program runs on the system. There was a post in this thread with a link to an opinion what an `ideal init` would do: just fork and exec anything in /etc/init.d or somewhere else. In the real world, it's of course not so simple. But it doesn't mean you may imply init's responsibility for `arbitrary` tasks. If I write an ASM program with an illegal instruction, is it the init's problem? If my mail/web server is DDOSed, is it the init's problem? If my HDD dies, also the init's problem? -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 24.02.2014 18:33, Mark David Dumlao wrote: On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: 24.02.2014 16:39, Mark David Dumlao пишет: On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: 24.02.2014 02:32, Alan McKinnon wrote: [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. it's obvious you haven't thought this through. consider, for a moment, that the one thing well that an init daemon is supposed to do is run programs that do arbitrary things to get the system to an arbitrary state. do you not see a problem? No. As you say, ``an init daemon is supposed to do is run programs``, until here you're right, but then you start talking about things the init doesn't do but the programs do. In your wording, an init daemon is also a DBMS, an MTA, a network startup daemon, a firewall, a getty and whatever program runs on the system. Let's try to talk you through to a soft landing here. When we say init, are we just referring to pid 1, or are we referring to something else entirely? Sorry but I think I was quite clear: An init daemon generally does one thing well. Following a Unix way design, Everything else should be done by something else. OpenRC is often spoken of in the same breath as systemd, as if they were the same kind of thing. That sounds fair but think about it for a second: Sorry but did I mention OpenRC? openrc - as most people talk about it - isn't even pid 1. as most people talk about it, openrc includes the functions.sh, the net.eth0 scripts, the script for starting your /sys, /proc, mounting local and network filesystems, setting the hostname and so on. Obviously. That is why OpenRC *can* be treated as a Unix way thing, because the whole bunch are pretty interchangeable, independent and do their own things well, don't they? They may be written in a different language from pid1, but when people talk about openrc, they are talking about that whole ball of wax. From a systems perspective - they're parts of the same thing. Even discounting the parts that you think are ridiculous, like databases and loggers, there are clearly more parts in there above than can be cleanly defined as one thing. Who gets to decide which is the one thing or not? You? Don't you rely on openrc to set your hostname? Load your kernel modules? Run your sysctl? Set any miscellaneous options in /sys? Mount your filesystems? Go ahead, define for everyone, once and for all, what this one thing is. Does this one thing init include a subsystem for reading separate environment files per-service? Isn't this just feature creep? Can't you just edit the init scripts to add those in? I mean, they are already scripts after all. And they're in /etc, they're meant to be configured. Sorry, do you mean *everything* in /etc/ is to be configured? That's a convention to put the init stuff in /etc/. You could as well put it in /usr, /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc. In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from a single linux's angle? Please note, I never say the 'linux way' but the Unix way. And you might also notice, an init system does not really much depend on the init daemon. It's pretty possible to run a SysV init daemon on a BSD system, or the opposite, because all the init daemon does is start some init scripts. Maybe /etc/rc, maybe /etc/init.d/* ... Does this one thing include service dependencies? This depends on what one thing you want the init daemon to do. In e.g. FreeBSD, the dependencies are handled by /etc/rc. Why sysv has gone for a LONG time without them, just a sequencing, and that works fine for almost all cases anyways. Isn't this just feature creep? Can't you just edit the init scripts to start any dependent services? Point is - go look at any arbitrary feature that's part of your init system and you could cry to hell and high water that it's violating the one thing, whatever that one thing is that doesn't seem to be defined. At least with systemd the parts are cleanly split off into separate executables. Yes, it's technically not needed for pid 1 to create tempfiles for other programs. That's why systemd-tmpfiles is its own tiny program, that does one one thing (create tempfiles for other programs) and nothing else. Yes, it's technically not needed for pid 1 to check your filesystems. That's why systemd-fsck is once again, a separate utility, that does one thing (run fsck) well. Yes, it's technically not needed for pid 1 to remount your filesystems readwrite. Again there's a separate utilty for that, that does nothing but just that. Okay, but can I take them out and substitute mine own easily? How? Is there a well-defined standard? Is there a well-defined objective, a target
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 24.02.2014 22:55, Mark David Dumlao wrote: [...] I didn't attribute anything to you you didn't say. It just so happens, though that there is a context to this conversation, which, if you ignore, just tends to perpetuate a lot of confusion. I am responding to questions and points in that context for the benefit of the larger conversation, not just for you. I'll be short. You also ignored much of what I asked, and tend to answer that's besides the point to things which IMO matter. If you are responding to my post, then I'm expecting you to be replying to me, rather than to the benefit of the larger conversation, if you didn't say otherwise. ;-) As for the context, I was answering to Alan's ``I've been wondering about this concept of the*nix design principles... `` which (as well as my answer) didn't mention systemd and openrc at all. In this thread, there's already a rattling mixture of contexts. I'm opting out of it, because I no longer see the benefit of the larger conversation here. Nevertheless, thank you for your time and answers. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 05:07, Alan McKinnon wrote: [ ...] We don't do error handling. We don't even try and deal with it at the point it occurred, we just chuck it back up the stack, essentially giving them message stuff it, I'm not dealing with this. You called me, you fix it. Doesn't sound like good design does it? Sounds more like do whatever you think you can get away with. Good design in this area gives you something conceptually along the lines of try...catch...finally (with possibly some work done to avoid throwing another exception in the finally). try...catch...finally *does* leave error handling to *the caller*. It only provides a more object-oriented way to error handling. It *does not* *handle* errors. Unix error design does this: exit some arb number and an error message is in $@ if you feel like looking for it Please, propose a more sound design? Take e.g. jQuery where all errors are handled by the library, it sometimes takes ages to debug why it doesn't work as expected, after a while you eagerly figure why error handling *should* be done by the caller, and the only thing the callee can do reliably is pass an error message upstream. Good error messages (and error codes, or error class hierarchy) are a different problem, but I haven't seen a more proof solution yet. Strangely, this approach is exactly why Unix took off and got such widespread adoption throughout the 70s. An engineer will understand that a well-thought out design that is theoretically correct requires an underlying design that is consistent. In the 70s, hardware consistency was a joke - every installation was different. Consistent error handling would severely limit the arches this new OS could run on. By taking a Stuff it, you deal with it coz I'm not! approach, the handling was fobbed off to a higher layer that was a) not really able to deal with it and b) at least in a position to try *something*. By ripping out the theoretical correctness aspects, devs were left with something that actually could compile and run. You had to bolt on your own fancy bits to make it reliable but eventually over time these things too stabilized into a consistent pattern (mostly by hardware vendors going bankrupt and their stuff leaving the playing field) And so we come to what Unix design probably really is: You do what you have to to get the job done, the simpler the better, but I'm not *really* gonna hold you to that. A good design is based on: - consistency - isolation and substitution of components - component reuse - thorough documentation (a free interpretation of [1]) This almost always leads to many simple components, and that is what's called Unix design principles AFAIU. The problem of Unix is that it doesn't follow Unix design principles any more. But it doesn't invalidate *the principles*. I still don't like what Lennart has done with this project, but I also fail to see what design principle he has violated. As per [1], I fail to see what design principle he has followed. [1] http://en.wikipedia.org/wiki/Software_design#Design_concepts -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 02:32, Alan McKinnon wrote: On 23/02/2014 20:18, Canek Peláez Valdés wrote: I don't think forking would attract much developers. Writing something new trying to follow the*nix design principles, but being modern and with the same features (all of them optional, of course) of systemd will have more chances; although I think it will fail because most of the people that can code better actually like the systemd design, and would prefer to contribute to it. And if you found enough of this mythical good-coders, good luck defining what it means the*nix design principles. I've been wondering about this concept of the*nix design principles... I've now concluded it's a myth, much like invisible pink unicorns. I may not be an authority, too. But please allow me to refute your arguments. Is it like the kernel? A huge monolithic chunk of code with support for modules? It ain't. No monolithic chunk of code, it's configurable. Is it like X11? A huge monolithic chunk of code that has a bizarre build system for years, and took something like 5 years of hard work to get it modular? And is 20 years behind the times? And *still* requires devs to jump through hoops to get a rendered image through a compositor and back up the the GPU? It's grown to that, but in the beginning it was (striving to be) a clean system doing generally one thing (graphical client/server) and doing it well. [1] It's not X11 devs' fault that GPUs and all that multidisplay/ multimedia stuff don't work well with client/server arch because they were designed for some other, you know which, OS. I assume if the GPU vendors had their specs opened 20 years ago, some wayland-like stuff would have been ready near that time. Is it like perl? Support every possible way to do something if it remotely makes sense to do it, no matter how bizarre the syntax? Perl (I suppose you know what it stands for) is great (probably the greatest) for what it was invented for: text manipulation/analysis. It could have been a good replacement for many things like awk, sed, tr etc. if the author were less ambitious to conquer the world with Perl. Is it like python? Pick ONE way to do it and stick with it dammit! You misquoted. The phrase is: there should be one—and preferably only one—obvious way to do it, *one* meaning 'at least one', complemented with *should be* and *obvious*. Is it like php? Do whatever you feel like? Php was a Unix design? LOL. Php wasn't a design at all. It was just another personal home pages perl script. Is it like command line text processing tools that only do one narrow thing well? [1] Perfectly well. Is it like bash? I can't find a decent description of how bash came to be except it's like Vogons - wasn't designed and didn't evolve, it just sort of ... congealed Bash or sh? What about ksh, csh, zsh etc? Well, a shell actually does two things: interactive shell and scripting. Let's ponder on how they can be separated? Not to rain on anyone's parade, but there's a prize of 40 internets up for the first person who can clearly and unambiguously define Unix design principles with specificity so that it is globally applicable. A truism: There's nothing globally applicable. Best I can come up with is Use common sense and build stuff that can be used and maintained which is wonderfully descriptive but really sucks as a definition. Something like this, but neither is it globally applicable. [1] For lack of a better term, let's just call systemd here a system controller. What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. [1] http://en.wikipedia.org/wiki/X11#Principles -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 22.02.2014 11:40, Mark David Dumlao wrote: [ ... ] Even as the complex beast it has become systemd is still simpler than the alternative of having abominations of unreliable shell scripts checking to see which version of grep and sed is used to split the command line, or whether the system uses tempfile or mktemp, or depending on perl. Well, simpler yeah, supporting only one kernel of specific versions is always simpler than trying to support everything from SunOS to NetBSD. This way, if the kernel supported only e.g. Intel IvyBridge+ with one chipset family, one graphics (VESA) and so on, it would have been incredibly simpler. Or probably is it systemd that checks whether the system uses tempfile or mktemp? Or having a new own (NIH) unit config format parser is simpler than taking one of thousands of existing ones? It is simpler for you end user. (Though dubious for users who wield shell scripts and perl.) But when it comes to reliability it's entirely wrong. I can fix a faulty shell script without having to wait for a new release. Or I can even write mine own. Can you fix systemd? ergo libreoffice. A follower of the MS-maintained strategy one black box that does everything. I always wonder what does e.g. Excel/Calc/spreadsheed need font decorations for? Or 1+2 is different from *1*+/2/? ;) desktop environments. A good DE design is just a collection of separate tools doing different things, united by some graphical design. firefox. An example of how an app once followed a non-Unix way is now failing to get back to the Unix way. And its reliability is somewhere near zero. Though, it's almost impossible now to make a simple browser which would also be cross-platform and popular. There's a holy bible of standards and quirks to support, and yet more in the development phase, for the end user to be happy. It's completely different from an init system, even all the init systems of all Unixes altogether. databases. What's wrong with them? Mostly, characteristic examples of the Unix way. Heck much of what's being said about systemd applies to postfix - there's no general case reason for me to grab some random postfix component and use it for everyday work, therefore postfix is just some closed-source monolithic virus, right? So now that there's a working postfix which is an example of a non-Unix way design, it's justified to use this approach everywhere else? -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 22.02.2014 21:21, Stroller wrote: On Sat, 22 February 2014, at 10:38 am, Yuri K. Shatroff yks-...@yandex.ru wrote: On 22.02.2014 11:40, Mark David Dumlao wrote: [ ... ] Even as the complex beast it has become systemd is still simpler than the alternative of having abominations of unreliable shell scripts checking to see which version of grep and sed is used to split the command line, or whether the system uses tempfile or mktemp, or depending on perl. Well, simpler yeah, supporting only one kernel of specific versions is always simpler than trying to support everything from SunOS to NetBSD. This way, if the kernel supported only e.g. Intel IvyBridge+ with one chipset family, one graphics (VESA) and so on, it would have been incredibly simpler. I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. … PS. Yes – it’s free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(. Good luck! Linux did indeed once support only one CPU family and one or two hard-drives, and the reason that it now supports more is that people dug into the code, submitted patches and got it fixed. Had all the original Linux developers spent their time on the comp.os.minix list, complaining oh, those splitters, they're trying to fragment the Minix community and this Linus guy should be putting his effort into improving the Minix kernel, where would we be today? Actually I don't get what you are arguing [against]. It's almost hilarious the volume of traffic expended here on this subject, especially that by the naysayers. When I first learned of systemd I did not feel favourably towards it, but those ranting against it have only given Canek a platform to convince me. I partially agree. In an emotional discussion the most probable winner (as seen from outside) is the calm one. But being calm doesn't refute all technical and `political` stuff. I personally was going to try systemd about a week ago when the discussion started. Now I'm quite convinced not to do this in the near future. No calm arguments of systemd's supporters, such as the complexity of shell scripts, the simplicity of systemd compared to the Kernel, the ease of use of journald tools, the shitload of troubles of configuring syslog, the replacement for all network setup tools, the good intents of Red Hat, etc etc, didn't convince me. Emotions pass, results remain. And whilst I'm still of two minds on which init system I'd ideally prefer, I am not under any delusions that I can influence the developers of the Gentoo distro or those of the Linux kernel (who AIUI are adding kdbus to support systemd), either by ranting about it here or otherwise. No delusions, there will always be an alternative. Nobody actually has disagreed yet with my words that in a couple of years systemd is going to dominate 90% (meaning the majority of) linux distros. But 10% hopefully will remain without it. Anyway since systemd is not intending to support any other kernels, we'll probably see other OS or stuff like Debian/kFreeBSD develop more intensively. Yet, of course, these alternatives will necessarily be poorer supported and one will have to take effort to migrate - to either the distro he used, but the version with systemd, or a different distro/OS. The amount of energy spent on this, you could have established a fork and written code by now - if y'all really want to prove your point, that's the way to do it. What point? I personally am terribly satisfied with the SysV init and shell scripts so what am I to fork and write? What a fork to establish? A fork of debian, to maintain it w/o systemd? Let that be done by debianners maybe, if they so desire. As for `ranting`, I do see a point in such talks (until these get personal), as I learn many new things (both from the posts and while trying to prove/refute the points) and I always try to ask a concrete question and answer a concrete question. Note: I do repeat *I* here because you answered *my* post. In any case, no offense, your reply is a rant, too. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 23.02.2014 00:22, Canek Peláez Valdés wrote: On Sat, Feb 22, 2014 at 1:36 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: On 22.02.2014 21:21, Stroller wrote: [ snip ] I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. … PS. Yes – it’s free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(. Good luck! Please, tell me this is sarcasm, and that you know that Stroller was quoting Linus' historical announcement (ca. 1991) of what eventually become the Linux kernel[1]. Well you sort of cracked it, but I'd rather wait for Stroller's response, esp. to this: Actually I don't get what you are arguing [against]. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
21.02.2014 12:48, Alan McKinnon пишет:
On 21/02/2014 09:03, Yuri K. Shatroff wrote:
Your idea instantly fails as the rc-service author has no idea of what
you defined ${SERVICE} to be and no way to determine what it is now.
Yes, the rc-service author does not have any idea because he is not
requested to.
${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
1. putting LINES= in /etc/conf.d/${SERVICE}
2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and
doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe
'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or
*whatever*)
3. adding this `tail -n ...` or whatever call to the init script .
4. voila.
If you feel I'm again entirely wrong please point out why.
The faults with your comments are many, and I'm not going to detail them
as that's not my job. I'm going to let you figure it out for yourself in
production why your entire approach is wrong, and simply leave you with
this:
You violate DRY.
For an example showing the general possibility to do this, I don't
violate anything. One could easily grep a syslog config , or do the
opposite (a syslog config generator from service configs), whatever. Of
course I didn't write a complete logging-aware init scripts system
because it's also not my job. But if it were, I'm pretty sure it's
doable under SysV/BSD init in compliance with DRY and ease-of-use for
admins. I'm sorry I couldn't convince you of that.
You expect the sysadmin to know they must make changes in a restart
config file when they tweak the syslogger so that somehow the init
script continues to get it right. Trust me, sysadmins are not going to
remember to do that, because expecting them to is off the wall crazy.
I repeat what I and Canek said earlier:
You've never actually DONE any of this in real life, right?
What exactly?
No, I didn't tweak any init system to print the last N log entries for a
service. No, because I don't need it and never did.
I *did* set up logging to a remote DB on SunOS and FreeBSD. But actually
you're digressing and just going personal, because the question wasn't
*how to setup logging* but *the possibility* of such a modification that
*prints the last N log entries* in the service status cmd.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
20.02.2014 09:24, Canek Peláez Valdés пишет: [ snip ] but I do not see the point, beyond as a nice gimmick. Well, I *do* see a point. Many points, actually. You want the logs for SSH, from February 12 to February 15? Done: journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service No grep. No cat. No hunting logrotated logs (the journal will rotate automatically its logs, and will search on all logs available). You can have second-precision intervals. Also, the binary format that the journal uses is indexed (hence the binary part); therefore, the search is O(log n), no O(n). With a log with a million entries, that's about 20 steps. Perhaps it's just a gimmick to you. For me is a really usefull Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) if really needed is easily achieved with databases. Not using cat and grep is not something one'd boast; rather, again, a waste of resources to recreate already existing tools. BTW, I wonder if anyone does really have logs with millions of lines in one single file, not split into files by date, service etc, so that the whole O(n) issue is moot. Well, maybe it'd be nice to have a collection of log management tools all-in-one but beyond that I don't see any advantages of systemd-journald. Its raison d'être is the new features it brings. I didn't notice any new features. It's not features that are new, but just a new implementation of old features in a more obtrusive way IMO. Additionally, the use of tail -f and grep allows me to check the logs real-time for debugging purposes. journalctl -f Checks the logs in real time. Again, [1]. Again, a brand new Wheel(c) systemctl status apache2.service (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep and the like. Not reinventing wheels. Not spending super-talented super-highly paid developers' time on doing tasks one had done about 30 years ago. I believe, not having this option is due to its simple uselessness. This way I really wonder if at some point the super talented systemd programmers decide that all shell tools are obsolete and every program should know how to index or filter or tail its output in its own, though, open, binary format. I can't get rid of the idea that systemd uses the MS Windows approach whatever you say about its open source. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
20.02.2014 15:33, Nicolas Sebrecht пишет:
The 20/02/14, Yuri K. Shatroff wrote:
(see [2]) will print the status of the Apache web server, and also the
last lines from the logs. You can control how many lines. You can
check also with the journal, as I showed up.
I believe it would be a 5-minutes job to add the capability of printing
last N log entries for a service to `rc-service status`. Using cat, grep
If I understand you correctly, what you're proposing is an analyzing
tool which works after-the-facts.
I wasn't proposing anything. I was just supposing.
I mean extracting the per-daemon logs
from a global log archive whereas systemd works the opposite way, AFAIU.
What is a 'global log archive'? Do you mean a single file where all logs
go? AFAIK you can set up syslog to log all messages into one file as
well as per-service files. So the deal is just to extract configuration
from syslog. Of course, if the services are using it, not keeping their
own logs as is usually the case of apache. As a multiuser (multi-vhost)
webserver admin I have to set up apache to log into users' home
directories, so I even don't know how many user logs there really are.
And I don't need to, because I've got my own global log. But a user is
definitely more familiar with a text file he/she can download via FTP,
than with a journalctl wrapper which he has to know how to use (and also
be granted SSH access to use), at the least which parameters to specify,
if at all usable in such setups.
You solution requires per-daemon extraction rules and have to be
maintained over time. So, postponed to errors.
I don't need such 'solutions' to non-existent problems. But if there
were a *real* necessity to pretty-print a log's tail in service status,
I think it would have been a matter of a proper setup (i.e. the service
using syslog, hence a defined log format) and not a heck more complicated.
Definetly not a 5-minutes job.
5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
20.02.2014 19:24, Alan McKinnon пишет:
On 20/02/2014 13:53, Yuri K. Shatroff wrote:
I don't need such 'solutions' to non-existent problems. But if there
were a *real* necessity to pretty-print a log's tail in service status,
I think it would have been a matter of a proper setup (i.e. the service
using syslog, hence a defined log format) and not a heck more complicated.
Definetly not a 5-minutes job.
5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.
You've never actually tried this, right?
You probably misunderstood. I don't *intend* to try this myself with
existing tools, I'm speaking of the init scripts modification. I say
that this modification of e.g. OpenRC, if required, would be done quite
easily with some assumptions.
Your idea instantly fails as the rc-service author has no idea of what
you defined ${SERVICE} to be and no way to determine what it is now.
Yes, the rc-service author does not have any idea because he is not
requested to.
${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
1. putting LINES= in /etc/conf.d/${SERVICE}
2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and
doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe
'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or *whatever*)
3. adding this `tail -n ...` or whatever call to the init script .
4. voila.
If you feel I'm again entirely wrong please point out why.
How are you going to deal with the situation with a big busy daemon that
immediately starts serving requests when started (i.e. with very little
delay)?
Either you or I seem to have misunderstood again.
The problem in question IMO was to add the output of last N log entries
to `*service status` analogous to systemctl status.
When you do tail -n $FILE, don't you *always* get the last N lines of
the file at the moment of issuing the cmd, regardless whether the file
is being added a million lines per second. I don't think that journalctl
can essentially work differently.
By the time grep, sed, awk and friends have gotten around to making
their way through a log file of varying size, the entries that apply to
restart can easy be many hundreds of log lines prior.
Why do you refer to restart?
Canek wrote:
systemctl status apache2.service
(see [2]) will print the status of the Apache web server, and also
the last lines from the logs. You can control how many lines
I don't notice anything about restart here. Just print out the last N lines.
If the question were about [re]start logs, and if in general you are
getting millions of entries written to the logs, you could use DBMS (not
necessarily relational). Maybe this *does* require some mess to setup
(we did it back in times of SunOS), but it could be resolved with
OpenRC/any SysV/BSD init (at the init-scripts level) if really necessary.
Am I wrong?
I have done this, and it does not work. I got a result and it's
relaible, but you don't want to know what it took. It's also highly
customized and useless to anything other than my highly customized setup.
Well, if you have to set up one system from scratch then probably it's
easier to use one generalized tool. But if you have an already
long-working setup which suits your needs, I believe it's relatively
easy to deploy it on other systems.
I don't like truisms but there is no generic setup suitable for
everything. Neither is systemd-journald.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
I'll try to be short. On 18.02.2014 05:09, Canek Peláez Valdés wrote: The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. Well, systemd is easier to use after a little time learning how it works. And it seems to be easier to maintain that thousands of lines of spaghetti shell code. And, I'm sorry, did you just said easier to remove? Seriously? You, as a person declaring ability to code, must understand what removal/substitution of components is important for. You think the kernel is easier to remove? Or glibc? The difference is, the kernel wasn't designed to be removed, neither was glibc. I don't think the development of such projects as Debian/kFreeBSD, uClibc etc is easy. Systemd is going to be even harder to remove -- officially limiting itself to Linux kernels. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. I knew you'd say this, ignoring my warning. Will you also claim that comparing Oracle and Postgres also doesn't have sense? Or comparing Photoshop and GIMP? As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. BTW, I asked purely technically: why not integrate everything into the kernel, since we're having a working example? -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. ? ...because there'll be nothing left to compare systemd to. The code is out there. You can choose to pick any point in time of the whole stack (ca. 2009, before systemd existed), and wrote from there if you have enough people willing and able to. So you eventually agree that it all converges on money. Enough people, competent enough in init systems, is quite 'enough' money. No one is taking anything from any one. No one is forcing nothing. No, no. No forcing. Just an offer you can't refuse. Free software is being written and offered, and knowledgeable people are choosing to use it in their distros. You are against that? Then wrote your own version with the same (or better) features. Heck of an argument. You don't like that stupid program on your TV? C'mon broadcast yours own. You don't like that road crossing with hundreds of traffic accidents? C'mon stand there directing traffic instead of the road police. Etc. You call the software free? Then put up with criticism and make conclusions on the feedback. If you don't or can't, don't claim it's free software. Nothing personal, Canek, I respect your POV and your eagerness to help people and make the world better that you always show in this ML. :) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Sorry for entering others' dialog... On 17.02.2014 21:13, Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. But it can be done, and that's a indisputable fact. A total ground-up rewrite of the whole Linux is also quite possible. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. We really don't expect that systemd's authors do anything for us. Anything they do is not for us, thanks. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. For now it's not, but take a look into the future when not a single product will be published without systemd's support, just because it's everywhere -- and since it's everywhere, then why bother support anything other? Time, money... So it's a matter of time -- you'll personally be happy with this scenario -- at first -- but think further... They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. I don't believe in Red Hat's being a corporation of Good, nor any other corporation being such, and please remember the notorious examples of almost privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost OpenOffice...) Well, there's some probability that by the time systemd occupies all linux distros, some clever RH guy (or a green soxx guy) will emerge and emerge systemd v2 which will be different ... But it's not something one should count on. [...] If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. The forward-looking people must unite, it may sound ridiculous, against systemd -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. You know what it is: everything's free but nothing to choose from. We had it before, it's called communism. Maybe it is not that bad but we don't want it anymore. Regards. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 20:50, Canek Peláez Valdés wrote: [ ... ] It's because they are cons only if you agree with systemd's view of the world. I do. Isn't there too many if you believe and if you agree? A church of systemd? ;) I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 23:26, Mick wrote: On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote: [ ... ] But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: Sorry, by the time Volker posted his message, I was already writing mine. ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? Do you disagree with my statement that in near future 90% of new distro versions will be systemd-based? Or with some other statement of mine? If the former, then I intentionally put it down to money with no regard to technical performance because money is usually what ultimately matters for maintainers. From a Software User's POV, as I said, I agree that systemd is a load of bul^W things whose significance is at the least overrated. From a technical POV, I bet, most systemd's cookies could be implemented within any other init system as well, if required. But in the Real World, software users either develop theirs own if they have the resources, or get what they are given by those who have. So my whole message was about -- whether OpenRC/upstart/anything guys have resources to show'em or eventually fall to systemd. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
17.02.2014 00:19, Canek Peláez Valdés пишет: On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Even religious. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). Oh I have read so many discussions already... :) To me, systemd's technical superiority is far not obvious. Just another init system would be, but as long as systemd is much more that one, I can't say that. It should NOT be compared to OpenRC / upstart alone, rather to a whole bunch of tools it replaces, and probably even those it's ambitious to replace. I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Well, I said that technical superiority matters little for maintainers; what matters is money. If I'd write some super-puper fancy init system and kernel replacement, who would be interested? It's not the time of Linus' rise, now you don't deal with USENET freaks, but with Intel, RedHat and other billionaire corps. Do you have the guts and means to keep up with competitors, even not about kernel/init subsystems, but a user app like mailer/browser/messenger... A kernel subsystem requires much more technical competence to maintain and is far more critical for functioning, so much more important here is not any 'technical superiority' but simply resources, human and financial, spared if using RH-maintained systemd. Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. Once you mentioned technical superiority, let's compare other stuff technically too. :) A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. You don't care about Emacs and Inkscape but do you care the same nought about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks HTTP rather than SHiTP? Do you care that once after a couple of years your systems get unmaintained and unmaintainable because the software on them becomes a load of bashed up crap which only a world's head lennart can deal with? Well, you'll say that red hat tralala, but we've seen the rise and fall of many giants e.g. Sun with their once 'technically superior' Solaris and SPARCs, well one can name many I just don't have time, also we seen MySQL bought by Oracle, and all. Nothing is eternal, and it's (Again!) quite not always technical matters that matters. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. At present, no. But the trend is clear. That's how free software works. Actually, free software (one you don't pay for) works like any other software you pay for. You probably wanted to say that's how the OSS model works but it's getting less and less true. The OSS model in many cases retains only its open source. Take MySQL, take KDE, take GNOME. Who cares about users? We do what we deem feasible regardless if you like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's technically superior. C'mon, who are you? An admin? A programmer? A Bachelor/PhD? Ha, man, we're BILLIONAIRES
[gentoo-user] emerge BUG?
Hi Gentoo users,
Looks like I've encountered a bug in emerge.
I do a sync, some updated packages are displayed, but emerge -avDu
@world doesn't see some of them, though I don't have them masked.
A today's example:
===
# eix-sync
[ ... ]
[U] == net-misc/youtube-dl (2013.11.25.1@26.11.2013; (~)2013.12.11.2
- (~)2013.12.17.2): Download videos from YouTube.com (and mores sites...)
[U] == sys-libs/timezone-data (2013h@20.11.2013; (~)2013h -
(~)2013i): Timezone data (/usr/share/zoneinfo) and utilities
(tzselect/zic/zdump)
[ ... ]
# emerge -avDu @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/timezone-data-2013i [2013h] USE=-nls 383 kB
[ebuild U ] dev-libs/libmemcached-1.0.17 [1.0.14] USE=libevent
-debug -hsieh -static-libs 0 kB
Total: 2 packages (2 upgrades), Size of downloads: 383 kB
Would you like to merge these packages? [Yes/No]
#
=
There are I think over 100 packages to be updated in total, including
the whole KDE.
When I specify a package instead of @world, it seems to work correctly:
=
# emerge -avDu kdm
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/timezone-data-2013i [2013h] USE=-nls 383 kB
[ebuild U ] kde-base/kcheckpass-4.11.4:4 [4.10.5:4] USE=pam
(-aqua) -debug 13,555 kB
[ebuild U ] kde-base/libkworkspace-4.11.4:4 [4.10.5:4] USE=(-aqua)
-debug 0 kB
[ebuild U ] kde-base/libkonq-4.12.0:4 [4.10.5:4] USE=(-aqua)
-debug {-test} 2,463 kB
[ebuild U ] kde-base/kdesu-4.12.0:4 [4.10.5:4] USE=(-aqua) -debug
-handbook 7,667 kB
[ebuild U ] kde-base/kdepasswd-4.12.0:4 [4.10.5:4] USE=(-aqua)
-debug -handbook 0 kB
[ebuild U ] kde-base/kdm-4.11.4:4 [4.10.5-r1:4] USE=consolekit pam
(-aqua) -debug -handbook -kerberos -systemd% 0 kB
Total: 7 packages (7 upgrades), Size of downloads: 24,067 kB
Would you like to merge these packages? [Yes/No]
=
I rebuilt portage to no avail.
What can it be or should I file a bug?
The output of `emerge --info` is attached.
--
Regards,
Yuri K. Shatroff
Portage 2.2.7 (default/linux/amd64/13.0, gcc-4.8.2, glibc-2.17, 3.12.4-gentoo
x86_64)
=
System uname:
Linux-3.12.4-gentoo-x86_64-Intel-R-_Core-TM-_i7-4770_CPU_@_3.40GHz-with-gentoo-2.2
KiB Mem: 8191336 total, 3943728 free
KiB Swap: 0 total, 0 free
Timestamp of tree: Fri, 20 Dec 2013 07:45:01 +
ld GNU ld (GNU Binutils) 2.23.2
app-shells/bash: 4.2_p45
dev-java/java-config: 2.2.0
dev-lang/python: 2.6.8-r3, 2.7.6, 3.3.3
dev-util/cmake: 2.8.12.1-r2
dev-util/pkgconfig: 0.28
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.12.4
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.6, 1.13.4, 1.14
sys-devel/binutils: 2.23.2
sys-devel/gcc:4.8.2
sys-devel/gcc-config: 1.8
sys-devel/libtool:2.4.2
sys-devel/make: 4.0-r1
sys-kernel/linux-headers: 3.12 (virtual/os-headers)
sys-libs/glibc: 2.17
Repositories: gentoo
ACCEPT_KEYWORDS=amd64 ~amd64
ACCEPT_LICENSE=* -@EULA
CBUILD=x86_64-pc-linux-gnu
CFLAGS=-O2 -pipe
CHOST=x86_64-pc-linux-gnu
CONFIG_PROTECT=/etc /usr/share/config /usr/share/gnupg/qualified.txt
/usr/share/themes/oxygen-gtk/gtk-2.0
CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf
/etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/
/etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo
CXXFLAGS=-O2 -pipe
DISTDIR=/var/portage/distfiles
FCFLAGS=-O2 -pipe
FEATURES=assume-digests binpkg-logs config-protect-if-modified distlocks
ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch userpriv usersandbox usersync
FFLAGS=-O2 -pipe
GENTOO_MIRRORS=http://distfiles.gentoo.org;
LANG=ru_RU.UTF-8
LDFLAGS=-Wl,-O1 -Wl,--as-needed
MAKEOPTS=-j6
PKGDIR=/var/portage/packages
PORTAGE_CONFIGROOT=/
PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times
--omit-dir-times --compress --force --whole-file --delete --stats
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local
--exclude=/packages
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/var/portage/tree
PORTDIR_OVERLAY=
SYNC=rsync://rsync.europe.gentoo.org/gentoo-portage
USE=X alsa amd64 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv
lzma mmx modules mudflap multilib ncurses nptl opengl openmp pam pcre
qt3support qt4 readline session sse sse2 sse3 sse4_1 ssl ssse3 tcpd unicode
zlib ABI_X86=64 ALSA_CARDS=ali5451 als4000 atiixp atiixp-modem bt87x ca0106
cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci
Re: [gentoo-user] emerge BUG?
20.12.2013 13:30, Alexey Mishustin пишет:
2013/12/20 Yuri K. Shatroff yks-...@yandex.ru:
Hi Gentoo users,
Looks like I've encountered a bug in emerge.
I do a sync, some updated packages are displayed, but emerge -avDu @world
doesn't see some of them, though I don't have them masked.
A today's example:
===
# eix-sync
[ ... ]
[U] == net-misc/youtube-dl (2013.11.25.1@26.11.2013; (~)2013.12.11.2 -
(~)2013.12.17.2): Download videos from YouTube.com (and mores sites...)
[U] == sys-libs/timezone-data (2013h@20.11.2013; (~)2013h - (~)2013i):
Timezone data (/usr/share/zoneinfo) and utilities (tzselect/zic/zdump)
[ ... ]
# emerge -avDu @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/timezone-data-2013i [2013h] USE=-nls 383 kB
[ebuild U ] dev-libs/libmemcached-1.0.17 [1.0.14] USE=libevent -debug
-hsieh -static-libs 0 kB
Total: 2 packages (2 upgrades), Size of downloads: 383 kB
Would you like to merge these packages? [Yes/No]
#
=
There are I think over 100 packages to be updated in total, including the
whole KDE.
When I specify a package instead of @world, it seems to work correctly:
=
# emerge -avDu kdm
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/timezone-data-2013i [2013h] USE=-nls 383 kB
[ebuild U ] kde-base/kcheckpass-4.11.4:4 [4.10.5:4] USE=pam (-aqua)
-debug 13,555 kB
[ebuild U ] kde-base/libkworkspace-4.11.4:4 [4.10.5:4] USE=(-aqua)
-debug 0 kB
[ebuild U ] kde-base/libkonq-4.12.0:4 [4.10.5:4] USE=(-aqua) -debug
{-test} 2,463 kB
[ebuild U ] kde-base/kdesu-4.12.0:4 [4.10.5:4] USE=(-aqua) -debug
-handbook 7,667 kB
[ebuild U ] kde-base/kdepasswd-4.12.0:4 [4.10.5:4] USE=(-aqua) -debug
-handbook 0 kB
[ebuild U ] kde-base/kdm-4.11.4:4 [4.10.5-r1:4] USE=consolekit pam
(-aqua) -debug -handbook -kerberos -systemd% 0 kB
Total: 7 packages (7 upgrades), Size of downloads: 24,067 kB
Would you like to merge these packages? [Yes/No]
=
I rebuilt portage to no avail.
What can it be or should I file a bug?
The output of `emerge --info` is attached.
What is the contents of /var/lib/portage/world?
Hm, really, it's almost empty except for the last packages I have added
yesterday... So that's clearly not an emerge bug, but ... Could anything
mess it up?
I have copied the system to a new HDD recently and done an `emerge
@world`, too, and everything went OK.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] emerge BUG?
20.12.2013 13:53, Neil Bothwick пишет: On Fri, 20 Dec 2013 13:47:25 +0400, Yuri K. Shatroff wrote: What is the contents of /var/lib/portage/world? Hm, really, it's almost empty except for the last packages I have added yesterday... So that's clearly not an emerge bug, but ... Could anything mess it up? Plenty, with the favourite being user error. If the packages aren't in world nor depended on by something n world, portage will not upgrade them. I have copied the system to a new HDD recently and done an `emerge @world`, too, and everything went OK. OK as in everything you expected to build built? Or OK as in no error messages appeared? The former. When I do an eix-sync, I expect that emerge -Du @world updates every package listed with the U-mark. There are no error messages anyway. Your first step would be to restore the world file from the old drive, adding the entries from the current version. I'll do this, but now I'm just wondering how I ended up with an empty world file. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] emerge BUG?
20.12.2013 14:35, Alexey Mishustin пишет: 2013/12/20 Yuri K. Shatroff yks-...@yandex.ru: 20.12.2013 13:30, Alexey Mishustin пишет: What is the contents of /var/lib/portage/world? Hm, really, it's almost empty except for the last packages I have added yesterday... So that's clearly not an emerge bug, but ... Could anything mess it up? I have copied the system to a new HDD recently Including /var? Yes, I have /var on root fs and just rsync'ed. and done an `emerge @world`, too, and everything went OK. If the correct version of the world file is lost, you may want to try to regenerate it with `regenworld'. This utility will search old emerge log files (did you copy it from old HDD?) If old emerge log files are lost too, then the script from [1] could help to recover some (major) part of the world file entries. [1] http://forums.gentoo.org/viewtopic-t-869667.html Thanks, I think a pretty easy way to regenerate @world is to edit the output of `emerge -pv --deplean`. At least I'm going to try this. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] emerge BUG?
20.12.2013 15:19, Neil Bothwick пишет:
On Fri, 20 Dec 2013 14:41:39 +0400, Yuri K. Shatroff wrote:
I have copied the system to a new HDD recently and done an `emerge
@world`, too, and everything went OK.
OK as in everything you expected to build built? Or OK as in no error
messages appeared?
The former. When I do an eix-sync, I expect that emerge -Du @world
updates every package listed with the U-mark.
There are no error messages anyway.
That shows nothing, except that the packages it did update had no errors.
You haven't said whether it emerged everything it should have, which it
probably did not.
Your first step would be to restore the world file
from the old drive, adding the entries from the current version.
I'll do this, but now I'm just wondering how I ended up with an empty
world file.
Did you copy the original over in the first place? Did you try adding
something to it and used instead of (you shouldn't do either, use
emerge -n, but people do).
No, I never had to touch the world file directly (until today), feeling
that emerge {-n|-1} is enough. I've even forgotten that it exists :)
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] emerge BUG?
20.12.2013 15:21, Neil Bothwick пишет: On Fri, 20 Dec 2013 14:50:47 +0400, Yuri K. Shatroff wrote: Thanks, I think a pretty easy way to regenerate @world is to edit the output of `emerge -pv --deplean`. At least I'm going to try this. That will add dependencies to world, which is a bad thing. You can use depclean to produce a list and then remove everything but the software you actually use. Then pass that list to emerge -n. Thank you, Neil. That's what I did. (Though I actually thought before that emerge --depclean shows only top-level packages i.e. those without any directly dependent packages. And in fact it shows the whole subtrees.) I'll be more careful now. -- Regards, Yuri K. Shatroff
Re: PORTDIR default - changing PORTDIR variable - WAS Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
On 02.10.2013 16:28, Alan McKinnon wrote: [ ... ] You should still move portage to var though. Consider it a local fix to a long-standing bug. Incidentally, do you know why the tree is in /usr? Because FreeBSD ports puts it there. Why did they do that? Because FreeBSD is not Linux; it is derived from SysV, which puts home directories and all manner of other things in /usr. I apologize but I always thought that it's Linux that derives from ATT SysV (1983), while FreeBSD derives from ... BSD (1978). How come then Linux uses SysV init and BSD does not? ;) As to ports placement in FreeBSD, I have never seen any reason to do it the other way, IMHO /var should not be polluted with huge amounts of data which is not runtime-related and may occupy tens of gigs (in case of OOo or LO compilation), rather what I always do (in FreeBSD and in Gentoo) is just put all ports/portage on a separate partition with performance-optimized settings (striping, noatime etc). And I'd really seriously object to putting portage under /var if my opinion were to be considered... I also don't like the approach of putting into /var stuff like databases and other important data. /var is system-related runtime stuff, and data should always be separate. This also helps keep /var small and neat and apply to it a different backup policy than to data and portage. It's as simple as that. -- Best wishes, Yuri K. Shatroff
[gentoo-user] KDE: unwanted dependencies
Hi people, I am about to update KDE from 4.10.4 to 4.11.1. Is it possible to avoid installing various nepomuks and akonadis which appear to be required now? I have set USE=-semantic-desktop but it doesn't seem to help. My current KDE installation is quite happy without that stuff (which also brings along tons of other crap). -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] KDE: unwanted dependencies
On 13.09.2013 14:14, Alan McKinnon wrote: On 13/09/2013 12:10, Yuri K. Shatroff wrote: Hi people, I am about to update KDE from 4.10.4 to 4.11.1. Is it possible to avoid installing various nepomuks and akonadis which No Pity. appear to be required now? I have set USE=-semantic-desktop but it doesn't seem to help. My current KDE installation is quite happy without that stuff (which also brings along tons of other crap). The KDE maintainers posted quite extensively about this some time back. Some time back I heard that KDE devs were striving to make KDE more modular. It is too hard to try and extract semantic-desktop out of the KDE build whilst not breaking everything else. What you now do is allow the stuff to be built, and disable the function in System Settings. Well why wasn't it too hard before? It's not quite obvious why one's got to extract some additional functionality, as opposed to including it when needed. A strange approach, all in all. What this in effect means is you spend an extra 20 minutes building and have a few more meg of disk space consumed by code than you never run. I personally care little about the megs, but the moral effect. Thousands of people posted much about these doubtful features and disabling them, and asked not to include them into KDE base, but all effort was vain. In trite words, KDE followed the windows way: we know better what you need... (Okay, no offense.) BTW, it seems that mysql is also a hard dependency for QT now. At least, the average joe can't be scorned any more for not having a server. Hey to all localhost admins! :) Thanks for clarification, Alan. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] look for a file type + sort
On 13.09.2013 10:24, Jean-Christophe Bach wrote:
[ ... ]
This one should work:
find /home/joseph/ -iname *.pdf -exec ls -l --sort=time {} +
-exec is not suitable here because it spawns a `ls` process per each
found entry; aside from being slow, this disallows sorting at all.
You'd prefer
find /home/joseph/ -iname *.pdf |xargs ls -l --sort=time
or, to be space-proof
find /home/joseph/ -iname *.pdf -print0 |xargs -0 ls -l --sort=time
A little late but HTH.
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] look for a file type + sort
On 13.09.2013 17:43, Mark David Dumlao wrote:
On Fri, Sep 13, 2013 at 9:36 PM, Yuri K. Shatroff yks-...@yandex.ru wrote:
On 13.09.2013 10:24, Jean-Christophe Bach wrote:
[ ... ]
This one should work:
find /home/joseph/ -iname *.pdf -exec ls -l --sort=time {} +
-exec is not suitable here because it spawns a `ls` process per each found
entry; aside from being slow, this disallows sorting at all.
This is incorrect. If you terminate exec with '+' instead of '\;', only a single
instance of the command is run - the command line is built by appending
each found file to the end of the {} placeholder.
Sorry, I'm ashamed
I didn't know about this feature. Does it also handle spaces correctly?
The only reason I see for it to fail is if you have so many files that
it can't be
passed to the argv of the receiving command.
There's always an opportunity to use tempfiles ;)
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] Re: KDE: unwanted dependencies
On 13.09.2013 17:50, Michael Palimaka wrote: On 13/09/2013 21:35, Yuri K. Shatroff wrote: On 13.09.2013 14:14, Alan McKinnon wrote: On 13/09/2013 12:10, Yuri K. Shatroff wrote: Hi people, I am about to update KDE from 4.10.4 to 4.11.1. Is it possible to avoid installing various nepomuks and akonadis which No Pity. appear to be required now? I have set USE=-semantic-desktop but it doesn't seem to help. While the USE flag has disappeared, you could try putting nepomuk and akonadi into your package.provided file. My current KDE installation is quite happy without that stuff (which also brings along tons of other crap). The KDE maintainers posted quite extensively about this some time back. Some time back I heard that KDE devs were striving to make KDE more modular. KDE upstream is, yes, and how this will affect semantic-desktop remains to be seen. so there is hope? ;) It is too hard to try and extract semantic-desktop out of the KDE build whilst not breaking everything else. What you now do is allow the stuff to be built, and disable the function in System Settings. Well why wasn't it too hard before? It's not quite obvious why one's got to extract some additional functionality, as opposed to including it when needed. A strange approach, all in all. The decision to remove the USE flag happened mostly because it maintain, and was in general not well supported anyway. There have been a number of proposals about the situation: do nothing, do a full revert, or implement some compromise. I would hope that we make a final decision about this before stabilising any 4.11 version. Clear, then I'll opt to wait for the stable 4.11. BTW, it seems that mysql is also a hard dependency for QT now. At least, the average joe can't be scorned any more for not having a server. Hey to all localhost admins! :) That shouldn't be the case. The default akonadi backend is mysql, why could explain why it's being pulled in. Yes, really, I was mislead, it is qtsql which requires setting the mysql flag, but I missed that it was due to akonadi. Thank you for the detailed answer, Michael. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] bios+gpt+grub2 boot windows
On 10.09.2013 19:14, Wang Xuerui wrote: 2013/9/10 东方巽雷 dongfangxun...@gmail.com: I format my hard disk to gpt.Then create a 1M partition at the header of hard disk ,add bios_grub flag.I can install and boot gentoo,debain and archlinux,but have no idea how to boot windows7 and 8.When I boot win7 or win8 from usb,it always complain the gpt partition and cannot install.What should I do? It's impossible to install Windows into a GPT partition if the firmware isn't EFI. This is a limitation artificially set by Microsoft; here's Microsoft's FAQ on this. http://msdn.microsoft.com/en-us/library/windows/hardware/gg463525.aspx Well, actually it *is* possible using hybrid MBR+GPT partitioning. http://www.rodsbooks.com/gdisk/hybrid.html Also google for 'hybrid mbr'. I am using this setup for multibooting several OS incl. Win 7 without problems for a couple of years. In this case, you must either revert to an msdos partition table (can be done w/o data loss IIRC), or trick Windows into believing it's running on EFI, i.e. set up UEFI DUET. Google that and you'll find an excellent HOWTO on this. Happy hacking~ An interesting idea, yet, probably, a little more complicated than hybrid MBR for the sole purpose of multibooting. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 23.08.2013 14:50, the wrote: On 08/23/13 14:39, Marc Stürmer wrote: Well... Nowadays RAM is so cheap that this is really no issue. Most recent Computers ship at last with 4 GB so what the Heck. Does that mean that I should buy hardware to match software requirements? Has it ever been different? Do people buy servers just because those are millions $ worth? Do people buy top 3D adapters for the same reason? That doesn't imply whether this fact is good or bad. That is just the fact, and it's always been. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 23.08.2013 13:42, the wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/23/13 13:21, Stroller wrote:
On 22 August 2013, at 17:08, hasufell wrote:
… I was arguing from both sides. It is buggy, crashes a lot,
consumes a lot of ressources and is able to slow down your whole
desktop, mess with audio settings and whatnot.
My granny never had these problems, using Skype on her PC.
I can assure you that skype consumes tremendous amount of ram.
Not defending Skype in any way, but tremendous is not calculable.
In these words, e.g. KDE consumes even more tremendous amounts. So what,
stop using KDE now?
As to bugs, don't think Skype has more bugs than KDE. Crashes, slowdowns
and UI troubles - KDE is plentiful with them. Stop using KDE now?
And it would be interesting to see a program (somewhat more complex than
printf('%s', 'Hello world'); ) which does not suffer from all these issues.
The main criterion of quality of software is whether it suits users'
needs. All that technical stuff is about talking. The user never sees
the code, rarely sees the resource utilization, and what he observes
most of the time is the result of using the software. If the user
manages to achieve his goal, the software is successful. If not, the
quality of code and UI and resource consumption matter nothing.
The advanced user will probably aim at minimizing RAM usage, improving
UI, opening the source code etc. but after all software quality is only
the users' perceived matching of expectations with results.
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 23.08.2013 19:58, hasufell wrote: On 08/23/2013 05:48 PM, Marc Stürmer wrote: Am 23.08.2013 12:50, schrieb the: [ ... ] The point for Skype, last time I am going to repeat that, is that it works out of the box for the normal user and the large user base. And that is still wrong. If it works for you, fine. There are enough users who have a LOT of trouble with it. Again: read the bugtrackers, I do. (Again, I'm not a skypodefender in any way) Please recommend us a bugtracker for an actively developing software which has, well, considerably fewer bugs. (Add to this: multiplatform, multiuser, network-based etc) And even better: you cannot file bug reports properly (at least from what I see the skype jira is gone) and cannot read/fix code. You are lured into believing it's a good piece of software that works out of the box, because all they do is good advertisement and increasing their userbase with some shiny features. Even worse: distro maintainers have trouble with it, need to apply hacks or don't even include it at all because of the nasty license. How does that improve out-of-the-box experience? Your view is simply different from the view of most software users. A good piece of software for them is not what is well-coded or well-maintained or well-licensed or well-whatever. All they need is matching their expectations. You may be 146% correct about troubles and hacks but this doesn't change the average joe's expectations. And yes, in most situations skype does work out-of-the-box. Sad, but true. Next you will tell us windows works out of the box. It does, in most situations. Sad, but true. I mean, wtf are you talking about? It doesn't make any sense. And doesn't even add anything to this topic. That's all about off-topic. But not acknowledging the truth doesn't add anything either. Do people hate Windows or other proprietary stuff because of its bugs? Or because of its not working OOTB? In my experience, I'd probably number a thousand more times of open-source software not working OOTB and being buggy than Windows/etc. But I still adhere to OSS. I don't think that having an 'ideal' piece of proprietary software would change an open-source adept's mind towards PS. But neither I think that emphasizing PS' problems which are common to all software will help people turn to the open-source side. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] re: xfce4-sensors-plugin pulling in nvidia-settings
On 22.08.2013 21:37, Alexander Kapshuk wrote: The version of the nvidia driver and nvidia settings I emerged is: box0=; equery list '*'|grep nvidia-driver x11-drivers/nvidia-drivers-319.32 I then emerged xfce4 as well as the xfce4-sensors-plugin (box0=; equery list '*'|grep xfce4-sensors-plugin xfce-extra/xfce4-sensors-plugin-1.2.5), which pulled in nvidia-settings of an older version: box0=; equery list '*'|grep nvidia-settings media-video/nvidia-settings-304.60 I guess it's rather obvious. The two packages x11-drivers/nvidia-drivers and media-video/nvidia-settings don't know about each other. The xfce4-sensors-plugin package needs nv-settings but it simply doesn't know that nv-settings is already installed by the (different!) nv-drivers. I think this could be reported to the maintainer of the xfce4 plugin. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] re: xfce4-sensors-plugin pulling in nvidia-settings
On 22.08.2013 22:49, Alexander Kapshuk wrote: On 08/22/2013 09:27 PM, Yuri K. Shatroff wrote: I think this could be reported to the maintainer of the xfce4 plugin. The maintainer field for the xfce4-sensors plugin seems to be undefined: box0=; equery meta xfce4-sensors-plugin-1.2.5|grep -i maintainer Maintainer: None specified Who would you recommend contacting about my original post? Thanks. As I figured in the package's changelog, some work on it is being done by Samuli Suominen ssuomi...@gentoo.org. He is also on this list, so I guess he could get involved as soon as he reads the list. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Mac Mini with Grub booting Mac OSX and Windows?!
On 30.05.2013 18:29, Tamer Higazi wrote: ... which in turn means that Windows will not use the GPT table. This is a really stupid Windows limitation, but we can't do anything about it. hm The Linux kernel can use GPT with no restrictions, however booting is another story. Booting directly from GPT requires a GPT-aware bootloader such as GRUB Intel Mac's are EFI Platforms that cannot boot Windows and that we would have to deal with BIOS Emulation that wouldn't make us of the GPT Table. fine, and wonderfull Now I have Grub2 with GPT support available, we can boot Gentoo and OsX but what about Windows which runs in BIOS emulation mode, and won't make use of the GPT table ... Making Windows boot from GPT for non-EFI systems is possible with hybrid GPT-MBR partition tables. Details: http://www.rodsbooks.com/gdisk/hybrid.html and google 'hybrid MBR' I've been using this for a while already and can say that it's doable, working and stable, but in case you occasionally run non-hybrid-MBR-aware partitioning tools such as fdisk, gparted, etc, you can face some problems (though as far as I've encountered by now, only problems related to booting windows). Anyway this is probably the only solution for multibooting. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] cups settup broken? - please help
On 14.05.2013 13:05, Helmut Jarausch wrote:
Hi,
recently I have problems with CUPS (1.6.2) with cups-filters-1.0.34
I see lots of strange error messages in /var/log/cups/error_log like
Filter pdftops not found.
but there is a /usr/libexec/cups/filter/pdftops
and then
ps: File /etc/cups/${EPREFIX}/usr/libexec/cups/filter/commandtops not
available: No such file or directory
These paths look strange.
Does any know what's going on here?
Many thanks for a hint,
Helmut.
Hi Helmut,
I also had this problem after installing CUPS. There is a trouble with
permissions, AFAIR you need to check that /var/spool/cups is accessible
to your user: that is, ensure that you're in the lp group and
/var/spool/cups group is lp. I can not be sure that this dir was the
only one to check but it was the permissions which was the problem.
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] cups settup broken? - please help
On 14.05.2013 13:42, Helmut Jarausch wrote:
On 05/14/2013 11:15:29 AM, Yuri K. Shatroff wrote:
On 14.05.2013 13:05, Helmut Jarausch wrote:
Hi,
recently I have problems with CUPS (1.6.2) with cups-filters-1.0.34
I see lots of strange error messages in /var/log/cups/error_log like
Filter pdftops not found.
but there is a /usr/libexec/cups/filter/pdftops
and then
ps: File /etc/cups/${EPREFIX}/usr/libexec/cups/filter/commandtops not
available: No such file or directory
These paths look strange.
Does any know what's going on here?
Many thanks for a hint,
Helmut.
Hi Helmut,
I also had this problem after installing CUPS. There is a trouble with
permissions, AFAIR you need to check that /var/spool/cups is
accessible to your user: that is, ensure that you're in the lp group
and /var/spool/cups group is lp. I can not be sure that this dir was
the only one to check but it was the permissions which was the problem.
Thanks Juri.
What do you mean by 'accessible' - here I have only group execute
permission, i.e.
ls -ld /var/spool/cups gives
drwx--x--- 3 root lp 32768 May 14 11:37 /var/spool/cups
Accessible really means accessible, i.e. when you are able to chdir to
it and see its contents.
Apparently, the dir lacks group read permission, i.e. it should be
drwxr-x---
the `execute` bit alone doesn't allow one to access the directory.
That is probably a portage bug or sort of.
And what do you have in /etc/cups/cups-files.conf
Actually I didn't even look there. Yes, everything is the same.
Here I still have
# Default user and group for filters/backends/helper programs; this
cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp
# Administrator user group, used to match @SYSTEM in cupsd.conf policy
rules...
SystemGroup lpadmin
# User that is substituted for unauthenticated (remote) root accesses...
#RemoteRoot remroot
Many thanks again
Helmut.
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] cups settup broken? - please help
On 14.05.2013 13:55, Yuri K. Shatroff wrote:
On 14.05.2013 13:42, Helmut Jarausch wrote:
On 05/14/2013 11:15:29 AM, Yuri K. Shatroff wrote:
On 14.05.2013 13:05, Helmut Jarausch wrote:
Hi,
recently I have problems with CUPS (1.6.2) with cups-filters-1.0.34
I see lots of strange error messages in /var/log/cups/error_log like
Filter pdftops not found.
but there is a /usr/libexec/cups/filter/pdftops
and then
ps: File /etc/cups/${EPREFIX}/usr/libexec/cups/filter/commandtops not
available: No such file or directory
These paths look strange.
Does any know what's going on here?
Many thanks for a hint,
Helmut.
Hi Helmut,
I also had this problem after installing CUPS. There is a trouble with
permissions, AFAIR you need to check that /var/spool/cups is
accessible to your user: that is, ensure that you're in the lp group
and /var/spool/cups group is lp. I can not be sure that this dir was
the only one to check but it was the permissions which was the problem.
Thanks Juri.
What do you mean by 'accessible' - here I have only group execute
permission, i.e.
ls -ld /var/spool/cups gives
drwx--x--- 3 root lp 32768 May 14 11:37 /var/spool/cups
Accessible really means accessible, i.e. when you are able to chdir to
it and see its contents.
Apparently, the dir lacks group read permission, i.e. it should be
drwxr-x---
the `execute` bit alone doesn't allow one to access the directory.
That is probably a portage bug or sort of.
Well, sorry, I must be wrong, I have the same
drwx--x---
on /var/spool/cups. But I remember that I had to change permissions
somewhere to make the filter work... I was in a hurry so I can't recall
the exact place, alas.
--
Best wishes,
Yuri K. Shatroff
Re: [gentoo-user] cups settup broken? - please help
On 14.05.2013 14:05, Alan McKinnon wrote: Read on a directory lets; you read the directory inode. In other words ls will work. To see other's spool files, you need at least read on each individual file. As a parallel, this is what makes cat work. Yes, of course; I obviously had a sudden eclipse of mind... I'm sorry. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
On 26.04.2013 12:34, Mark David Dumlao wrote: YES it is entirely about a few megabytes you don't like. A few megabytes that OTHER people choose to put on THEIR computers to NO effect on yours. YES it is entirely about a software I don't like. If other people choose to like the software is the problem of those people, but there is no way other people can (may, dare) make me like it. Note that I do not force other people to remove, avoid, or hate PA, nor do most others opposed to PA. There may be a wagon of reasons why I don't like it, from its name to its author's coding style to my experience with it 175 years ago, and for me these are all fair reasons. If you have your fair reasons to use it, please go ahead, but that doesn't imply that someone else is also going to need it, accept it, like it, or stop criticizing it. We've got freedom of speech, haven't we? ;-) If you find my arguments inconclusive, neither do I find your arguments it won't harm, it will have no effect, etc. As for `technical arguments`, much of them are as subjective as most non-technical arguments (e.g. `true unix way`, or `coding style`, or `a few megabytes` or `slowdown` as well as `NO effect` are all both technical and subjective). In the end, I humbly believe it's up to me to judge what effect there is for me on my computers. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
On 26.04.2013 16:56, Yohan Pereira wrote: On 26/04/13 at 04:05pm, Yuri K. Shatroff wrote: There may be a wagon of reasons why I don't like it, from its name to its author's coding style to my experience with it 175 years ago, and for me these are all fair reasons. Woah poettering wrote software that ran on this thing ? if so He just earned some respect in my books. http://en.wikipedia.org/wiki/Analytical_engine Considering global effort on pushing his code, I sometimes doubt that he didn't. http://en.wikipedia.org/wiki/Lennart_Poettering Since 2003, Poettering has worked in more than 40 software projects An average of 4 projects a year, statistics says. I don't rely on statistics though. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
On 26.04.2013 19:41, Mark David Dumlao wrote: On Fri, Apr 26, 2013 at 8:05 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: In the end, I humbly believe it's up to me to judge what effect there is for me on my computers. Yes, that's exactly the point. Scroll up and reread this thread, though, and you'll get the impression that some complainers seem to think that Lennart is breaking into their systems and magickally installing his 175-year old software in them. What's this about 100% of the users being forced to have pulseaudio in? Yes, being. I don't know if Lennart writes great code (doesn't seem like that though) but what I can see is that he never asks what people need. He forces his self-righteous software upon us as a sole alternative. Instead of first creating (at least talking over) protocols which are (no need to explain why) better, he creates a proggy which aims to be all-powerful all-solving (including adobe flash's bugs) and probably to conquer all the world. I don't know again. That's the impression. Maybe there's one who knows better. But AFAICT all (really) great software talks protocols and standards. In Lennart's works, I don't see any. And that said, yes, I'm being forced. Gradually it all goes for us all to have to have his works installed everywhere. Someone's justifying this by the needs of 1% users, the other one by the ease to maintain one library instead of a lot, the next one by it being brand new -- regardless. It's kinda mass psychosis. Whatever you say if not it's great, you get: oh, again you with your criticism of lennart? I have *** installed and it works, and you are kinda dumb yourself etc. It doubtlessly greatly assists in inclining my point of view towards installing lennart's stuff, yeah. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
On 26.04.2013 22:25, Canek Peláez Valdés wrote: [ snip ] You do realize that Lennart hasn't been the maintainer of PulseAudio since *BEFORE* the 1.0 release? And that now it has in fact many contributors, and they just released 3.0 in December and are getting ready to release 4.0? And that systemd/udev has dozens of contributors, from (basically) all the distributions, and that several of them are kernel developers? Just the same way as Linus is the person of the kernel, and BG is the person of Microsoft, and Moscow is the capital of Russia (don't you take literally smth like Moscow agreed to Washington's terms), we probably do not speak of personalities or capitals but there is of course some connection and responsibility on their behalf. You may not like the *design* of the stuff, but you certainly can't complaint about the *quality* of it. How can quality be apart of design? What do you then mean by quality? Quality of bytes and indentation and comments? You are not being forced to anything: in the worst case you can patch all the programs you use, the code is out there. Thanks, it really doesn't look like forcing. On the higher level, there must be some politics going on; that's also not forcing, but politics. On the lower level (that of users) one's always got the worst case to demonstrate there's no forcing. But why not go the best case? It's a big mistake to think that developing software is about writing code; NO! it's about communication. What is your software usable for except its users' usage? Ask users and try to do what they want. Forcing begins when you the developer start to think what users want without asking them, that's why (some) users don't go the windows way, the mac way or other ways and NOT the quality or design of windows or mac, nor their cost. Free doesn't just mean you get it for free -- and as if that should be the indulgence of the developers; free is (to me) the freedom of communication between them and the users, it's what is called the community! (As an example, you may notice what's going on around MySQL, losing its community; feel free to take the code and patch though, as it remains GPL'd and free!) And when I hear Do you pay them? I answer, you need money -- why code then? Go to a stock exchange and trade, there's quite a bit more money guys. That's what about money. But if you do your job, please do it with regard to how it is going to be used. You agreed to the terms; there was no forcing. This is the line that must be drawn. (Similarly, when I'd start to pay, do I buy the right for `all my dreams to come true`? Another fair question would be: do I pay *enough*? Who pays more?) It's a neverending talk anyway. Everyone has his own attitude, and probably most of us are willing to make the world better, only according to one's own perception of better. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] can't mount ext4 fs as est3 or ext3
On 25.04.2013 18:26, gottl...@nyu.edu wrote: I get the following in /var/log/messages EXT3-fs (sda5): error: couldn't mount because of unsupported optional features (240) ... EXT4-fs (sda5): couldn't mount as ext2 due to feature incompatibilities ... EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) Here is the entry in fstab /dev/sda5 / ext4noatime,discard 0 1 I am having no difficulty, but seeing the first (error) message every day in logwatch is annoying. Since all my fs are ext4 I could remove ext3 support from the kernel (3.5.4). Is that the recommended procedure? Yes, it is. Moreover, it is due to the ext3 legacy code that you are getting the EXT3 error (the first one) in /var/log/messages. Even if you remove ext3 legacy support from kernel, the ext2 and ext3 filesystems will be handled by the new ext4 code. As for the EXT4-fs message, probably it tries to mount the fs as ext2 first but it is not quite consistent for different fs, I'm getting it on some but not getting on others. thanks, allan -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
On 25.04.2013 19:48, Mark David Dumlao wrote: On Sat, Apr 20, 2013 at 5:34 PM, Walter Dnes waltd...@waltdnes.org wrote: I think you've hit the nail on the head. Complex setups require complex software... deal with it. An analogy is that an 18-wheeler semi-tractor trailer with a 17-speed manual transmission (plus air brakes that require months of training to manage/use) is much more powerful than a Chevy Sonic hatchback when it comes to hauling huge loads. But for someoneone who merely wants to zip out to the supermarket and buy a week's groceries, the hatchback is much more appropriate. Similarly, PulseAudio may be better at handling complex situations like you describe. The yelling and screaming you're hearing are from the 99% of people whose setups are not complex enough to justify PulseAudio. Making 100% of setups more complex in order to handle the 1% of edge cases is simply wrong. The complexity overhead of pulseaudio is vaaastly overstated here. Yes, as a general principle, adding unneeded complexity is bad. But that takes into account general ideas on the relative tradeoffs of having it there or not. But listen to the happy PA users here who don't feel any problem with their setup. The complexity doesn't bite them. That is not a good argument. If it were that easy, then why not just install everything -- or even simply untar all software -- at once? People say that HDDs are big now. And that would do for 99% users, wouldn't it? Instead, you're still messing with all that package managing stuff... As for the complexity of PA, one must distinguish the PA architecture complexity, its installation complexity and the complexity of managing this stuff for the user (not mentioning usage complexity which is probably negligible). I wouldn't care for the architecture complexity (although I assume it to be too complex) but what I do care about is its bad manageability. If it were to install just a package, or just remove one package, then everyone would be satisfied, including those who need the functionality. But apparently it isn't so; either all audio software is to use PA, or none at all. Analogy: 99% of people aren't going to need a11y. But the whole point of installing it by default on most desktop systems is that you can't predict who will need it, and _it does not harm_ (or very little harm) to the people who don't. So your tradeoffs are: A) no a11y unless elected by user: - for the 1%: a11y is a pain to install because the user might not even be able to see the screen (very big pain) - for the 99% use a few megabytes less on their disk. (very small gain) B) a11y for everyone unless elected removed: - for the 1%: they can use the system properly (no pain) - for the 99%: use a few megabytes more on their disk (very small pain) Obviously (B) is a better default choice. Ditto pulseaudio. Well if PA is that great then why really not do like you suggest? Probably, the problem is not a few megabytes more on their disk but that PA is just not a good alternative? And eventually is there a real big unsolvable problem for one to *install* PA when he needs? Does one really end up with black screen or another kinda PITA without PA? If not, then it's not a good analogy? But as I feel it, the talk is about choice, not PA nor complexity. I just *don't want* it. I probably don't see any harm with various akonadis and nepomuks in KDE (actually, I did see much harm, but that's another story) but I simply don't want'em. As a result (of all those useless-for-me pieces of great code removed) I have Gentoo running KDE times faster than e.g. OpenSUSE, but even without that, it's my choice and if I don't perceive or measure these times faster I believe in them. Why should I care that there is a 99% majority of users who say that some stuff are harmless or they need them on their PCs, if *I* don't need it on *my* PC? -- Here I means one. If free software is going to be really free, then it is not expected to make assumptions about what I need or what 99% users need, nor to make its use unavoidable. It is expected to provide a means to use it, as well a means to not use it. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Removing pulseaudio
sorry for breaking in... a very interesting discussion :) On 20.04.2013 19:41, Alan McKinnon wrote: ... But back to audio. My needs are simplistic - all sound goes through the laptop speakers and I need one global volume knob. When a headset is plugged into the 3.5mm jack, all sound goes there. For a mic, I have the internal one and whilst there is a 3.5mm jack for an external mic, I've never used it but I do expect it to work when plugged in and to disconnect the internal mic. Absolutely true. I also can predict that ALSA config tools are at least no more complicated than any other sound system's, including PA. Folk like Canek have complex setups that would drive me insane. I'm more than happy to fiddle with all that on my HTPC and home audio system, but never on my laptop. There's the extremes. Now, how would we determine the % numbers of how real users really use real audio? Probably there's no way. But at large, I believe it would not be a big error to say that 90% of linux users never need anything in excess of ALSA. Even that is, well, too optimistic for PA. When I heard about some sort of problems with apps when starting them in a wrong order, or bugs in Flash, or in WINE, or wherever, and *the* sound server which is designed to fix those bugs, eh... Well, just remember a couple of years ago when there was OSS, and ALSA came in to fix the problems of OSS-aware software. And now one'd say: here's *the* sound server that solves all problems of ALSA-using software, ... so the question is how long will it take to create another sound-superserver which will take care of problems with *that* already-fixing-everything soundserver? Or should bugs probably be fixed in the bugged software? Another aspect, to my mind, is that there's a misunderstanding what sound server is for. A software on its own should not need any kind of server, it should just input/output audio. ALSA is itself pretty well aware of what is input and what is output. If one needs something like playing one stream through e.g. mic and recording another stream through e.g. headphones, he'd just install whatever sound server he deems fit. But it's improper to have apps use the sound server interface directly, it's like a browser being forced to use MAC addresses instead of HTTP (or sockets). Why ever build apps with pulseaudio support (or any other stuff of that sort) if it is just a layer atop the sound system? And that's the problem with pulseaudio: it wants too much. Another example, there's music composition software for windows which uses e.g. ASIO. But it's kinda stupid to require all windows audio software to support ASIO. As for complex cases, there are some, certainly. But the rule is: don't oversimplify the complex, nor -- overcomplicate the simple. The latter seems the way to go for Lennart ... -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] [SOLVED] kdm: can't login and start KDE
On 12.04.2013 00:35, Forrest Schultz wrote: To be fair, I really don't know much about either of these processes. However, it looked like the log was describing a situation where, due to a lack of timezone information, the two processes were unable to communicate properly. Is it at all possible that this is caused by some processes defaulting to different time zones? DBUS certainly sounds like a program where correct time information would be important. On the other hand, I would think that they would both pull system time if that was the case. Also, none of things you did sound like they would have fixed that. It also seems possible that the library/package rebuild fixed something that was wrong with ktimezoned specifically. Well, there's my two cents. The problem is gone after another sync and world-update, which also affected kdelibs (due to png update) and udev 200-201. So, it wasn't possible to identify the problem's source. Just hoping it will not appear again to anyone. Anyway, thanks for your opinion. Regarding ktimezoned: there is no problem with it, and I'm still getting the same messages even now that everything is in order. if you look at the log I supplied, you see the first message is klauncher(21958) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. The message regarding ktimezoned also states: ktimezoned initialize() D-Bus call failed: Not connected to D-Bus server But dbus is up and running: # rc-service dbus status * status: started I don't know why this happens, maybe there's a dependency issue in OpenRC which allows xdm service to start before dbus, but as long as it doesn't hamper my system, I'd close my eyes on it. [OT] In general, I don't see any point in KDE's specific services such as ktimezoned, because they seem to me nothing but memory-eaters possibly doing the job already done by kernel and system tools (and more probably, doing no job at all). -- Best wishes, Yuri K. Shatroff
[gentoo-user] kdm: can't login and start KDE
Hello gentoo-users, Yesterday I completed a world update (amd64, unstable) and now I can't login with kdm. (I have kdm set as display manager in /etc/conf.d/xdm, and started from default runlevel) After booting, the login screen appears as usual. I type login/password and then a glimpse of X's default x-shaped pointer on black background appears, returning to the login screen. I don't get any sensible errors, neither in kdm.log nor in messages, all I see is: [/var/log/kdm.log] - klauncher(21958) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. kdeinit4: Communication error with launcher. Exiting! kdmgreet(21952)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: Not connected to D-Bus server kdmgreet(21952)/kdecore (K*TimeZone*): No time zone information obtained from ktimezoned - But I guess this is unrelated, since dbus is running (and restarting it doesn't help, nor does restarting xdm) Each time login fails I also see this in [/var/log/messages] - Apr 9 11:33:53 localhost kdm: :0[20396]: pam_unix(kde:session): session opened for user yks by (uid=0) Apr 9 11:33:54 localhost kdm: :0[20396]: pam_unix(kde:session): session closed for user yks - No other logs appear to change. Needless to say that kdm 4.10.1 and earlier worked properly, and no configuration files were changed during the last update. As a workaround, I just typed startx on the console (with startkde in .xinitrc) and KDE started up, so I assume the problem is somewhere around kdm. Any ideas? P.S. I had no problem with networking and udev which got updated from 197-r9 to 200 and the network interface name didn't change from eth0 (the 80-*rules file was a regular file full of commented text) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kdm: can't login and start KDE
On 09.04.2013 17:13, João Matos wrote: 2013/4/9 Yuri K. Shatroff yks-...@yandex.ru mailto:yks-...@yandex.ru Hello gentoo-users, Yesterday I completed a world update (amd64, unstable) and now I can't login with kdm. (I have kdm set as display manager in /etc/conf.d/xdm, and started from default runlevel) After booting, the login screen appears as usual. I type login/password and then a glimpse of X's default x-shaped pointer on black background appears, returning to the login screen. I don't get any sensible errors, neither in kdm.log nor in messages, all I see is: [/var/log/kdm.log] - klauncher(21958) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. kdeinit4: Communication error with launcher. Exiting! kdmgreet(21952)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: Not connected to D-Bus server kdmgreet(21952)/kdecore (K*TimeZone*): No time zone information obtained from ktimezoned - But I guess this is unrelated, since dbus is running (and restarting it doesn't help, nor does restarting xdm) Each time login fails I also see this in [/var/log/messages] - Apr 9 11:33:53 localhost kdm: :0[20396]: pam_unix(kde:session): session opened for user yks by (uid=0) Apr 9 11:33:54 localhost kdm: :0[20396]: pam_unix(kde:session): session closed for user yks - No other logs appear to change. Needless to say that kdm 4.10.1 and earlier worked properly, and no configuration files were changed during the last update. As a workaround, I just typed startx on the console (with startkde in .xinitrc) and KDE started up, so I assume the problem is somewhere around kdm. Any ideas? P.S. I had no problem with networking and udev which got updated from 197-r9 to 200 and the network interface name didn't change from eth0 (the 80-*rules file was a regular file full of commented text) -- Best wishes, Yuri K. Shatroff Hi. I have a similar problem here, since the last update from kde 4.9. But I can login with my user, I just cant using any new user. I found this problem easily, because I have a guest account, and I erase /home/guest/* once in a while. Since two months ago this account is useless. that's a little different problem ;) I remember the related discussion on this mailing list. But my kde is istill 4.10.1. It seemed nobody had the same problem, and my problem was not that bad because my own account was working pretty well. The error is exactly the same of yours, when I try to login the guest account, but when I try startx a get the following: /etc/X11/xinit/xinitrc line 63: exec: xterm: not found Can this be solved by putting an executable .xinitrc into the user's home dir? As for me, I had to put - exec /usr/bin/startkde - so that startx would start kde. I don't think it will help, because I get the same error if I try the working account. I'm using systemd, so I tried to remove consolkit support from kdm, but it didn't help. I also have a suspicion it has to do with consolekit, but there is no simple way to make sure. Is anyone else facing a similar problem? -- João de Matos Linux User #461527 Graduado em Engenharia de Computação UEFS - Universidade Estadual de Feira de Santana -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Re: stage3 only for i486?
On 03.04.2013 23:36, Alan McKinnon wrote: The reason I say Gentoo shouldn't worry about installers is that the typical person installing Gentoo already knows about chroots. Someone who doesn't is unlikely to consider Gentoo at all (unless they are looking to rice, but we long since moved past that). As for me, the Gentoo installation process is really much easier than that of some installer-based distros. Regardless of knowledge of what chroot is, if one follows the (very well written and detailed) installation docs, he'd get Gentoo installed with far less effort than trying to make out what all these fancy buttons and menus mean in a graphical installer. And from an already-user-of-another-distro point of view, it's even more attractive that he can install and tune Gentoo from his already-installed linux, not even wasting time writing CDs, booting and stuff. And the guys around here confirmed that they hadn't had problems with chroot :) This idea will of course not be popular, I'll be told I'm trying to be elitist, and so the search for the perfect installer will continue unabated Well, an installer certainly would find its users. But none is perfect, and writing another (imperfect) one exclusively for Gentoo is sort of wasting time. A true Gentoo way IMO would be a selection of installers on the installation medium ;-) But AFAICT it is this idea that wouldn't be popular, rather than leaving no-installer at all. Regarding elitism, can the absence of an installer be considered elite? :) I'd rather call 'elite' e.g. the OpenSUSE installer (a claim for elite, at least). Probably it's time for me to agree with the 'Gentoo is what it is' pattern I had argued against a month ago. =) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Updating our live servers. I'm scared!
On 28.03.2013 21:49, Michael Orlitzky wrote: On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated? I guess this is related to the recent profile upgrade (as of 2013-02-10). In my $ eselect news list I get the last news item related to this upgrade. As it states, Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). this formally requires a new profile tree with EAPI=5. So, read the news item, emerge portage, then # eselect profile and you're done. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 12.03.2013 22:09, Volker Armin Hemmann wrote: Am 12.03.2013 12:51, schrieb Yuri K. Shatroff: The starting point has to be someone identifying the problem. When you come e.g. to a car service and say, 'my engine is not working properly e.g. ignition fails or sort of', do you expect the mechanic to answer, 'hell why are you coming to me? you know the problem, c'mon fix it yourself'? no, because I am going to pay a shitload of money. See the difference? So what if the problem be posed like: You found an issue. Here's my bank account. The more you pay, the quicker you get it fixed (that is not personal, just a view) :) Nobody is paying me to hang around on this list. A list that is full with threads about problems that are: occuring every odd month, so a little search would have answered the question obvious user errors caused by stupid behaviour or easily fixable with a little bit of thinking and/or using google. Bonus points: people being pissy if pointed out. Well, you're not paid for the answers to these petty bugs, too :) I mean, if you think one's run into his own stupidity, you're not required to answer him :) At some point you have three choices dealing with this: go away, because the shit isn't worth it anymore swallow it, show your nicest smile and go on in the hope that someday somebody might grow up become an asshole. I have chosen option number three. I admit it freely. There are very few people on this list whose opinion I really care about. Those people earned my respect. So why staying and act like this? Because sometimes people are ok. Sometimes there are good threads. Because some people do see the pattern. Others realize that a bit of own research means a lot of time saved. Their own time. Learning something. Stuff like that. Btw, Daniel? cool reaction. I liked that. Really, I thought from the beginning that you're kinda acting :) and Daniel apparently realized that, too. Why I started this talk, it was probably me not quite knowing your way of acting. But I never thought anything like you are a real asshole :) Or even more of it, 'your car is what it is, you wanna drive -- buy a limousine for a couple hundred grands'? you are proposing that. 'Oh, this car needs manual intervention and some thinking. Mod your car to turn it into Carbuntu! It will do everything for you! Even driving! And breaking!* *except in icy conditions or raining. There will be no warning. hell, even limousines break under conditions usually viewed as 'normal'. :) What I said was a reply to if you want things fixed, use ubuntu Though I can't perceive ubuntu as a limo versus gentoo as a bad car; to me, it's rather the opposite :) but when one answers like that, gentoo is what it is, go use my_unfavorite_OS that sounds like I said. (that means, kinda pejorative towards gentoo. That's another thing I was trying to highlight) Yes, you can expect that a gentoo user is more familiar with the things but you can't expect everyone capable of everything. And clearly, there are people who'd do it better than an average gentoo user. This is not a unique situation, there are other out of tree drivers that give such a message, and plenty more that don't. All it needs is for someone to take the time to fix it - rather than demanding that someone else fixes it for them. Yes, that's it -- if you can't do it yourself, just inform someone who has the time and ability to fix it. And no profound discussions about what gentoo is and what it is not. Because (it's my humble opinion of course) he who discusses the most does the least. have a look at the checks in ati or nvidia drivers, create a suitable patch for every other driver. Not that hard. If you want to do it. I don't. Seriously. Perhaps I'll try. Thank you for expressing your point of view, after we discussed you behind your back :) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 11.03.2013 21:47, Volker Armin Hemmann wrote: Am 11.03.2013 14:00, schrieb Yuri K. Shatroff: [ quoting stripped ] sorry for breaking in, but... (to Volker Armin Hemmann) 1. If this driver is superfluous as you say, then why does it ever exist in portage? because it exists? gnome is there too. Or systemd AND openrc. mrxvt, rxvt AND urxvt. well, I guess, you won't have systemd AND openrc installed together even if you try, that's what portage is for. Is there any obstacle of using *rxvts together? I don't know but do not think it critical. and who's going to blame you for using gnome? 2. Since it does exist, then probably it would be much nicer to user to show him a notice when he (user) tries to compile it on a kernel which has native support for the device, or moreover an unsupported kernel installed, than blame user for that? no, this is gentoo. You are supposed to do your homework. No training wheels. Again, following your logic, why not just let the user himself ./configure make make install as in old days? What is portage for? 3. Why does the ebuild *not* check for supported kernel version or breaking APIs/ABIs? why should it? See above. You can't know if in the future something might change. That is a testing issue. Of course, one can never know what will change, or whether the code contains a bug (before one is detected), but when someone *does* stumble upon such issues, it is up to maintainers to update portage to prevent the issue... that's what portage is for, isn't it? That said, the topic starter has run across an issue and I assume the action to be taken by the package maintainer is to add a test against kernel compatibility and eligibility of the native driver, so that in the future the issue not rise again. Am I right? Or do I completely misunderstand the purpose of portage, and everything? 4. How and why would you expect to force all users to grep thru kernel src in search for a driver they might need, especially when the portage explicitly lists this driver? Also sometimes kernel drivers' description is not quite consistent and it is not easy to figure out whether it supports exactly yours card/chip/device, or moreover find it by grep. All kernel source? grep? Nope. Just reading a bit of help text. Maybe using google. Doing it once. As I said, there is not always good help text for kernel options. Then you have a working setup you can use for the rest of eternity (or the next couple of years...) Okay, and when someone like the topic starter *did* have a working setup with the superfluous driver from portage, ... do you feel the logic? :) When should one realize that this setup is no more working? I guess, just after it stopped working, right? :) Of course, again, if one is really concerned he will check each kernel release or whatever for the new stuff he's concerned about, but when all *worked*, why should he? 5. After all, linux and gentoo in particular are *not* developer-only-oriented systems, and it is up to maintainers or whomever to make them more user-friendly. Yes, it is not fair of a user to blame someone for breaking APIs etc. but neither it is fair to blame the user for not knowing everything as I bet nobody knows everything about linux kernel. oh, so gentoo is for ubuntu users? Well, why not use ubuntu in the first place? so, according to that, everyone who's striving to get linux/gentoo/whtever more user-friendly (including portage's key features) is an ubuntoid? You know, I came from FreeBSD where you're supposed to do much more work by hand, and after a dozen years I'm a little bit tired of that. I *can* do without things like portage's colorful output, for example (although it's helpful most of the time). But I really dislike things broken e.g. on `portupgrade -aR` and the sort and I can *not* call a system which allows that a quality system. That sort of user-friendliness has nothing to do with ubuntism (we know better what you want) and visual beauty: that's about quality. (I know that there's no absolute quality, but when a system tends to fail, and justifies that with user not having googled or having taken a way we, devs, didn't ever think to go -- it's at least incorrect if not arrogant.) But I feel generous right now. You might have a point there. That does not invalidate the 'remove kernels before testing' criticism from the list nor does it solve the 'insisting to use the latest kernel release instead of stable series' problem. That's right, I was just feeling like the words you said towards the topic starter were a little harsh, and wanted to have him a little acquitted :) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 12.03.2013 12:46, Alexander Schwarz wrote: Am 12.03.2013 08:33, schrieb Yuri K. Shatroff: Again, following your logic, why not just let the user himself ./configure make make install as in old days? What is portage for? Following your logic, if there's even one tool to make life easier everything has to be absolutely easy. So we should now utilize fancy wizards? Once again, that's following your logic. not has to be easy, but definitely, with such purpose. Do you disagree? Perhaps you reckon that the whole purpose of computing is to make life harder? :) That is a testing issue. Of course, one can never know what will change, or whether the code contains a bug (before one is detected), but when someone *does* stumble upon such issues, it is up to maintainers to update portage to prevent the issue... that's what portage is for, isn't it? That said, the topic starter has run across an issue and I assume the action to be taken by the package maintainer is to add a test against kernel compatibility and eligibility of the native driver, so that in the future the issue not rise again. Am I right? Or do I completely misunderstand the purpose of portage, and everything? First of all: Gentoo relies on volunteers to do work as testing. If something fails they CAN report it (like he did via this userlist). You're requesting enterprise features (everything tested to a great extent for every piece of hardware)? That's cool, because you can help. Just invest some time and help testing, everyone would be grateful. Without those reports portage can't know. It's a tool and not a thinking human being, as such it's limited in many ways. How should it know that something will break other things if nobody tells it? The case in question is exactly that: the user (Daniel Wagener) experienced an issue and reported it. He was *the* tester. He encountered a problem. He helped. He wrote *the* report. I believe he is to be thanked, rather than to blame. Maybe he expressed his feelings too harshly, but it's comprehensible to an extent. 4. How and why would you expect to force all users to grep thru kernel src in search for a driver they might need, especially when the portage explicitly lists this driver? Also sometimes kernel drivers' description is not quite consistent and it is not easy to figure out whether it supports exactly yours card/chip/device, or moreover find it by grep. All kernel source? grep? Nope. Just reading a bit of help text. Maybe using google. Doing it once. As I said, there is not always good help text for kernel options. I tend to agree but then again: why even bother compiling the Linux kernel if it's too tedious? Not quite. The big deal is not compiling the kernel itself, but finding out options which are applicable or conversely useless for one. And don't say that's an easy task even for those who are familiar. I personally am not always in mood to tinker with those new CONFIG_SOMETHING_WHICH_NOBODY_YET_UNDERSTANDS_WHAT_IT_S_FOR_AND_IS_GONNA_BE_RENAMED_AFTER_TWENTY_EIGHT_VERSIONS which neither kernel.org nor google can clearly explain. But then it turns out that you need that (or need that removed) for another thingy to work. Probably the task of just compiling the kernel appears to user much more horrible than it really is. Not counting the options... Then you have a working setup you can use for the rest of eternity (or the next couple of years...) Okay, and when someone like the topic starter *did* have a working setup with the superfluous driver from portage, ... do you feel the logic? :) When should one realize that this setup is no more working? I guess, just after it stopped working, right? :) Of course, again, if one is really concerned he will check each kernel release or whatever for the new stuff he's concerned about, but when all *worked*, why should he? There are distributions out there who take care of *this*. Instead of utilizing them you're trying to redefine Gentoo in a manner that more suits you. This is highly illogical, as alternatives are out there with the exact same thing you'd like to see. Sorry I didn't get what you meant by *this*. All I'm trying to say is that every software is for the user, and blaming user for software deficiencies is unfair. I regard the case in question as a deficiency. Would you disagree? I can't find a basis to think the opposite, but if you can, I'd be interested. :) so, according to that, everyone who's striving to get linux/gentoo/whtever more user-friendly (including portage's key features) is an ubuntoid? You know, I came from FreeBSD where you're supposed to do much more work by hand, and after a dozen years I'm a little bit tired of that. I *can* do without things like portage's colorful output, for example (although it's helpful most of the time). But I really dislike things broken e.g. on `portupgrade -aR` and the sort and I can *not* call a system which allows that a quality system. That sort of user
Re: [gentoo-user] kernel 3.8 and external drivers
On 12.03.2013 14:30, Alan McKinnon wrote: On 12/03/2013 12:01, Yuri K. Shatroff wrote: Following your logic, if there's even one tool to make life easier everything has to be absolutely easy. So we should now utilize fancy wizards? Once again, that's following your logic. not has to be easy, but definitely, with such purpose. Do you disagree? Perhaps you reckon that the whole purpose of computing is to make life harder? :) You know, this general topic rears it's head about every six months. The answer never changes: Gentoo is what it is, it works a certain way for a reason. Maybe you like it, maybe you don't. Either way that is not going to change anytime soon. What you could do is pitch in and do all the same heavy lifting that our long-term devs have done, and be the change you want to see in the world. That might involve dealing with the protestations of the existing devs though and they will likely quote the Gentoo is what it is line. So, who argues? Gentoo is what it is just like everything is. I only don't see in that fact any reason for driving off users when they find issues. One could say: oh crap, it's an issue, or more probably, okay we note that and get it fixed in a couple of our free time units Instead people immediately take on the face of almighty gods, and start a long talk about what gentoo is, spending their own time, and others' time (who read it) for just saying not too meaningful, if quite meaningless it is what it is (with some perceived connotation you fool it's not your business). You think I want to change the concept, the design, or any feature of the software, or to have it changed. But I humbly don't want anything except perhaps a little different attitude toward the user. Please forgive me if I said that not quite clearly. I think you just don't understand the group and technical dynamics that are at work here. Gentoo is not a product, it's a tool kit. Nobody ever claimed that drivers moving in and out of 3rd party vendor space to and from mainline would be tracked and dealt with and documented. It is up to the user to track that and decide what they want to use. It is the user that must be aware of possible incompatibilities between his chosen packages and deal with the results. A Gentoo system cannot possibly work any other way - you built the thing using provided tools, deal with th result of your creation. Is it a design problem or a big change of principles to fix a package to check kernel compatibility? (in this case) Is it impossible or too hard to fix? Is confirming an issue or fixing it a stain on the reputation of yours, gentoo, linux or whatsoever? Is that petty issue worth so long a discussion about the philosophy of gentoo vs your_unfavorite_OS? :) I can understand that it is not possible to track everything and that there are more important things to do. But I can not imagine one protesting against an improvement on the sole base that we are not your_unfavorite_OS :) I don't deny user's responsibility for what he's doing. But I don't see a reason not to improve a package after a user found an issue and thank him for that (at least not blaming him) :) But please don't count as if I was demanding something, these were but philosophical questions. :) I don't see why you are getting so upset. The OP asked a question, he got an answer. He seems OK with it, so why are you getting offended on his behalf? In no way. I don't know if it is my English that sounds to you so differently from what I'm trying to say. What I could be upset with, is that this story is turning into attacks on me which have no basis except misunderstanding. I only have to repeat that I thought the words said to the OP a little harsh and wanted to defend him because everyone once gets into such a situation for the first time, and experience is what had been needed most when you hadn't it :) so that he wouldn't take it too hard :) I only wanted to reconcile everyone and instead got blamed myself. But that's quite common, so I'm not upset even with that :) I hope I have not insulted anyone either. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 12.03.2013 14:44, Neil Bothwick wrote: On Tue, 12 Mar 2013 12:30:57 +0200, Alan McKinnon wrote: not has to be easy, but definitely, with such purpose. Do you disagree? Perhaps you reckon that the whole purpose of computing is to make life harder? :) You know, this general topic rears it's head about every six months. The answer never changes: Gentoo is what it is, it works a certain way for a reason. Maybe you like it, maybe you don't. Either way that is not going to change anytime soon. What you could do is pitch in and do all the same heavy lifting that our long-term devs have done, and be the change you want to see in the world. That might involve dealing with the protestations of the existing devs though and they will likely quote the Gentoo is what it is line. On the other hand, if you file bug report with a patch to the ebuild that checks the running kernel version and outputs an elog message of you might want to try the in-kernel drivers. They may simply say thank you. The starting point has to be someone identifying the problem. When you come e.g. to a car service and say, 'my engine is not working properly e.g. ignition fails or sort of', do you expect the mechanic to answer, 'hell why are you coming to me? you know the problem, c'mon fix it yourself'? Or even more of it, 'your car is what it is, you wanna drive -- buy a limousine for a couple hundred grands'? Yes, you can expect that a gentoo user is more familiar with the things but you can't expect everyone capable of everything. And clearly, there are people who'd do it better than an average gentoo user. This is not a unique situation, there are other out of tree drivers that give such a message, and plenty more that don't. All it needs is for someone to take the time to fix it - rather than demanding that someone else fixes it for them. Yes, that's it -- if you can't do it yourself, just inform someone who has the time and ability to fix it. And no profound discussions about what gentoo is and what it is not. Because (it's my humble opinion of course) he who discusses the most does the least. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 12.03.2013 15:51, Dale wrote: You may want to know, Volker is quite known for being harsh to use your word. Most of us here, just ignore it. Dale :-) :-) :-) On 12.03.2013 15:51, Alan McKinnon wrote: So don't overthink what happens around here. The reality is more like this: user1: I think I made a mistake user2: Yes you did. It was a colossal dumbass mistake and you acted like an idiot user1: h, yeah. Well I guess I asked for that. user2: yes you did :-) Wanna go grab a beer? I wasn't too far from taking it this way :) Maybe the philosophical talks are what makes your brain rest after a long developer's working day ;) Just hoping I've not wasted your time guys :-) -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] kernel 3.8 and external drivers
On 11.03.2013 03:05, Daniel Wagener wrote: On Sun, 10 Mar 2013 21:53:42 +0100 Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 10.03.2013 19:28, schrieb Daniel Wagener: Hello, I ran into some trouble about an hour ago… My workstation has an onboard Realtek Ethernet which only works with the r8168 driver. Unfortunately, this driver is not in the kernel, but available to be compiled as a kernel module. (I guess because of som patents) That worked for quite some time, until i thought hey, you got an hour of time, your workstation is still on 3.7.4, why don't you just upgrade it to 3.8.2? So I did, only to find out that Linus and his friends changed the way drivers are initialized… (__devinit got unsupported for example) Of course, the guys who wrote that r8169 have not changed their code yet. tl;dr: My network is broken since 3.8.0. So for an immediate fix I am emerging 3.7.10 (since emerge --depclean deleted the Kernel source when it found the source fo 3.7.8 which got removed as soon as 3.8.2 was emerged…) to get it working again. For the long run im thinking of buying a PCI(e) card with Kernel support. Or maybe, if I find some time I will fix the driver myself. My question now is: Who should I talk to so something like this does not happen again? A certain gentoo dev, who could issue warnings on emerging kernels, something like excerpts from the changelog? Myself, because I missed what I described above? The devs of the r8169? Linus co for breaking things? Myself bcause I forgot something else? Realtek? Or someone completely different? so, you are using a superfluous external driver. Despite the fact that external drivers are prone to breaking you insist on using the latest kernel, instead using the latest kernel of one of the stable kernel series like 3.4. To add insult to injury you remove kernels after installing instead of after testing. well… I guess that sums it up… :( sorry for breaking in, but... (to Volker Armin Hemmann) 1. If this driver is superfluous as you say, then why does it ever exist in portage? 2. Since it does exist, then probably it would be much nicer to user to show him a notice when he (user) tries to compile it on a kernel which has native support for the device, or moreover an unsupported kernel installed, than blame user for that? 3. Why does the ebuild *not* check for supported kernel version or breaking APIs/ABIs? 4. How and why would you expect to force all users to grep thru kernel src in search for a driver they might need, especially when the portage explicitly lists this driver? Also sometimes kernel drivers' description is not quite consistent and it is not easy to figure out whether it supports exactly yours card/chip/device, or moreover find it by grep. 5. After all, linux and gentoo in particular are *not* developer-only-oriented systems, and it is up to maintainers or whomever to make them more user-friendly. Yes, it is not fair of a user to blame someone for breaking APIs etc. but neither it is fair to blame the user for not knowing everything as I bet nobody knows everything about linux kernel. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Fontconfig messed up my fonts
On 05.03.2013 01:39, Alan McKinnon wrote: On 04/03/2013 22:48, Yuri K. Shatroff wrote: Hello gentoo users, Today I updated my system, including fontconfig from 2.9.0 to the latest unstable 2.10.2, and after reboot I was quite unhappy to see all my fonts become ugly, well, can't describe exactly, kind of as if back in 1980s. (not that antialiasing disappeared or bad hinting, it was just the fonts being ugly -- a well antialiased, hi-res crap) I don't know the reason, but I don't think the problem was in the /etc/fonts/conf.d settings, at least I didn't notice major changes after the update (using diff). And all the stuff like lcdfilter remained enabled. I didn't have any special settings, neither in /etc/fonts/conf.d, nor in my home dir or elsewhere, because I really enjoyed the default rendering style. So after all I downgraded fontconfig and the fonts' rendering is restored and now I enjoy it again, so I deem the issue to be the problem of the fontconfig-2.10.2 package. Regardless of whether it's configuration- or library-related, with the latter more likely, one wouldn't like package updates to break existing setups. P.S. I've just thought it could be fonts cache which I noticed to contain entries as old as September, but if the new package can not work with old cache, I believe its ebuild should clear it, shouldn't it? Well, it's probably not fontconfig, it's more likely the GUI software you use that has issues. It's hard to imagine a modern GUI software rendering fonts bypassing the font rendering engine. It's not kind of pixel-art, you know :) And moreover, see below. fontconfig-2.10.2 is fine here with KDE-4.10 apps and most of Mozilla's stuff. I have updated @world to unstable as of the date I was writing, incl. latest KDE and *zillas. What GUI software do you run that has issues? And is it ALL apps, or just a few you use often and might notice it more? Yes, it is ALL apps. That's why I almost immediately began to blame fontconfig, and eventually downgraded it. Again, as usual, the problem occurring with my setup is not due to occur with another one's, it might be the stars misaligned corrupting bytes in memory during compilation, or whatever, but the evident cause was fontconfig because otherwise I can't explain how downgrading it did help. -- Best wishes, Yuri K. Shatroff
[gentoo-user] Fontconfig messed up my fonts
Hello gentoo users, Today I updated my system, including fontconfig from 2.9.0 to the latest unstable 2.10.2, and after reboot I was quite unhappy to see all my fonts become ugly, well, can't describe exactly, kind of as if back in 1980s. (not that antialiasing disappeared or bad hinting, it was just the fonts being ugly -- a well antialiased, hi-res crap) I don't know the reason, but I don't think the problem was in the /etc/fonts/conf.d settings, at least I didn't notice major changes after the update (using diff). And all the stuff like lcdfilter remained enabled. I didn't have any special settings, neither in /etc/fonts/conf.d, nor in my home dir or elsewhere, because I really enjoyed the default rendering style. So after all I downgraded fontconfig and the fonts' rendering is restored and now I enjoy it again, so I deem the issue to be the problem of the fontconfig-2.10.2 package. Regardless of whether it's configuration- or library-related, with the latter more likely, one wouldn't like package updates to break existing setups. P.S. I've just thought it could be fonts cache which I noticed to contain entries as old as September, but if the new package can not work with old cache, I believe its ebuild should clear it, shouldn't it? -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Delayed update semantics
On 15.02.2013 00:58, Daniel Frey wrote: On 02/14/2013 11:26 AM, James wrote: Hello, Context: Stable Systems with a few newer packages (unmasked) in portage. --snip-- So, my latest ideas is to sync up and then wait one week before acutally installing those new packages. This would allow the fodder that the good folks on this list catch, bitch about (um, I mean file bug reports) and fix, to occur first; then I can complete the package update cautiously avoiding an emerge sync. I suppose you could set up a weekly cron job (say on a Saturday) to do something like: emerge -fuDN world proposed_change.txt AFAICT, if you do not really do an emerge --sync, this command will repeatedly show nothing. Then a few days later (say Wednesday?) email that file to yourself so you know what changes are being proposed. You surely know, there is a great toolset, eix, which has eix-sync command that does emerge --sync and shows all updated ebuilds. But anyway, to update a package, you'll have to sync. When time permits I CAN CHOOSE to emerge sync and then immediately update the packages and parse through the issues mostly. Call this the stable-stable approach to gentoo updates. IMHO that is not a solution: rather, a solution is not to update world but pick single packages to update. Most software does not *require* an update, unless there are security/stability issues. So doing a world update to track such issues is kinda hunting sparrows with a mortar. And practical experience has it that it works, and don't touch it. Pretty often some unnecessary update causes an unnecessary mess, even if the dev guys put it as stable. A delay after emerge --sync is pretty useless because you end up with a (week-)old portage tree, so to fix any possible bugs found that week, you'd do another sync so... you see. For the purpose of stability, I don't see an alternative to doing emerge --sync but singling out packages to update rather than updating world. In the real world, there's no 100% secure way to be 100% secure, you know. You just choose the path you deem more suitable based on risk/work and efficiency/work relations. -- Best wishes, Yuri K. Shatroff
[gentoo-user] A bug in ALSA?
Hello gentoo-users, I've got a Samsung laptop with Intel HDA sound card (Realtek ALC269VB ) Yesterday I updated software (it was about a month old; I did a eix-sync and emerge -Du @world) and somehow sound disappeared: the kernel module (snd-hda-intel) still loads and the devices get detected (the aforementioned Realtek codec and HDMI codecs). alsa-mixer also seems to function. At least, it shows the sound card and allows to change volume levels. (in /sys there are also entries for sound/card0) But in KDE, the Kmix complains of the device not working, mpg123 says cannot find card 0, etc. Before the update, everything worked, the kernel version was 3.7.0. I even installed kernels 3.7.4, 3.6.11, with many combinations of HDA-related options and module parameters, all in vain, now I installed 3.7.4 with ultra-verbose DEBUG enabled for ALSA and that's what I'm getting: === BEGIN /var/log/messages === snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X ALSA sound/pci/hda/hda_intel.c:3150 chipset global capabilities = 0x4401 ALSA (many similar messages) input: HDA Intel MID Mic as /devices/pci:00/:00:1b.0/sound/card0/input8 input: HDA Intel MID Headphone as /devices/pci:00/:00:1b.0/sound/card0/input9 BUG: unable to handle kernel NULL pointer dereference at 0005 IP: [811dd420] strcmp+0x10/0x30 PGD 119028067 PUD 119029067 PMD 0 Oops: [#1] PREEMPT SMP ...(registers dump)... Call Trace: [a00473d6] card_id_ok.part.5+0x46/0x80 [snd] [a00475fb] snd_card_set_id_no_lock+0xeb/0x150 [snd] [a0047725] snd_card_register+0xc5/0x290 [snd] [a0138a29] azx_probe_continue+0xa4/0x159 [snd_hda_intel] [a0138e81] azx_probe+0xd9/0x116 [snd_hda_intel] [811fb319] pci_device_probe+0x79/0xb0 [8126aa4a] ? driver_sysfs_add+0x7a/0xb0 [8126abdc] really_probe+0x5c/0x210 [8126ae9d] driver_probe_device+0x1d/0x20 [8126af3b] __driver_attach+0x9b/0xa0 [8126aea0] ? driver_probe_device+0x20/0x20 [8126922e] bus_for_each_dev+0x4e/0x80 [8126a859] driver_attach+0x19/0x20 [8126a410] bus_add_driver+0x180/0x270 [a010c000] ? 0xa010bfff [8126b455] driver_register+0x75/0x150 [a010c000] ? 0xa010bfff [811fa3b3] __pci_register_driver+0x43/0x50 [a010c01e] azx_driver_init+0x1e/0x1000 [snd_hda_intel] [810001fa] do_one_initcall+0x3a/0x160 [81088bf9] sys_init_module+0xb9/0x220 [813bf392] system_call_fastpath+0x16/0x1b ... ---[ end trace d00fdb0cd6665b52 ]--- === END /var/log/messages === As one can see, the line BUG: unable to handle kernel NULL pointer dereference indicates a bug, doesn't it? If it is a bug, what should I do? (I have ~amd64 in keywords, pulseaudio is disabled, alsa enabled in USE flags) Strangely enough, I've got another laptop (a little newer model of Samsung), also with Realtek, and there the software update didn't cause any problems. Thanks in advance for any ideas. -- Best wishes, Yuri K. Shatroff
