Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
On Tue, 28 Aug 2012 07:46:30 +0530 Shridhar Daithankar ghodech...@ghodechhap.net wrote: On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote: On Mon, 27 Aug 2012 10:48:32 +0200 Thomas Bächler tho...@archlinux.org wrote: But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come. I don't run gnome, but kde is just as bad in this case :( care to elaborate? I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific. GNOME OTOH forces you to use pulseaudio : $ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd. But who knows, I can imagine that there are so many old time linux users that would hate installing something like systemd even if they use kde as DE. With a bit of luck someone willl step up and maintain an alternative to consolekit/polkit that doesn't require systemd. --- Joakim -- Joakim Hernberg
[arch-general] Re: [arch-dev-public] merging systemd back to a singular package
The 27/08/12, Tom Gundersen wrote: As has been mentioned, the problems I foresee are (ordered from currently a problem to a potential problem a long time from now: 1) not enough people testing initscripts. This would be easy to help out with :-) 2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around. 3) devs at some point no longer wanting to maintain the various rc scripts. If people are committed enough I guess an rc scripts package could be put in the AUR to deal with this case (if ever it becomes a problem, which it might not). Notice that debian is working on a tool to automagically convert unit systemd files into initscripts. https://github.com/akhilvij/systemd-to-sysvinit-converter Might be worth giving it a try and contribute to get easier support of sysvinit in the long term. -- Nicolas Sebrecht
Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
On Tue, 28 Aug 2012 08:55:06 +0200 Joakim Hernberg j...@alchemy.lu wrote: $ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd. Maybe I should add that I think this support is only needed by KDE for powermanagement and automounting of media. So conceivably one could live without it if necessary :) -- Joakim -- Joakim Hernberg
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: Notice that debian is working on a tool to automagically convert unit systemd files into initscripts. https://github.com/akhilvij/systemd-to-sysvinit-converter If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than forking (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious... -t
Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
Am 28.08.2012 04:16, schrieb Shridhar Daithankar: On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote: On Mon, 27 Aug 2012 10:48:32 +0200 Thomas Bächler tho...@archlinux.org wrote: But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come. I don't run gnome, but kde is just as bad in this case :( care to elaborate? I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific. You can build polkit with either consolekit or systemd support, but not with support for both. consolekit is unmaintained for a while and thus we will switch to building polkit with systemd support instead. Once that happens, you need systemd for certain aspects of KDE to function properly (most prominently, mounting removable file systems). signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Op 28 aug. 2012 10:06 schreef Tom Gundersen t...@jklm.no het volgende: On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: Notice that debian is working on a tool to automagically convert unit systemd files into initscripts. https://github.com/akhilvij/systemd-to-sysvinit-converter If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than forking (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious... Actually, that sounds like a fairly small issue... With most daemons i prefer to either start them at boot or not at all. In case any daemon requires socket activation, you can use xinetd for those. mvg, Guus
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On Tue, Aug 28, 2012 at 10:24 AM, Guus Snijders gsnijd...@gmail.com wrote: Op 28 aug. 2012 10:06 schreef Tom Gundersen t...@jklm.no het volgende: If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than forking (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious... Actually, that sounds like a fairly small issue... With most daemons i prefer to either start them at boot or not at all. In case any daemon requires socket activation, you can use xinetd for those. I guess what I wrote was a bit misleading. Ignore socket/dbus activation (that is a side effect only). The point is that I don't see how to make daemons of Type=simple (the default), Type=dbus or Type=notify work without reimplementing much of systemd (regardless of when/how they are started). The point is that those kinds of daemons have moved functionality out of the daemon itself and into systemd, so the analogous must be done in the rc scripts. Hopefully the Debian guys have found a clever solution for this, I'd be interested to see it :) Cheers, Tom
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On 27 August 2012 18:16, Tom Gundersen t...@jklm.no wrote: On Mon, Aug 27, 2012 at 5:21 PM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: I can help (or at least try to) with support for initscripts Anyone who wants to help, please join arch-proje...@archlinux.org, review patches, use initscripts from git/testing and report problems. if it's going to be a burden for you some day in the future. As has been mentioned, the problems I foresee are (ordered from currently a problem to a potential problem a long time from now: 1) not enough people testing initscripts. This would be easy to help out with :-) For some reason I always find problems after some time when initscripts are already in core. 2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around. I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. I can maintain these in community if that time comes. But I can care about KDE only, making GNOME work without systemd would be a too difficult (I don't use it and they are much more likely to require systemd than KDE). Fortunately KDE currently uses only one library (polkit) that is likely to switch to systemd in near future. Lukas
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. So far we see that whenever systemd is made optional, it is optional at compile-time rather than at run-time (which would have been ideal, and not much more difficult to code). That means our packages cannot support both scenarios at the same time. As to Ubuntu, remember that they lag quite far behind our packages, so while they probably will produce patches, don't expect it to happen in time for it to help us. Notice for instance that Ubuntu supposedly took over consolekit, but no release has happened and without backporting patches from git our consolekit package would be completely broken. In short: avoiding systemd will be a lot of work, and you will be more or less alone in doing it. -t
Re: [arch-general] khugepaged hangs and filesystem unresponsive
On 27 August 2012 09:10, pants pa...@cs.hmc.edu wrote: Good evening, I just experienced a major problem with my system while listening to a music file in mpd from an xfs filesystem over a mdadm raid6. A kernel error was thrown, with the following error.log entry: output: /var/log/error.log Aug 26 23:34:50 localhost kernel: [283781.061258] xhci_hcd :0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Aug 26 23:34:50 localhost kernel: [283781.062268] xhci_hcd :0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Aug 26 23:34:50 localhost kernel: [283781.063273] xhci_hcd :0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Aug 26 23:34:50 localhost kernel: [283781.064245] xhci_hcd :0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Aug 26 23:34:51 localhost kernel: [283782.058901] timeout: still 1 active urbs.. Aug 26 23:38:48 localhost kernel: [284019.080666] INFO: task mpd:707 blocked for more than 120 seconds. Aug 26 23:38:48 localhost kernel: [284019.080696] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:40:48 localhost kernel: [284139.071419] INFO: task khugepaged:32 blocked for more than 120 seconds. Aug 26 23:40:48 localhost kernel: [284139.071451] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:40:48 localhost kernel: [284139.071589] INFO: task mpd:525 blocked for more than 120 seconds. Aug 26 23:40:48 localhost kernel: [284139.071613] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:40:48 localhost kernel: [284139.071721] INFO: task mpd:707 blocked for more than 120 seconds. Aug 26 23:40:48 localhost kernel: [284139.071744] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:40:48 localhost kernel: [284139.071943] INFO: task mplayer:28316 blocked for more than 120 seconds. Aug 26 23:40:48 localhost kernel: [284139.071968] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:42:48 localhost kernel: [284259.062189] INFO: task khugepaged:32 blocked for more than 120 seconds. Aug 26 23:42:48 localhost kernel: [284259.062220] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:42:48 localhost kernel: [284259.062358] INFO: task mpd:525 blocked for more than 120 seconds. Aug 26 23:42:48 localhost kernel: [284259.062382] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:42:48 localhost kernel: [284259.062489] INFO: task mpd:702 blocked for more than 120 seconds. Aug 26 23:42:48 localhost kernel: [284259.062512] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:42:48 localhost kernel: [284259.062688] INFO: task mpd:703 blocked for more than 120 seconds. Aug 26 23:42:48 localhost kernel: [284259.062712] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 26 23:42:48 localhost kernel: [284259.062829] INFO: task mpd:704 blocked for more than 120 seconds. Aug 26 23:42:48 localhost kernel: [284259.062852] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Attempts to access other files on the same filesystem after the incident caused the applications used to also go into interruptible sleep (see the mplayer processes that appear later in the log). I was forced to kill and unmount what I could, then force the system down. Afterwards, I could replicate the error by attempting to read the file in question at the same point Even if you have no solution, pointing me towards the relevant kernel mailing list would be very helpful. Thanks, pants. It is difficult to say where the problem is in. I'd go for LKML mailing list [1] or for the Kernel Bugzilla [2] as stated in [3]. You may try XFS mailing list if you think it's XFS-only issue (ie. it doesn't happen with other filesystems). Lukas [1] https://lkml.org/ (the email address is linux-ker...@vger.kernel.org) [2] https://bugzilla.kernel.org/ [3] http://www.kernel.org/doc/man-pages/reporting_code_bugs.html
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On 28 August 2012 11:05, Tom Gundersen t...@jklm.no wrote: On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. So far we see that whenever systemd is made optional, it is optional at compile-time rather than at run-time (which would have been ideal, and not much more difficult to code). That means our packages cannot support both scenarios at the same time. That's why I'm think about maintaining such packages in community. As to Ubuntu, remember that they lag quite far behind our packages, so while they probably will produce patches, don't expect it to happen in time for it to help us. Notice for instance that Ubuntu supposedly took over consolekit, but no release has happened and without backporting patches from git our consolekit package would be completely broken. In short: avoiding systemd will be a lot of work, and you will be more or less alone in doing it. -t Unless there's going to be some major rewrite of the affected packages in the meantime I think I'll be able to handle that. During the years I'm using OSS, I learned one thing: If no one else wants to do something, you must do it yourself. Lukas
Re: [arch-general] SystemD poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2012 05:40 AM, C Anthony Risinger wrote: you sir, are an arrant sack of shite -- a pitifully miserable sore spewing an egregious pus of arrogance and obstinance -- a first-class jerk-off! Wow, Stephen Fry would be proud. http://youtu.be/H0cJBEMiN1c -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQPI/HAAoJENVg3RpC7ZC8goQP/jp8i3PvWxLfzNLh9+wzdmY2 Z1LI0Kc8W+aV8khWCzzRUsCbUgYlPCco+R1ui+co534R85PrvajxGKC99DU7pj6s o4b5w9dhds6fD0LTkNRH2m6TgqJ3YeJrC+5VWjxV9ey/j2AFFIsGQBCgyM6w0S5C QiHukol8RY0Mywx94tITIkJSHYffuIqUlB35a7yzhkCgGyVmPOSvbvVlDhxY4ilG vEAg9BPU9Y2TG5gZO1GPi+zugEdE0ePnNV0iSuJOnKfvjHCYfyPXjVlBZoidr4+Z 1cKjrNqONg+OBbgOOT4krW9LGf7jxFKLANThIw771bpsKmRNWhgjVT3dxfkD1uHS p2KIrGqiTVAcgCGC5zGhknBzno6GTQtO1QXgHvsjpg+1ybc/vRaDKdb+CkSrHKEC GkEww0RgoLLLP0upsIsFxIB18cumxghUnl5GlsW8Gf07yKNK39f+zebtxUZmJ3+4 FNQ94KhsAEykeGb/p4wb9hAxPdzQJaTb2pU3DdSBOChprRLN2YxVycCz0NjufO+a irWIm/GKjxvxqauW/enDaJxoNWCt6xOyxE6tgm1dVoWpjN5bWJnGvxcyDqRw8xmY oEe4Ola0do0zTixavjkoOHRmA+xVypZ6+F32Ja/xU4PluLoty3MHjF5JZZrJdlGJ 63scVfw3n3ARxpdY8Kl3 =QxDD -END PGP SIGNATURE-
[arch-general] Re: [arch-dev-public] merging systemd back to a singular package
The 28/08/12, Tom Gundersen wrote: I guess what I wrote was a bit misleading. Ignore socket/dbus activation (that is a side effect only). The point is that I don't see how to make daemons of Type=simple (the default), Type=dbus or Type=notify work without reimplementing much of systemd (regardless of when/how they are started). The point is that those kinds of daemons have moved functionality out of the daemon itself and into systemd, so the analogous must be done in the rc scripts. Well, sd_notify looks pretty simplistic and I guess than writting a helper program to handle this function would not be hard, if ever needed. Now, the simple type of systemd pretends to do optimization: if the process offers functionality to other processes on the system its communication channels should be installed before the daemon is started up [...] as systemd will immediately proceed starting follow-up units. While it's a good feature to get pallelism, it's not expected by historical sysVinit. So, it should be fine to start the required deamon and let it configure environment or whatever it has to. Once it is fully started or responding, continue the boot process. Yes, this fully started or responding is the tricky part but with a fully serialized starting process, it might be doable. Though, I wouldn't expect such converter to create shell scripts roughly equivalent to what systemd does. I think the main pitfall to such a tool would be to try to get equivalent features with shell scripts. Think another way: sysVinit serialize daemons startup. As a consequence, for a minimal working convertion you only need to get the correct order of the series. Advanced features of systemd should highly be ignored from the process. On top of that and for tricky parts of the conversion, it should not be very hard to have conversion tunning from a complementary static source. I mean, trying to convert everything /from unit files only/ in a smart enough way could be very hard. Instead, it would be easier to do the consersion from both unit files AND whatever other source or configuration files (of the convertion tool). IMHO, the best approach of this converter would be to turn it into a micro-framework with _very simple features_ like templating support for init scripts. That way: - simple unit files would not require a template; let the process go automagically; - more complex unit files would only require to write a little template with whatever static-and-dedicated code needed for a given section/function of the built target (the sysVinit script). The systemd-to-sysvinit-converter seems very hackable as a all-in-one python script with only 658 lines. ,-) Hopefully the Debian guys have found a clever solution for this, I'd be interested to see it :) I guess you meant if the Debian guys have found. -- Nicolas Sebrecht
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On Tue, Aug 28, 2012 at 12:06 PM, Nicolas Sebrecht nsebre...@piing.fr wrote: [...]its communication channels should be installed before the daemon is started up [...] This is the point. If a daemon has been customized for systemd (which some have, and hopefully more will), then it will expect systemd to set up its communication channels for it and pass them to the daemon on startup, it might also expect systemd to do many other tasks which daemons traditionally would do themselves. This is by no means impossible to reimplement, but it would be quite some work, so it is something to keep in mind. -t
[arch-general] Re: [arch-dev-public] merging systemd back to a singular package
The 28/08/12, Tom Gundersen wrote: This is the point. If a daemon has been customized for systemd (which some have, and hopefully more will), then it will expect systemd to set up its communication channels for it and pass them to the daemon on startup, it might also expect systemd to do many other tasks which daemons traditionally would do themselves. Daemons customized to require systemd will actually require systemd. Now, systemd is a Linux only platform tool and most upstream don't target their software to Linux only. I don't expect much daemons requiring systemd to be started. If they do, users who want such tool will use systemd and such daemons would naturally be out of the scope. -- Nicolas Sebrecht
Re: [arch-general] SystemD poll
Suppose for some reason the majority of scientists believe in the theory of the Big Bang. And then I come along and wonder... where is the evidence? Well, if the Big Bang theory has merits, there would be tons of evidence, and any decent scientist that believes in this theory would gladly point me towards that evidence. But what happens if scientists tell me: no, we already believe in this theory, so now *you* have the burden of proof if you want to discredit it; that would be worrying. I don't want to discredit it: I'm simply a rational person that is looking for the evidence, and as any rational person, I would not take the scientists words for an answer (fallacy of authority), or accept the status quo (appeal to tradition). In fact in most cases that was exactly what happened with some scientists and teachers saying the Big Bang was all but proven until fairly recently the number questioning and the evidence built up against it. To me it has been obvious that the Big Bang was bullshit for over a decade because, where did the dust come from and what came to make the dust and what made that. I didn't need to know and couldn't afford the time to find out about quantum mechanics but in fact knowledge can blind you as much as it clears the way. Of course the Big Bang theory is morphing with one option being many Big Bang's and that it was a point in history and not the beginning which is perfectly plausible and systemd may morph sufficiently for more users too, in time. I care little though (except any consequences) and don't hold a great deal of hope in that regard because systemd tells us what to do and not us telling systemd what to do and so it can never fit everyone's needs as init scripts can, as to do so, it wouldn't be systemd any more. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] Arch Linux and systemd
So which components (obviously used by the majority of Arch users) do currently have or will soon have hardcoded! dependencies to systemd? udev. Upstream, Gnome has considered it. You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees. p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of they're work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] SystemD poll
Every piece of complex software has bugs; those bugs won't be found if the software isn't tested, and since you're not willing to participate in that process you've no right to harass those who have. Not everyone wants complex software, just about any other init system let's you decide that. You could argue the Linux kernel is complex and it is but also extremely configurable to a point of being extremely simple, considering it's task. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] SystemD poll
The cumulated amount of time spent on these endless discussions has now almost certainly get past the amount of time necessary to fix initscripts. Fix them instead of feeding trolls. Except there will be more fallout from systemd's wide adoption than our own selfish needs but as that is unlikely to happen, I guess you are right. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
But who knows, I can imagine that there are so many old time linux users that would hate installing something like systemd even if they use kde as DE. With a bit of luck someone willl step up and maintain an alternative to consolekit/polkit that doesn't require systemd. In most cases there is no need. Consolekit controls sessions for xfce, the first thing I turn off and easily replaced. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.). Do you mean the packages compiled for Arch with systemd enabled options like firefoxes with dbus? I don't see these packages removing more than half their userbase and I don't see systemd ever getting more than half the userbase. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. I can maintain these in community if that time comes. But I can care about KDE only, making GNOME work without systemd would be a too difficult (I don't use it and they are much more likely to require systemd than KDE). Fortunately KDE currently uses only one library (polkit) that is likely to switch to systemd in near future. Personally I live happier without polkit but for others it may be if the build machines don't mind that arch could have kde-nosystemd packages? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Hi, Apparently, Gentoo has recently forked udev. [1] I am not completely sure since the main poster is a n00b according to the gentoo forum ratings, but rest of the discussions seems legit. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] SystemD poll
On Tue, 28 Aug 2012 11:06:12 +0100 Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: In fact in most cases that was exactly what happened with some scientists and teachers saying the Big Bang was all but proven until fairly recently the number questioning and the evidence built up against it. To me it has been obvious that the Big Bang was bullshit for over a decade because, where did the dust come from and what came to make the dust and what made that. Kevin, I have read all your contributions here with interest. Along with those of Anthony ''Ishpeck'' Tedjamulia, I have found them genuinely helpful in gaining perspective on the systemd issue. But please, I beg you, don't take us into quantum mechanics, the Standard Model and all its ramifications. My nerves won't stand contemplating how systemd interacts with the Everett Interpretation :) Geoff
Re: [arch-general] Arch Linux and systemd
On Tuesday 28 Aug 2012 11:16:38 Kevin Chadwick wrote: You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees. p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of they're work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor. In this context, I had shared a link where systemd devs had suggested gnome devs to consider adding systemd as a dependency due to some funcitonality which was present in systemd only. [1] What is going on I am not sure, but this shows that GNOME in future is going to have a hard dependency on systemd. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html [1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
Re: [arch-general] Arch Linux and systemd
On Tue, 2012-08-28 at 16:43 +0530, Jayesh Badwaik wrote: On Tuesday 28 Aug 2012 11:16:38 Kevin Chadwick wrote: You know why, because according to heise some of their longterm devs have left leaving more than half the devs being RedHat employees. p.s. I have nothing against RedHat, I value they're work, mostly the work which goes unnoticed. Unfortunately the most prominent of they're work gets a bad rep or is it more prominent because of the rep? I think both because it often has a bad user experience and interaction factor. In this context, I had shared a link where systemd devs had suggested gnome devs to consider adding systemd as a dependency due to some funcitonality which was present in systemd only. [1] What is going on I am not sure, but this shows that GNOME in future is going to have a hard dependency on systemd. [1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html If somebody doesn't want to use systemd, IMO it's easy to quit GNOME. I don't think that gcalctool and other small apps will have a dependency chain, as well as GTK. Or could it become that extreme? Sorry for the noob question, Ralf
[arch-general] systemd boot errors
Dear list, I am testing systemd. I have the following errors at boot: 1-failed to start packet filtering framework iptables is installed on my system 2-boot hangs on at: reached target graphical interface i do not use any login manager. runlevel 3 + startx 3-systemd can't write to journal. I have a message at boot: /var/log/journal/d564e939c66712bce792b071017f/fss file does not exist. I have in fact /var/log/journal/d564e939c66712bce792b071017f/system.journal. Thank you for any help.
Re: [arch-general] systemd boot errors
On Tue, Aug 28, 2012 at 9:41 AM, Arno Gaboury arnaud.gabo...@gmail.com wrote: Dear list, I am testing systemd. I have the following errors at boot: 1-failed to start packet filtering framework iptables is installed on my system 2-boot hangs on at: reached target graphical interface i do not use any login manager. runlevel 3 + startx 3-systemd can't write to journal. I have a message at boot: /var/log/journal/d564e939c66712bce792b071017f/fss file does not exist. I have in fact /var/log/journal/d564e939c66712bce792b071017f/system.journal. Have you read Arch wiki about systemd? It explains 2 and 3 and will help you debug 1. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html --- Denis A. Altoe Falqueto Linux user #524555 ---
[arch-general] [PSA] change to locale handling
Hi guys, We recently (in [testing]) refactored our locale handling. This should hopefully resolve some long-standing issues, so I though I'd bring it to everyone's attention. For some details see: https://plus.google.com/114015603831160344127/posts/2zKCcnTWDpa. Please report any issues/bugs/regressions on the bug tracker. Cheers, Tom
Re: [arch-general] systemd boot errors
On Tue, Aug 28, 2012 at 2:41 PM, Arno Gaboury arnaud.gabo...@gmail.com wrote: Dear list, I am testing systemd. I have the following errors at boot: 1-failed to start packet filtering framework iptables is installed on my system There probably was an error restoring the iptables rules. Check systemctl status iptables 2-boot hangs on at: reached target graphical interface i do not use any login manager. runlevel 3 + startx systemctl enable multi-user.target will switch the default target to multi-user.target 3-systemd can't write to journal. I have a message at boot: /var/log/journal/d564e939c66712bce792b071017f/fss file does not exist. I have in fact /var/log/journal/d564e939c66712bce792b071017f/system.journal. You get this error because you're running systemd v189 and have forward-secure log sealing enabled (which is the default), but no sealing keys exist. Either disable sealing in /etc/systemd/journald.conf or generate sealing keys using journalctl --setup-keys.
Re: [arch-general] SystemD poll
On Tue, Aug 28, 2012 at 5:06 AM, Kevin Chadwick ma1l1i...@yahoo.co.ukwrote: Suppose for some reason the majority of scientists believe in the theory of the Big Bang. And then I come along and wonder... where is the evidence? Well, if the Big Bang theory has merits, there would be tons of evidence, and any decent scientist that believes in this theory would gladly point me towards that evidence. But what happens if scientists tell me: no, we already believe in this theory, so now *you* have the burden of proof if you want to discredit it; that would be worrying. I don't want to discredit it: I'm simply a rational person that is looking for the evidence, and as any rational person, I would not take the scientists words for an answer (fallacy of authority), or accept the status quo (appeal to tradition). In fact in most cases that was exactly what happened with some scientists and teachers saying the Big Bang was all but proven until fairly recently the number questioning and the evidence built up against it. To me it has been obvious that the Big Bang was bullshit for over a decade because, where did the dust come from and what came to make the dust and what made that. I didn't need to know and couldn't afford the time to find out about quantum mechanics but in fact knowledge can blind you as much as it clears the way. Of course the Big Bang theory is morphing with one option being many Big Bang's and that it was a point in history and not the beginning which is perfectly plausible and systemd may morph sufficiently for more users too, in time. I care little though (except any consequences) and don't hold a great deal of hope in that regard because systemd tells us what to do and not us telling systemd what to do and so it can never fit everyone's needs as init scripts can, as to do so, it wouldn't be systemd any more. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ Wow, this is way off base. Anyway, you may also wish to look into the argument from ignorance; the fact that you fail to understand something doesn't make it untrue. I have to admit I'd be interested to know who you get information on theoretical physics from, since you seem to think theoretical physicists aren't reliable authorities on the subject. I'm also getting tired of seeing folks completely misunderstand how the burden of proof works (hint: It always lies with the claimant). Back on track: You and I have different standards for complexity. A few dozen lines of code accomplishing a multi-faceted task can easily be considered complex. systemd can be just as modular as you like, if you learn your way around it. Many of the units installed with the package on Arch are packaged upstream, and can be done away with by the user if not needed.
Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
On 28 August 2012 16:01, Joakim Hernberg j...@alchemy.lu wrote: On Tue, 28 Aug 2012 08:55:06 +0200 Joakim Hernberg j...@alchemy.lu wrote: $ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd. Maybe I should add that I think this support is only needed by KDE for powermanagement and automounting of media. So conceivably one could live without it if necessary :) In fact, many Archers have lived without these things for years ever since they became mandatory for the masses. Especially those on WMs. These are the purists, so to say. I don't see systemd or anything like that becoming a problem. The purists will find their way to keep these things out. Having libpulse or systemd live on your system isn't going to do any harm while you're adapting to the change. There's always a way to do what you want, and there's always another KISS operating system. Given the resistance that I see, I'm almost sure a separate initscripits project (or a distro fork if necessary) is inevitable. -- GPG/PGP ID: C0711BF1
Re: [arch-general] kde and systemd [was Re: [arch-dev-public] merging systemd back to a singular package]
On Tue, 28 Aug 2012 23:45:04 +0800 Rashif Ray Rahman sc...@archlinux.org wrote: Having libpulse or systemd live on your system isn't going to do any harm while you're adapting to the change. There's always a way to do what you want, and there's always another KISS operating system. Given the resistance that I see, I'm almost sure a separate initscripits project (or a distro fork if necessary) is inevitable. A distro fork would be the absolute worst outcome imaginable (imo) of the initscripts vs systemd schism... --- Joakim
Re: [arch-general] xf86-video-intel-2.20.5
On 08/27/2012 01:20 PM, Andre Goree wrote: On 08/27/2012 01:03 PM, Jameson wrote: Updating xf86-video-intel to 2.20.5 today results in my DRM driver hanging when I try to use compiz. Has anyone else seen this, or am I just lucky with my hardware configuration? Does anyone know of something new that got turned on by default in this version that could result in this: Aug 27 12:39:09 localhost kernel: [4.733046] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 Aug 27 12:42:27 localhost kernel: [ 219.129987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 220.723319] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.229987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.230044] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Aug 27 12:42:37 localhost kernel: [ 222.230087] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I'll be happy to post more information, and/or a bug later if that will be helpful. For now, I need to get caught back up at work. Thanks, =-Jameson Interesting (glad I didn't proceed with the update). Given that I'm at work right now, I'll hold off on my update/reboot until later this evening, and let you know if I get the same error. I'm not actually using Compiz, but rather Kwin...though since it's a kernel-level issue, I guess we'll see how much that matters. I indeed ended up having an issue with Kwin that actually was causing KDE to crash. After downgrading to xf86-video-intel-2.20.4-1-x86_64.pkg.tar.xz, the issue ceased. For whatever reason, it was causing X BadWindow and Fatal IO errors, e.g.: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x3ee X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 (X_GetProperty) Resource id: 0x3ee X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x3ee plasma-desktop(3002)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: MNG error 11: Function is invalid at this point; chunk IHDR; subcode 0:0 kopete(3110): No language dictionaries for the language : en_US plasma-desktop(3002)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application enigmail.js: Registered components caught error TypeError: Cc['@mozilla.org/mime/pgp-mime-decrypt;1'] is undefinedmimeDecrypt.jsm: MimeDecryptor registration doneplasma-desktop(3002)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 (X_ChangeWindowAttributes) Resource id: 0x1e020c7 krdc(3272)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: kwin: Fatal IO error: client killed kdeinit4: Fatal IO error: client killed -- Andre Goree an...@drenet.info signature.asc Description: OpenPGP digital signature
Re: [arch-general] xf86-video-intel-2.20.5
On Tue, Aug 28, 2012 at 12:37 PM, Andre Goree an...@drenet.info wrote: On 08/27/2012 01:20 PM, Andre Goree wrote: On 08/27/2012 01:03 PM, Jameson wrote: Updating xf86-video-intel to 2.20.5 today results in my DRM driver hanging when I try to use compiz. Has anyone else seen this, or am I just lucky with my hardware configuration? Does anyone know of something new that got turned on by default in this version that could result in this: Aug 27 12:39:09 localhost kernel: [4.733046] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 Aug 27 12:42:27 localhost kernel: [ 219.129987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 220.723319] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.229987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.230044] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Aug 27 12:42:37 localhost kernel: [ 222.230087] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I'll be happy to post more information, and/or a bug later if that will be helpful. For now, I need to get caught back up at work. Thanks, =-Jameson Interesting (glad I didn't proceed with the update). Given that I'm at work right now, I'll hold off on my update/reboot until later this evening, and let you know if I get the same error. I'm not actually using Compiz, but rather Kwin...though since it's a kernel-level issue, I guess we'll see how much that matters. I indeed ended up having an issue with Kwin that actually was causing KDE to crash. After downgrading to xf86-video-intel-2.20.4-1-x86_64.pkg.tar.xz, the issue ceased. I opened a bug report. https://bugs.archlinux.org/task/31317
Re: [arch-general] SystemD poll
Of course the Big Bang theory is morphing with one option being many Big Bang's and that it was a point in history and not the beginning which is perfectly plausible and systemd may morph sufficiently for more users too, in time. I care little though (except any consequences) and don't hold a great deal of hope in that regard because systemd tells us what to do and not us telling systemd what to do and so it can never fit everyone's needs as init scripts can, as to do so, it wouldn't be systemd any more. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ Wow, this is way off base. Anyway, you may also wish to look into the argument from ignorance; the fact that you fail to understand something doesn't make it untrue. I have to admit I'd be interested to know who you get information on theoretical physics from, since you seem to think theoretical physicists aren't reliable authorities on the subject. I'm also getting tired of seeing folks completely misunderstand how the burden of proof works (hint: It always lies with the claimant). Seems the systemd advocating Trolls continue to shoot down without saying a thing. You missed the point, a fact can be obtained and a theory discounted without understanding the complete origins of the universe which no one can satisfy without mentioning God. The consensus was wrong and believed to be all but proved and those very physicists are now saying so due to those who grew up asking questions in the classroom realising more and more that the lecturer was wrong and the attention and work refocussed on new more likely ideas with new flaws. So you really believe the old theory that a single Big bang started the universe and which and is more likely a multiverse. A term concocted I suppose to stop treading on peoples toes. I suppose you believe in string theory too and going faster than light puts you in the past rather than just seeing the past, but enough digressing. This work will likely never end but good does come of it. I suppose you blindly believe everything physicists and Lennart says. Kindly tell me privately what you believe is 'on base' currently as I won't spam this list any more. I'd be shocked, if it was credible, though it may be interesting and answer some questions leading to new ones. Back on track: You and I have different standards for complexity. A few dozen lines of code accomplishing a multi-faceted task can easily be considered complex. systemd can be just as modular as you like, if you learn your way around it. /sbin/init does not demand a few dozen lines of code unless you wish so. It is not as modular as you like without study, a major rewrite and recompilation. I guess you missed the posts about embedded and Android and busybox using an init system leaner than the usual /sbin/init. You also seem to have missed or ignored the points about complex kernel requirements etc. that it wants to apply to every system and contrary to the arch way 2.0. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [arch-general] xf86-video-intel-2.20.5
I opened a bug report. https://bugs.archlinux.org/task/31317 It seems to be SNA causing the problem. I have swapped over to UXA for the time being, been stable for the like 3 hours. Neil
Re: [arch-general] xf86-video-intel-2.20.5
On Tue, 28 Aug 2012 17:55:46 +0100 Neil Perry npe...@gmail.com wrote: It seems to be SNA causing the problem. I have swapped over to UXA for the time being, been stable for the like 3 hours. Is the default still UXA mode? --- Joakim
Re: [arch-general] khugepaged hangs and filesystem unresponsive
On Tue, Aug 28, 2012 at 11:07:10AM +0200, Lukas Jirkovsky wrote: It is difficult to say where the problem is in. I'd go for LKML mailing list [1] or for the Kernel Bugzilla [2] as stated in [3]. You may try XFS mailing list if you think it's XFS-only issue (ie. it doesn't happen with other filesystems). I don't know how much I can bring them; I ran xfs_repair on the filesystem in question, deleted, and replaced the problematic file, and have had no further problems with it. Thank you for your input regardless, pants. pgpsAEcwjleHW.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] linux-3.5.x status
On Thu, Aug 23, 2012 at 04:10:26PM +0200, Tobias Powalowski wrote: If you have any other showstopper please let me know. I just upgraded my machine to the new kernel this morning, and was greeted by a kernel panic coming out of the shower. Unfortunately, nothing was logged to the disk, so I have nothing to share here, which probably makes this email near useless. However, it is worth noting that after forcing the system down and powering it on again, I was greeted with MACHINE CHECK ERROR after the BIOS splash, followed by a boot cycle which would again stop at this point. After turning the machine off again for a while, I powered it on with no difficulty and was able to boot into arch. Any input would be greatly appreciated. pants. pgpeFiQK4LSCt.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
On Tue, Aug 28, 2012 at 6:55 AM, Jayesh Badwaik jayesh.badwai...@gmail.com wrote: Hi, Apparently, Gentoo has recently forked udev. [1] I am not completely sure since the main poster is a n00b according to the gentoo forum ratings, but rest of the discussions seems legit. Actually, a guy forked it and announced it on Gentoo's forums; the distro itself currently has nothing to do with it, although as Gentoo is planning on using OpenRC over systemd any news about a udev fork is interesting to them [2]. I'm not sure I'd call the less than one page of discussion legit though - it looks to me like a little bit of building discussion and a lot of the same crap that's been infecting our own mailing list (plus consus' advantages are suspect - just going on the first one, a separate /usr not mounted in initramfs has been broken since long before systemd-udev, and in my quick look at commits I don't really see anything they've added that would change that esp. since it's not just udev that's the issue. If Gentoo devs get on board it might go somewhere, but until then I'm not that confident.) [1]https://forums.gentoo.org/viewtopic-t-934678.html [2]http://www.reddit.com/r/linux/comments/ywdpw/systemdudev_has_been_forked/c5zwz0n
Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Ahh, I thought so. It was only forked yesterday, so there is not much to be expected in terms of changes right now. But going by the number of veterans and others who have commented on it, I thought that it is possible that this is legit. Also, the guys there are talking like they are the one going to be making the changes. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] xf86-video-intel-2.20.5
On Tue, Aug 28, 2012 at 12:55 PM, Neil Perry npe...@gmail.com wrote: It seems to be SNA causing the problem. I have swapped over to UXA for the time being, been stable for the like 3 hours. Yep. UXA is working fine for me, also. =-Jameson
Re: [arch-general] [arch-dev-public] linux-3.5.x status
On Tue, Aug 28, 2012 at 1:55 PM, pants pa...@cs.hmc.edu wrote: I just upgraded my machine to the new kernel this morning, and was greeted by a kernel panic coming out of the shower. Unfortunately, nothing was logged to the disk, so I have nothing to share here, which probably makes this email near useless. However, it is worth noting that after forcing the system down and powering it on again, I was greeted with MACHINE CHECK ERROR after the BIOS splash, followed by a boot cycle which would again stop at this point. After turning the machine off again for a while, I powered it on with no difficulty and was able to boot into arch. Any input would be greatly appreciated. I'm no kernel dev, but that sounds like a hardware issue to me. =-Jameson
Re: [arch-general] iptables forward policy
Thanks all for your help I finally decided to go with a more simple port forwarding solution using socat a tool to forward tcp conections. This way I can filter forwarded ports by using the router's INPUT chain. Cheers On Sun, Aug 26, 2012 at 1:08 PM, Peter Baldridge petebaldri...@gmail.com wrote: On Sun, Aug 26, 2012 at 10:11 AM, Juan Diego Tascón juantas...@gmail.comwrote: Is there any way to debug iptables, Juan, Another good way to debug IPTables (if you can limit the traffic to the box to just what you are troubleshooting) use the command : sudo iptables -Z sudo watch -n .5 iptables -nvL ^zeros the counters for iptables this will serve to show packet counters next to all your rules. Then you can send the traffic you are troubleshooting and see which rule it is matching. From a different window or screen you can add/drop rules and watch the counters in real time. That has always helped me in tough IPtables setups since it's a little more realtime/less info than logging. -pete
Re: [arch-general] xf86-video-intel-2.20.5
On 08/28/2012 02:43 PM, Jameson wrote: On Tue, Aug 28, 2012 at 12:55 PM, Neil Perry npe...@gmail.com wrote: It seems to be SNA causing the problem. I have swapped over to UXA for the time being, been stable for the like 3 hours. Yep. UXA is working fine for me, also. For what its worth - i still have crashes with UXA just very much less frequent. I logged it here: https://bugs.archlinux.org/task/30921 gene/
Re: [arch-general] xf86-video-intel-2.20.5
On Tue, Aug 28, 2012 at 8:46 PM, Genes MailLists li...@sapience.com wrote: On 08/28/2012 02:43 PM, Jameson wrote: On Tue, Aug 28, 2012 at 12:55 PM, Neil Perry npe...@gmail.com wrote: It seems to be SNA causing the problem. I have swapped over to UXA for the time being, been stable for the like 3 hours. Yep. UXA is working fine for me, also. For what its worth - i still have crashes with UXA just very much less frequent. I logged it here: https://bugs.archlinux.org/task/30921 gene/ Works excellent here with intel ironlake and sna
[arch-general] Is Nouveau 2D or 3D acceleration driver for nVidia cards?
The description of package xf86-video-nouveau ( http://www.archlinux.org/packages/extra/x86_64/xf86-video-nouveau) is Open Source 2D acceleration driver for nVidia cards, but Arch Wiki( https://wiki.archlinux.org/index.php/Nouveau) says that it is Open Source 3D acceleration graphics driver for NVIDIA cards. Is there any mistakes?
Re: [arch-general] Is Nouveau 2D or 3D acceleration driver for nVidia cards?
On Tue, Aug 28, 2012 at 10:40 PM, Kelvin kelvin9302...@gmail.com wrote: The description of package xf86-video-nouveau ( http://www.archlinux.org/packages/extra/x86_64/xf86-video-nouveau) is Open Source 2D acceleration driver for nVidia cards, but Arch Wiki( https://wiki.archlinux.org/index.php/Nouveau) says that it is Open Source 3D acceleration graphics driver for NVIDIA cards. Is there any mistakes? Both. afiak it started out as a 2d driver, but these days it also has [limited] 3d acceleration.
Re: [arch-general] Is Nouveau 2D or 3D acceleration driver for nVidia cards?
2012/8/29 Brandon Watkins bwa...@gmail.com On Tue, Aug 28, 2012 at 10:40 PM, Kelvin kelvin9302...@gmail.com wrote: The description of package xf86-video-nouveau ( http://www.archlinux.org/packages/extra/x86_64/xf86-video-nouveau) is Open Source 2D acceleration driver for nVidia cards, but Arch Wiki( https://wiki.archlinux.org/index.php/Nouveau) says that it is Open Source 3D acceleration graphics driver for NVIDIA cards. Is there any mistakes? Both. afiak it started out as a 2d driver, but these days it also has [limited] 3d acceleration. Thanks. I found this page after I have posted this. http://nouveau.freedesktop.org/wiki/FeatureMatrix The support is really very limited.
Re: [arch-general] Is Nouveau 2D or 3D acceleration driver for nVidia cards?
Le 29 août 2012 05:26, Kelvin kelvin9302...@gmail.com a écrit : 2012/8/29 Brandon Watkins bwa...@gmail.com On Tue, Aug 28, 2012 at 10:40 PM, Kelvin kelvin9302...@gmail.com wrote: The description of package xf86-video-nouveau ( http://www.archlinux.org/packages/extra/x86_64/xf86-video-nouveau) is Open Source 2D acceleration driver for nVidia cards, but Arch Wiki( https://wiki.archlinux.org/index.php/Nouveau) says that it is Open Source 3D acceleration graphics driver for NVIDIA cards. Is there any mistakes? Both. afiak it started out as a 2d driver, but these days it also has [limited] 3d acceleration. Thanks. I found this page after I have posted this. http://nouveau.freedesktop.org/wiki/FeatureMatrix The support is really very limited. Sure. But at least, screen capture fully works, not only full screen. Try taking à single window screenshot with nvidia drivers... Result is very... unuseful. Don't remember bug number, but look on archlinux bug tracker.
Re: [arch-general] Is Nouveau 2D or 3D acceleration driver for nVidia cards?
On Wed, Aug 29, 2012 at 10:40 AM, Kelvin kelvin9302...@gmail.com wrote: The description of package xf86-video-nouveau ( http://www.archlinux.org/packages/extra/x86_64/xf86-video-nouveau) is Open Source 2D acceleration driver for nVidia cards, but Arch Wiki( https://wiki.archlinux.org/index.php/Nouveau) says that it is Open Source 3D acceleration graphics driver for NVIDIA cards. Is there any mistakes? xf86-video-nouveau is for 2d acceleration. nouveau-dri is for 3d.
