Re: [gentoo-user] Re: USE flags handling
On 31/07/2014 03:55, Walter Dnes wrote: > On Wed, Jul 30, 2014 at 10:31:50PM +0200, Volker Armin Hemmann wrote >> Am 30.07.2014 21:48, schrieb Dale: >> >>> While to me KDE is bloated, I just try to disable what I can and carry >>> on. If my system was limited on resources, then I may use something else. >> >> and maybe you did exactly the wrong thing. KDE is very modular and >> reuses its modules as much as it can. Which also means: memory is only >> used once. >> >> There were once a very good (in my not so humble opinion. It think very >> highly of myself) comparism here: >> >> http://ktown.kde.org/~seli/memory/ >> (url is dead btw) >> >> and if you actually use kde apps in kde - memory consumption is lower >> than in either gnome or 'leightweight' solutions like xfce or >> windowmaker+stuff. >> >> http://web.archive.org/web/20071229030604/http://ktown.kde.org/~seli/memory/desktop_benchmark.html > > The problem with KDE apps is that they're imitating what MS did with > Internet Explorer. They pointed to the itsy-bitsy-teeny-weeny little > "ie.exe" that you could delete if you felt like doing so. They > deliberately obfuscated that it was merely a front end to a ton of > system libraries that you could not remove. Back when xpdf was being > deprecated, various replacement options were suggested. I chose mupdf > rather than the KDE app "okular". Here's why. After multiple attempts > at "emerge -pv okular", I found I had to add at least the following to > package.use to get it to work... > > dev-libs/libattica qt4 > media-libs/phonon vlc > media-video/vlc dbus xcb -ffmpeg > dev-qt/qtcore qt3support > dev-qt/qtdeclarative accessibility qt3support > dev-qt/qtgui accessibility qt3support > dev-qt/qtopengl qt3support > dev-qt/qt3support accessibility > dev-qt/qtsql qt3support sqlite > dev-qt/qtsvg accessibility > sys-libs/ncurses unicode > > Seems that if I want to emerge and use KDE's "pdf reader", I need... > > phonon > vlc (or gstreamer) > libmpeg > libmad > net-dns/libidn > dev-qt/qtwebkit > > ...***FOR A STINKING PDF READER***. Here's the "emerge -pv okular" > output with USE flag listings edited out... > > [d531][waltdnes][~] emerge -pv okular | sed " s/USE.*$//" > > These are the packages that would be merged, in order: > > Calculating dependencies done! > [ebuild R] sys-libs/ncurses-5.9-r3:5 > [ebuild N ] net-dns/libidn-1.28 > [ebuild N ] kde-base/kde-env-4.12.5:4/4.12 > [ebuild N ] dev-libs/libpcre-8.35:3 > [ebuild N ] app-admin/eselect-qtgraphicssystem-1.1.1 0 kB > [ebuild N ] dev-qt/qtcore-4.8.5-r2:4 > [ebuild N ] dev-qt/qtscript-4.8.5:4 > [ebuild N ] dev-qt/qtgui-4.8.5-r3:4 > [ebuild N ] dev-qt/qtsql-4.8.5:4 > [ebuild N ] dev-qt/qt3support-4.8.5:4 > [ebuild N ] dev-qt/qtdbus-4.8.5:4 > [ebuild N ] dev-qt/qtsvg-4.8.5:4 > [ebuild N ] dev-qt/qttest-4.8.5:4 > [ebuild N ] dev-qt/designer-4.8.5:4 > [ebuild N ] dev-qt/qtopengl-4.8.5:4 > [ebuild N ] dev-qt/qtxmlpatterns-4.8.5:4 > [ebuild N ] app-crypt/qca-2.0.3:2 > [ebuild N ] dev-qt/qtwebkit-4.8.5:4 > [ebuild N ] dev-qt/qtdeclarative-4.8.5:4 > [ebuild N ] x11-libs/libXScrnSaver-1.2.2-r1 > [ebuild N ] media-libs/libmpeg2-0.5.1-r2 > [ebuild N ] media-libs/libmad-0.15.1b-r7 > [ebuild N ] media-video/vlc-2.1.2:0/5-7 > [ebuild N ] dev-util/automoc-0.9.88 9 kB > [ebuild N ] kde-base/oxygen-icons-4.12.5:4/4.12 > [ebuild N ] media-libs/qimageblitz-0.0.6-r1 > [ebuild N ] dev-libs/libattica-0.4.2 > [ebuild N ] dev-libs/libdbusmenu-qt-0.9.2 > [ebuild N ] app-misc/strigi-0.7.8 > [ebuild N ] media-libs/phonon-4.6.0-r1 > [ebuild N ] media-libs/phonon-vlc-0.6.2 > [ebuild N ] kde-base/kdelibs-4.12.5-r1:4/4.12 > [ebuild N ] kde-base/katepart-4.12.5:4/4.12 > [ebuild N ] kde-base/libkexiv2-4.12.5:4/4.12 > [ebuild N ] kde-base/okular-4.12.5-r1:4/4.12 > > Total: 35 packages (34 new, 1 reinstall), Size of downloads: 309,990 kB > > I'm going to take issue with this post. Walter, you have completely misjudged what KDE is designed to do and are blaming it unfairly. KDE apps are not designed to run in isolation - they run in a greater context. That context is the KDE system. It was designed with the view that an app like okular will be installed alongside other similar apps that let you deal with other filetypes. Like audio, video, graphics, text. And so on. To do this, it needs the libs it is built on. And it needs a graphics toolkit - Qt. The reason you got such a long list of packages to install is because you do not have any Qt installed at all. If you did not have any X installed at all and wanted to emerge xpdf you would get a similar long list for exactly the same reason. The point I'm trying to make is that KDe was not designed with you in mind. KDE could never work for you because of your viewpoint
Re: [gentoo-user] Re: USE flags handling
On Thu, Jul 31, 2014 at 04:41:24AM +0200, Volker Armin Hemmann wrote > I occasionally tried razorqt or enlightenment or twm... > and yeah, they load quickly. And then they are all useless for me. I run ICEWM with 9 work areas dedicated to specific "tasks" or forums. A desktop environment doesn't provide me that much extra functionality. I suppose some of my inertia is due to starting to use ICEWM and *BOX back when I had a Dell with 256 megabytes of RAM and an 8-megabyte ATI video card. That machine lasted for 7 years or so. My current one is over 6 years old. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] depclean wants to remove all perl?
On Thursday 31 Jul 2014 06:14:56 J. Roeleveld wrote: > I always check the list from depclean to see if there is any package and/or > version that I am actually using. If yes, I add it to the world file. > (Emerge --noreplace) I don't add packages to my world file, let alone specific versions, unless I want them to be there. I let portage manage versions and dependencies. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] depclean wants to remove all perl?
On 30 July 2014 23:47:19 CEST, Mick wrote: >Having updated some perl packages, I ran perl-cleaner which failed with >some >blockers, I ran: > >emerge --deselect --ask $(qlist -IC 'perl-core/*') > >emerge -uD1a $(qlist -IC 'virtual/perl-*') > >as advised by perl-cleaner, before I ran perl-cleaner successfully. > >Following all this depclean give me a lng list of perl packages, >but I am >reluctant to hit yes, before I confirm that this correct: > > These are the packages that would be unmerged: > > perl-core/Module-Load-Conditional >selected: 0.540.0 > protected: none > omitted: none > > virtual/perl-ExtUtils-Install >selected: 1.590.0-r1 > protected: none > omitted: none > > virtual/perl-ExtUtils-Command >selected: 1.170.0-r5 > protected: none > omitted: none > > perl-core/Archive-Tar >selected: 1.900.0-r1 > protected: none > omitted: none > > perl-core/File-Spec >selected: 3.400.0 > protected: none > omitted: none > > perl-core/Time-Local >selected: 1.230.0-r1 > protected: none > omitted: none > > perl-core/CPAN-Meta-Requirements >selected: 2.122.0-r1 > protected: none > omitted: none > > perl-core/Test-Harness >selected: 3.260.0 > protected: none > omitted: none > > virtual/perl-Module-Load-Conditional >selected: 0.540.0-r1 > protected: none > omitted: none > > perl-core/ExtUtils-ParseXS >selected: 3.180.0-r1 > protected: none > omitted: none > > perl-core/IO-Compress >selected: 2.60.0 > protected: none > omitted: none > > perl-core/CPAN-Meta >selected: 2.120.921-r1 > protected: none > omitted: none > > perl-core/Compress-Raw-Bzip2 >selected: 2.60.0 > protected: none > omitted: none > > perl-core/Parse-CPAN-Meta >selected: 1.440.400-r1 > protected: none > omitted: none > > perl-core/Params-Check >selected: 0.360.0-r1 > protected: none > omitted: none > > perl-core/Module-Load >selected: 0.240.0 > protected: none > omitted: none > > perl-core/Scalar-List-Utils >selected: 1.270.0 > protected: none > omitted: none > > perl-core/Module-Build >selected: 0.400.300-r1 > protected: none > omitted: none > > perl-core/Compress-Raw-Zlib >selected: 2.60.0 > protected: none > omitted: none > > perl-core/Digest-MD5 >selected: 2.520.0-r1 > protected: none > omitted: none > > virtual/perl-IPC-Cmd >selected: 0.800.0-r1 > protected: none > omitted: none > > perl-core/CPAN-Meta-YAML >selected: 0.8.0-r1 > protected: none > omitted: none > > perl-core/Module-Metadata >selected: 1.0.11-r1 > protected: none > omitted: none > > virtual/perl-ExtUtils-Manifest >selected: 1.630.0-r1 > protected: none > omitted: none > > virtual/perl-ExtUtils-ParseXS >selected: 3.180.0-r2 > protected: none > omitted: none > > virtual/perl-IO-Zlib >selected: 1.100.0-r4 > protected: none > omitted: none > > virtual/perl-Test-Harness >selected: 3.260.0-r2 > protected: none > omitted: none > > virtual/perl-Module-CoreList >selected: 3.30.0 > protected: none > omitted: none > > virtual/perl-Module-Load >selected: 0.240.0-r1 > protected: none > omitted: none > > virtual/perl-Params-Check >selected: 0.360.0-r1 > protected: none > omitted: none > > virtual/perl-Compress-Raw-Bzip2 >selected: 2.60.0-r2 > protected: none > omitted: none > > virtual/perl-Package-Constants >selected: 0.20.0-r4 > protected: none > omitted: none > > virtual/perl-File-Temp >selected: 0.230.0 > protected: none > omitted: none > > virtual/perl-CPAN-Meta-Requirements >selected: 2.122.0-r2 > protected: none > omitted: none > > virtual/perl-Test-Simple >selected: 0.980.0-r5 > protected: none > omitted: none > > virtual/perl-Digest >selected: 1.170.0-r3 > protected: none > omitted: none > > virtual/perl-Perl-OSType >selected: 1.3.0-r1 > protected: none > omitted: none > > virtual/perl-Archive-Tar >selected: 1.900.0-r2 > protected: none > omitted: none > > virtual/perl-CPAN-Meta >selected: 2.120.921-r2 > protected: none > omitted: none > > virtual/perl-Locale-Maketext-Simple >selected: 0.210.0-r4 > protected: none > omitted: none > > virtual/perl-Module-Metadata >selected: 1.0.11-r1 > protected: none > omitted: none > > virtual/perl-ExtUtils-CBuilder >selected: 0.280.210-r1 > protected: none > omitted: none > > virtual/perl-Parse-CPAN-Meta >selected: 1.440.400-r1 > protected: none > omitted: none > > virtual/perl-JSON-PP >selected: 2.272.20-r1 > protected: none > omitted: none > > virtual/perl-CPAN-Meta-YAML >selected: 0.8.0-r2 > protected: none > omitted: none > > virtual/perl-version >selected:
Re: [gentoo-user] Re: USE flags handling
> okular is not a 'stinking pdf reader'. Nice try. But just like konqueror > it is just a wrapper around kparts and is able to deal with a lot more > files than just pdf and postscript. > > That is what 'modular' and 'code reuse' really means. > > And the opposite to what gnome does. 'oh, there is an app. Hijack it and > gnomify it and make it dependent on 2 douzend gnome libs that all do the > same but nobody ever cleaned up'. You're right about the code reuse if you're running KDE, but I'd rather not install *all* of Qt and a bunch of other crap just to view PDFs and such. I think that's all he's arguing. I love having KDE on my desktop (and okular is really nice), but on my laptop (i3wm) I spend the vast majority of my time in vim and on the terminal and shouldn't have to essentially install KDE to view a PDF when I need to check some LaTeX formatting. Just contrast with evince; I disabled nautilus integration, and my machine only has 5 gnome packages, 2 of which are icon sets. Alec
Re: [gentoo-user] Arrh - my KDE "look" has disappeared
On 29/07/2014 3:09 PM, Neil Bothwick wrote: On Tue, 29 Jul 2014 11:47:55 +0800, Andrew Lowe wrote: Fired up the 'puter last night and instead of a backdrop showing the dog doing something stupid, a task bar, the start button thingy, and a few other bits and pieces, I had the default KDE backdrop. The task bar was on the second screen, the backdrop was the default, there was no start button etc. What's happened?? Obviously KDE has freaked out in some way, but how? Where are the files that configure the look and feel of my desktop kept? I've looked in ~/Desktop and ~/.kde4 and there was nothing there. The files should be in ~/.kde4/share/config, so if ~/.kde4 is empty you have a problem. Let's hope you also have a backup. Had a look, "everything" appears to be there - no idea as to why I originally said ~/.kde4 was empty. The dates on all of the files are all over the place, that is from some time last year when I built the machine up to basically now so it looks like they are the correct files. Is there an environmental/system variable that should point to ~/.kde4 that I should check to see is correct? Andrew
Re: [gentoo-user] Re: USE flags handling
Am 31.07.2014 03:55, schrieb Walter Dnes: > On Wed, Jul 30, 2014 at 10:31:50PM +0200, Volker Armin Hemmann wrote >> Am 30.07.2014 21:48, schrieb Dale: >> >>> While to me KDE is bloated, I just try to disable what I can and carry >>> on. If my system was limited on resources, then I may use something else. >> and maybe you did exactly the wrong thing. KDE is very modular and >> reuses its modules as much as it can. Which also means: memory is only >> used once. >> >> There were once a very good (in my not so humble opinion. It think very >> highly of myself) comparism here: >> >> http://ktown.kde.org/~seli/memory/ >> (url is dead btw) >> >> and if you actually use kde apps in kde - memory consumption is lower >> than in either gnome or 'leightweight' solutions like xfce or >> windowmaker+stuff. >> >> http://web.archive.org/web/20071229030604/http://ktown.kde.org/~seli/memory/desktop_benchmark.html > The problem with KDE apps is that they're imitating what MS did with > Internet Explorer. They pointed to the itsy-bitsy-teeny-weeny little > "ie.exe" that you could delete if you felt like doing so. They > deliberately obfuscated that it was merely a front end to a ton of > system libraries that you could not remove. Back when xpdf was being > deprecated, various replacement options were suggested. I chose mupdf > rather than the KDE app "okular". Here's why. After multiple attempts > at "emerge -pv okular", I found I had to add at least the following to > package.use to get it to work... > > dev-libs/libattica qt4 > media-libs/phonon vlc > media-video/vlc dbus xcb -ffmpeg > dev-qt/qtcore qt3support > dev-qt/qtdeclarative accessibility qt3support > dev-qt/qtgui accessibility qt3support > dev-qt/qtopengl qt3support > dev-qt/qt3support accessibility > dev-qt/qtsql qt3support sqlite > dev-qt/qtsvg accessibility > sys-libs/ncurses unicode > > Seems that if I want to emerge and use KDE's "pdf reader", I need... > > phonon > vlc (or gstreamer) > libmpeg > libmad > net-dns/libidn > dev-qt/qtwebkit > > ...***FOR A STINKING PDF READER***. Here's the "emerge -pv okular" okular is not a 'stinking pdf reader'. Nice try. But just like konqueror it is just a wrapper around kparts and is able to deal with a lot more files than just pdf and postscript. That is what 'modular' and 'code reuse' really means. And the opposite to what gnome does. 'oh, there is an app. Hijack it and gnomify it and make it dependent on 2 douzend gnome libs that all do the same but nobody ever cleaned up'. > output with USE flag listings edited out... you know - useflags or tree would have been so much more meaningful... > > [d531][waltdnes][~] emerge -pv okular | sed " s/USE.*$//" > > These are the packages that would be merged, in order: > > Calculating dependencies done! > [ebuild R] sys-libs/ncurses-5.9-r3:5 > [ebuild N ] net-dns/libidn-1.28 > [ebuild N ] kde-base/kde-env-4.12.5:4/4.12 > [ebuild N ] dev-libs/libpcre-8.35:3 > [ebuild N ] app-admin/eselect-qtgraphicssystem-1.1.1 0 kB > [ebuild N ] dev-qt/qtcore-4.8.5-r2:4 > [ebuild N ] dev-qt/qtscript-4.8.5:4 > [ebuild N ] dev-qt/qtgui-4.8.5-r3:4 > [ebuild N ] dev-qt/qtsql-4.8.5:4 > [ebuild N ] dev-qt/qt3support-4.8.5:4 > [ebuild N ] dev-qt/qtdbus-4.8.5:4 > [ebuild N ] dev-qt/qtsvg-4.8.5:4 > [ebuild N ] dev-qt/qttest-4.8.5:4 > [ebuild N ] dev-qt/designer-4.8.5:4 > [ebuild N ] dev-qt/qtopengl-4.8.5:4 > [ebuild N ] dev-qt/qtxmlpatterns-4.8.5:4 > [ebuild N ] app-crypt/qca-2.0.3:2 > [ebuild N ] dev-qt/qtwebkit-4.8.5:4 > [ebuild N ] dev-qt/qtdeclarative-4.8.5:4 > [ebuild N ] x11-libs/libXScrnSaver-1.2.2-r1 > [ebuild N ] media-libs/libmpeg2-0.5.1-r2 > [ebuild N ] media-libs/libmad-0.15.1b-r7 > [ebuild N ] media-video/vlc-2.1.2:0/5-7 > [ebuild N ] dev-util/automoc-0.9.88 9 kB > [ebuild N ] kde-base/oxygen-icons-4.12.5:4/4.12 > [ebuild N ] media-libs/qimageblitz-0.0.6-r1 > [ebuild N ] dev-libs/libattica-0.4.2 > [ebuild N ] dev-libs/libdbusmenu-qt-0.9.2 > [ebuild N ] app-misc/strigi-0.7.8 > [ebuild N ] media-libs/phonon-4.6.0-r1 > [ebuild N ] media-libs/phonon-vlc-0.6.2 > [ebuild N ] kde-base/kdelibs-4.12.5-r1:4/4.12 > [ebuild N ] kde-base/katepart-4.12.5:4/4.12 > [ebuild N ] kde-base/libkexiv2-4.12.5:4/4.12 > [ebuild N ] kde-base/okular-4.12.5-r1:4/4.12 > > Total: 35 packages (34 new, 1 reinstall), Size of downloads: 309,990 kB > >
Re: [gentoo-user] Re: USE flags handling
Am 31.07.2014 02:26, schrieb Dale: > Neil Bothwick wrote: >> On Wed, 30 Jul 2014 15:54:07 -0500, Dale wrote: >> >>> The biggest thing for me, is just stuff I don't use or ever see me >>> needing. At one point, can't recall version, KDE4 was a bit of a memory >>> hog. It seems they have cleaned that up a lot since tho. Even on my >>> old rig which had 3GBs of ram and KDE3, it wasn't to bad on memory. CPU >>> wise tho, I'd hate to run KDE4 on my old rig. It is just to slow for >>> KDE4. >> I used to run KDE on a netbook with 2GB and it ran very well. True, LXDE >> was faster, but it did less. Not doing stuff faster isn't a benefit in my >> book. >> >> > That's why I use KDE still. There are things it does that I like plus > my new rig is fast enough and has plenty of ram. My old rig tho, not > KDE4. I don't think I would even try it. KDE4 is the reason I built > this new rig. > > I do have Fluxbox installed tho. I have been known to use it a few > times too. It is so fast it is unreal. > > Dale > > :-) :-) > > > I occasionally tried razorqt or enlightenment or twm... and yeah, they load quickly. And then they are all useless for me.
Re: [gentoo-user] Re: USE flags handling
On Wed, Jul 30, 2014 at 10:31:50PM +0200, Volker Armin Hemmann wrote > Am 30.07.2014 21:48, schrieb Dale: > > > While to me KDE is bloated, I just try to disable what I can and carry > > on. If my system was limited on resources, then I may use something else. > > and maybe you did exactly the wrong thing. KDE is very modular and > reuses its modules as much as it can. Which also means: memory is only > used once. > > There were once a very good (in my not so humble opinion. It think very > highly of myself) comparism here: > > http://ktown.kde.org/~seli/memory/ > (url is dead btw) > > and if you actually use kde apps in kde - memory consumption is lower > than in either gnome or 'leightweight' solutions like xfce or > windowmaker+stuff. > > http://web.archive.org/web/20071229030604/http://ktown.kde.org/~seli/memory/desktop_benchmark.html The problem with KDE apps is that they're imitating what MS did with Internet Explorer. They pointed to the itsy-bitsy-teeny-weeny little "ie.exe" that you could delete if you felt like doing so. They deliberately obfuscated that it was merely a front end to a ton of system libraries that you could not remove. Back when xpdf was being deprecated, various replacement options were suggested. I chose mupdf rather than the KDE app "okular". Here's why. After multiple attempts at "emerge -pv okular", I found I had to add at least the following to package.use to get it to work... dev-libs/libattica qt4 media-libs/phonon vlc media-video/vlc dbus xcb -ffmpeg dev-qt/qtcore qt3support dev-qt/qtdeclarative accessibility qt3support dev-qt/qtgui accessibility qt3support dev-qt/qtopengl qt3support dev-qt/qt3support accessibility dev-qt/qtsql qt3support sqlite dev-qt/qtsvg accessibility sys-libs/ncurses unicode Seems that if I want to emerge and use KDE's "pdf reader", I need... phonon vlc (or gstreamer) libmpeg libmad net-dns/libidn dev-qt/qtwebkit ...***FOR A STINKING PDF READER***. Here's the "emerge -pv okular" output with USE flag listings edited out... [d531][waltdnes][~] emerge -pv okular | sed " s/USE.*$//" These are the packages that would be merged, in order: Calculating dependencies done! [ebuild R] sys-libs/ncurses-5.9-r3:5 [ebuild N ] net-dns/libidn-1.28 [ebuild N ] kde-base/kde-env-4.12.5:4/4.12 [ebuild N ] dev-libs/libpcre-8.35:3 [ebuild N ] app-admin/eselect-qtgraphicssystem-1.1.1 0 kB [ebuild N ] dev-qt/qtcore-4.8.5-r2:4 [ebuild N ] dev-qt/qtscript-4.8.5:4 [ebuild N ] dev-qt/qtgui-4.8.5-r3:4 [ebuild N ] dev-qt/qtsql-4.8.5:4 [ebuild N ] dev-qt/qt3support-4.8.5:4 [ebuild N ] dev-qt/qtdbus-4.8.5:4 [ebuild N ] dev-qt/qtsvg-4.8.5:4 [ebuild N ] dev-qt/qttest-4.8.5:4 [ebuild N ] dev-qt/designer-4.8.5:4 [ebuild N ] dev-qt/qtopengl-4.8.5:4 [ebuild N ] dev-qt/qtxmlpatterns-4.8.5:4 [ebuild N ] app-crypt/qca-2.0.3:2 [ebuild N ] dev-qt/qtwebkit-4.8.5:4 [ebuild N ] dev-qt/qtdeclarative-4.8.5:4 [ebuild N ] x11-libs/libXScrnSaver-1.2.2-r1 [ebuild N ] media-libs/libmpeg2-0.5.1-r2 [ebuild N ] media-libs/libmad-0.15.1b-r7 [ebuild N ] media-video/vlc-2.1.2:0/5-7 [ebuild N ] dev-util/automoc-0.9.88 9 kB [ebuild N ] kde-base/oxygen-icons-4.12.5:4/4.12 [ebuild N ] media-libs/qimageblitz-0.0.6-r1 [ebuild N ] dev-libs/libattica-0.4.2 [ebuild N ] dev-libs/libdbusmenu-qt-0.9.2 [ebuild N ] app-misc/strigi-0.7.8 [ebuild N ] media-libs/phonon-4.6.0-r1 [ebuild N ] media-libs/phonon-vlc-0.6.2 [ebuild N ] kde-base/kdelibs-4.12.5-r1:4/4.12 [ebuild N ] kde-base/katepart-4.12.5:4/4.12 [ebuild N ] kde-base/libkexiv2-4.12.5:4/4.12 [ebuild N ] kde-base/okular-4.12.5-r1:4/4.12 Total: 35 packages (34 new, 1 reinstall), Size of downloads: 309,990 kB -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: USE flags handling
Neil Bothwick wrote: > On Wed, 30 Jul 2014 15:54:07 -0500, Dale wrote: > >> The biggest thing for me, is just stuff I don't use or ever see me >> needing. At one point, can't recall version, KDE4 was a bit of a memory >> hog. It seems they have cleaned that up a lot since tho. Even on my >> old rig which had 3GBs of ram and KDE3, it wasn't to bad on memory. CPU >> wise tho, I'd hate to run KDE4 on my old rig. It is just to slow for >> KDE4. > I used to run KDE on a netbook with 2GB and it ran very well. True, LXDE > was faster, but it did less. Not doing stuff faster isn't a benefit in my > book. > > That's why I use KDE still. There are things it does that I like plus my new rig is fast enough and has plenty of ram. My old rig tho, not KDE4. I don't think I would even try it. KDE4 is the reason I built this new rig. I do have Fluxbox installed tho. I have been known to use it a few times too. It is so fast it is unreal. Dale :-) :-)
[gentoo-user] Cant compile Openvz sources
Hi all! :D I'm having troubles to compile the openvz kernel :( I tryed making the config by my self, making it with " make x86_64_defconfig ", and using this: http://download.openvz.org/kernel/branches/rhel6-2.6.32/042stab053.5/configs/config-2.6.32-042stab053.5.x86_64 config file. (The official from openvz) None works. I also tryed to downloading the sources again. But is the same :S I asked on gentoo forum, but i dont get answers. I hope someone can help me please :P This is the error: [quote] scripts/kallsyms.c: En la función ‘read_symbol’: scripts/kallsyms.c:112:9: aviso: se descarta el valor de devolución de ‘fgets’, se declaró con el atributo warn_unused_result [-Wunused-result] scripts/mod/file2alias.c:797:12: aviso: se define ‘do_x86cpu_entry’ pero no se usa [-Wunused-function] scripts/mod/modpost.c: En la función ‘get_markers’: scripts/mod/modpost.c:1563:12: aviso: se descarta el valor de devolución de ‘asprintf’, se declaró con el atributo warn_unused_result [-Wunused-result] scripts/mod/modpost.c: En la función ‘add_marker’: scripts/mod/modpost.c:1993:10: aviso: se descarta el valor de devolució HOSTLD scripts/genksyms/genksyms HOSTLD scripts/mod/modpost CC kernel/bouIn file included from kernel/sched.c:2184:0: kernel/sched_fair.c: En la función ‘nr_iowait_dec_fair’: kernel/sched_fair.c:3541:23: aviso: variable ‘se’ sin usar [-Wunused-variable] kernel/sched_fair.c: En la función ‘nr_iowait_inc_fair’: kernel/sched_fair.c:3572:23: aviso: variable ‘se’ sin usar [-Wunused-variable] In file included from kernel/sched.c:2187:0: kernel/sched_autogroup.c: En la función ‘autogroup_move_group’: kernel/sched_autogroup.c:145:4: error: expected ‘while’ before ‘while_each_thread’ make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 make: *** Se espera a que terminen otras tareas In file included from include/linux/kmemtrace.h:12:0, from include/linux/slub_def.h:13, from include/linux/slab.h:203, from include/linux/percpu.h:5, from include/linux/percpu_counter.h:13, from include/linux/fs.h:452, from include/linux/sysfs.h:77, from include/linux/kobject.h:21, from include/ CC arch/x86/mm/pageattr.o CC arch/x86/mm/mmap.o CC arch/x86/mm/pat.o CC arch/x86/mm/pgtable.o AS arch/x86/vdso/vdso-note.o CC arch/x86/vdso/vclock_gettime.o CC arch/x86/mm/physaddr.o CC fs/super.o CC fs/char_dev.o CC fs/stat.o CC fs/exec.o CC fs/pipe.o CC fs/namei.o CC arch/x86/vdso/vgetcpu.o CC arch/x86/vdso/vvar.o LDS arch/x86/vdso/vdso-rhel5.lds LDS arch/x86/vdso/vdso32/vdso32.lds AS arch/x86/vdso/vdso32/note.o CC mm/mempool.o CC mm/oom_kill.o AS arch/x86/vdso/vdso32/int80.o AS arch/x86/vdso/vdso32/syscall.o AS arch/x86/vdso/vdso32/sysenter.o CC arch/x86/vdso/vdso32-setup.o CC mm/fadvise.o CC mm/maccess.o CC mm/page_alloc.o CC mm/page-writeback.o CC mm/readahead.o CC mm/swap.o CC mm/truncate.o CC mm/vmscan.o CC mm/shmem.o VDSOarch/x86/vdso/vdso.so.dbg VDSOarch/x86/vdso/vdso-rhel5.so.dbg VDSOarch/x86/vdso/vdso32-int80.so.dbg VDSOarch/x86/vdso/vdso32-syscall.so.dbg VDSOarch/x86/vdso/vdso32-sysenter.so.dbg VDSOSYM arch/x86/vdso/vdso-syms.lds VDSOSYM arch/x86/vdso/vdso-rhel5-syms.lds VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds VDSOSYM arch/x86/vdso/vdso32-syscall-syms.lds OBJCOPY arch/x86/vdso/vdso.so OBJCOPY arch/x86/vdso/vdso32-int80.so OBJCOPY arch/x86/vdso/vdso32-syscall.so OBJCOPY arch/x86/vdso/vdso-rhel5.so OBJCOPY arch/x86/vdso/vdso32-sysenter.so VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds AS arch/x86/vdso/vdso.o AS arch/x86/vdso/vdso32.o AS arch/x86/vdso/vdso-rhel5.o VDSOSYM arch/x86/vdso/vdso32-syms.lds LD arch/x86/vdso/built-in.o UPD include/linux/compile.h CC init/version.o LD init/built-in.o ude/linux/sysfs.h:158:15: error: el campo ‘ia_iattr’ tiene tipo de dato incompleto In file included from include/linux/kmemtrace.h:12:0, from include/linux/slub_def.h:13, from include/linux/slab.h:203, from include/linux/percpu.h:5, from include/linux/percpu_counter.h:13, from include/linux/fs.h:452, from include/linux/highmem.h:4, from arch/x86/mm/pageattr.c:5: include/trace/events/kmem.h:528:1: aviso: se declaró ‘struct address_space’ dentro de la lista de parámetros [activado por defecto] include/trace/events/kmem.h:528:1: aviso: su ámbito es solamente esta definición o declaración, lo cual probablemente no es lo que desea [activado por defecto] include/trace/events/kmem.h:528:1: aviso: se declaró ‘struct address_space’ dentro de la
Re: [gentoo-user] a question about updating process
On Wed, 30 July 2014, at 3:42 pm, James wrote: > >> Gentoo … I really like it ! > > Are you kidding? Really? ... you just do not realize just how rediculous > this line of reasoning/questioning is? I think you must have misunderstood. Stroller.
Re: [gentoo-user] Re: USE flags handling
On 31/07/14 04:22, Volker Armin Hemmann wrote: > Am 30.07.2014 22:18, schrieb Joost Roeleveld: >>> So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* >>> the running speed, dude!" >> It does! >> I enabled -pipe in my CFLAGS and all the software was running a lot faster >> on >> my new machine compared to my old one ;) >> > aaah a aahhh thepainmakeitstop > > *g* > anyone got benchmarks on "-pipe -pipe" ? more is better, right ... :) BillK
Re: [gentoo-user] depclean wants to remove all perl?
On 30/07/2014 23:12, Mick wrote: On Wednesday 30 Jul 2014 23:02:38 Kerin Millar wrote: On 30/07/2014 22:58, Alan McKinnon wrote: On 30/07/2014 23:47, Mick wrote: Having updated some perl packages, I ran perl-cleaner which failed with some blockers, I ran: emerge --deselect --ask $(qlist -IC 'perl-core/*') emerge -uD1a $(qlist -IC 'virtual/perl-*') as advised by perl-cleaner, before I ran perl-cleaner successfully. Following all this depclean give me a lng list of perl packages, but I am reluctant to hit yes, before I confirm that this correct: It's very likely safe: http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtual s.html I'm quite sure that whole list is now bundled with perl itself so there's no need to have the modules as well. Everything except for IO::Compress and Scalar::List::Utils. I concur; nothing about this list appears surprising. --Kerin Thank you both! I am on dev-lang/perl-5.18.2-r1 As Perl 5.16 is EOL, perhaps that's no bad thing. Incidentally, you can check whether a module is part of the Perl core by using the corelist tool. $ corelist Archive::Tar Archive::Tar was first released with perl v5.9.3 --Kerin
Re: [gentoo-user] resolv.conf is different after every reboot
On 28/07/2014 16:34, Grand Duet wrote: 2014-07-28 1:00 GMT+03:00 Kerin Millar : On 27/07/2014 21:38, Grand Duet wrote: 2014-07-27 22:13 GMT+03:00 Neil Bothwick : On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote: That's what replaces it when eth0 comes up. It looks like eth0 is not being brought up fully It sounds logical. But how can I fix it? By identifying how far it is getting and why no further. But it appears that eth0 is being brought up correctly and then the config is overwritten by the lo config. I think so. As I have already reported in another reply to this thread, it is my first reboot after commenting out the line dns_domain_lo="mynetwork" and so far it went good. Moreover, the file /etc/resolv.conf has not been overwritten. I still have to check if everything else works fine and if I will get the same result on the next reboot but I hope that the problem has been solved. But it looks like a bug in the net csript. Why lo configuration should overwrite eth0 configuration at all? I would consider it be a documentation bug at the very least. Being able to propagate different settings to resolv.conf depending on whether a given interface is up may be of value for some esoteric use-case, although I cannot think of one off-hand. Some other distros use the resolvconf application to handle these nuances. In any case, it is inexplicable that the user is invited to define dns_domain for the lo interface. Why would one want to push settings to resolv.conf based on the mere fact that the loopback interface has come up? Also, it would be a great deal less confusing if the option were named dns_search. I think that the handbook should refrain from mentioning the option at all, for the reasons stated in my previous email. Those who know that they need to define a specific search domain will know why and be capable of figuring it out. It's too bad that the handbook is still peddling the notion that this somehow has something to do with 'setting' the domain name. It is tosh of the highest order. I agree with you. But how to put it all in the right ears? I'm not entirely sure. I'd give it another shot if I thought it was worth the effort. My experience up until now is that requests for minor documentation changes are dismissed on the basis that, if it does not prevent the installation from being concluded, it's not worth bothering with [1]. I do not rate the handbook and, at this juncture, my concern is slight except for where it causes demonstrable confusion among the user community. Indeed, that's why my interest was piqued by this thread. --Kerin [1] For example: bugs 304727 and 344753
Re: [gentoo-user] depclean wants to remove all perl?
On Wednesday 30 Jul 2014 23:02:38 Kerin Millar wrote: > On 30/07/2014 22:58, Alan McKinnon wrote: > > On 30/07/2014 23:47, Mick wrote: > >> Having updated some perl packages, I ran perl-cleaner which failed with > >> some blockers, I ran: > >> > >> emerge --deselect --ask $(qlist -IC 'perl-core/*') > >> > >> emerge -uD1a $(qlist -IC 'virtual/perl-*') > >> > >> as advised by perl-cleaner, before I ran perl-cleaner successfully. > >> > >> Following all this depclean give me a lng list of perl packages, but > >> I am > > > >> reluctant to hit yes, before I confirm that this correct: > > It's very likely safe: > > > > http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtual > > s.html > > > > I'm quite sure that whole list is now bundled with perl itself so > > there's no need to have the modules as well. > > Everything except for IO::Compress and Scalar::List::Utils. I concur; > nothing about this list appears surprising. > > --Kerin Thank you both! I am on dev-lang/perl-5.18.2-r1 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] depclean wants to remove all perl?
On 30/07/2014 22:58, Alan McKinnon wrote: On 30/07/2014 23:47, Mick wrote: Having updated some perl packages, I ran perl-cleaner which failed with some blockers, I ran: emerge --deselect --ask $(qlist -IC 'perl-core/*') emerge -uD1a $(qlist -IC 'virtual/perl-*') as advised by perl-cleaner, before I ran perl-cleaner successfully. Following all this depclean give me a lng list of perl packages, but I am reluctant to hit yes, before I confirm that this correct: It's very likely safe: http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtuals.html I'm quite sure that whole list is now bundled with perl itself so there's no need to have the modules as well. Everything except for IO::Compress and Scalar::List::Utils. I concur; nothing about this list appears surprising. --Kerin
Re: [gentoo-user] depclean wants to remove all perl?
On 30/07/2014 23:47, Mick wrote: > Having updated some perl packages, I ran perl-cleaner which failed with some > blockers, I ran: > > emerge --deselect --ask $(qlist -IC 'perl-core/*') > > emerge -uD1a $(qlist -IC 'virtual/perl-*') > > as advised by perl-cleaner, before I ran perl-cleaner successfully. > > Following all this depclean give me a lng list of perl packages, but I am > reluctant to hit yes, before I confirm that this correct: It's very likely safe: http://dilfridge.blogspot.com/2014/07/perl-in-gentoo-dev-langperl-virtuals.html I'm quite sure that whole list is now bundled with perl itself so there's no need to have the modules as well. Do read the link above and check your main perl version > > These are the packages that would be unmerged: > > perl-core/Module-Load-Conditional > selected: 0.540.0 >protected: none > omitted: none > > virtual/perl-ExtUtils-Install > selected: 1.590.0-r1 >protected: none > omitted: none > > virtual/perl-ExtUtils-Command > selected: 1.170.0-r5 >protected: none > omitted: none > > perl-core/Archive-Tar > selected: 1.900.0-r1 >protected: none > omitted: none > > perl-core/File-Spec > selected: 3.400.0 >protected: none > omitted: none > > perl-core/Time-Local > selected: 1.230.0-r1 >protected: none > omitted: none > > perl-core/CPAN-Meta-Requirements > selected: 2.122.0-r1 >protected: none > omitted: none > > perl-core/Test-Harness > selected: 3.260.0 >protected: none > omitted: none > > virtual/perl-Module-Load-Conditional > selected: 0.540.0-r1 >protected: none > omitted: none > > perl-core/ExtUtils-ParseXS > selected: 3.180.0-r1 >protected: none > omitted: none > > perl-core/IO-Compress > selected: 2.60.0 >protected: none > omitted: none > > perl-core/CPAN-Meta > selected: 2.120.921-r1 >protected: none > omitted: none > > perl-core/Compress-Raw-Bzip2 > selected: 2.60.0 >protected: none > omitted: none > > perl-core/Parse-CPAN-Meta > selected: 1.440.400-r1 >protected: none > omitted: none > > perl-core/Params-Check > selected: 0.360.0-r1 >protected: none > omitted: none > > perl-core/Module-Load > selected: 0.240.0 >protected: none > omitted: none > > perl-core/Scalar-List-Utils > selected: 1.270.0 >protected: none > omitted: none > > perl-core/Module-Build > selected: 0.400.300-r1 >protected: none > omitted: none > > perl-core/Compress-Raw-Zlib > selected: 2.60.0 >protected: none > omitted: none > > perl-core/Digest-MD5 > selected: 2.520.0-r1 >protected: none > omitted: none > > virtual/perl-IPC-Cmd > selected: 0.800.0-r1 >protected: none > omitted: none > > perl-core/CPAN-Meta-YAML > selected: 0.8.0-r1 >protected: none > omitted: none > > perl-core/Module-Metadata > selected: 1.0.11-r1 >protected: none > omitted: none > > virtual/perl-ExtUtils-Manifest > selected: 1.630.0-r1 >protected: none > omitted: none > > virtual/perl-ExtUtils-ParseXS > selected: 3.180.0-r2 >protected: none > omitted: none > > virtual/perl-IO-Zlib > selected: 1.100.0-r4 >protected: none > omitted: none > > virtual/perl-Test-Harness > selected: 3.260.0-r2 >protected: none > omitted: none > > virtual/perl-Module-CoreList > selected: 3.30.0 >protected: none > omitted: none > > virtual/perl-Module-Load > selected: 0.240.0-r1 >protected: none > omitted: none > > virtual/perl-Params-Check > selected: 0.360.0-r1 >protected: none > omitted: none > > virtual/perl-Compress-Raw-Bzip2 > selected: 2.60.0-r2 >protected: none > omitted: none > > virtual/perl-Package-Constants > selected: 0.20.0-r4 >protected: none > omitted: none > > virtual/perl-File-Temp > selected: 0.230.0 >protected: none > omitted: none > > virtual/perl-CPAN-Meta-Requirements > selected: 2.122.0-r2 >protected: none > omitted: none > > virtual/perl-Test-Simple > selected: 0.980.0-r5 >protected: none > omitted: none > > virtual/perl-Digest > selected: 1.170.0-r3 >protected: none > omitted: none > > virtual/perl-Perl-OSType > selected: 1.3.0-r1 >protected: none > omitted: none > > virtual/perl-Archive-Tar > selected: 1.900.0-r2 >protected: none > omitted: none > > virtual/perl-CPAN-Meta > selected: 2.120.921-r2 >protected: none > omitted: none > > virtual/perl-Locale-Maketext-Simple > selected: 0.210.0-r4 >protected: none > omitted: none > > virtual/perl-Module-Metadata > selected: 1.0.11
[gentoo-user] depclean wants to remove all perl?
Having updated some perl packages, I ran perl-cleaner which failed with some blockers, I ran: emerge --deselect --ask $(qlist -IC 'perl-core/*') emerge -uD1a $(qlist -IC 'virtual/perl-*') as advised by perl-cleaner, before I ran perl-cleaner successfully. Following all this depclean give me a lng list of perl packages, but I am reluctant to hit yes, before I confirm that this correct: >>> These are the packages that would be unmerged: perl-core/Module-Load-Conditional selected: 0.540.0 protected: none omitted: none virtual/perl-ExtUtils-Install selected: 1.590.0-r1 protected: none omitted: none virtual/perl-ExtUtils-Command selected: 1.170.0-r5 protected: none omitted: none perl-core/Archive-Tar selected: 1.900.0-r1 protected: none omitted: none perl-core/File-Spec selected: 3.400.0 protected: none omitted: none perl-core/Time-Local selected: 1.230.0-r1 protected: none omitted: none perl-core/CPAN-Meta-Requirements selected: 2.122.0-r1 protected: none omitted: none perl-core/Test-Harness selected: 3.260.0 protected: none omitted: none virtual/perl-Module-Load-Conditional selected: 0.540.0-r1 protected: none omitted: none perl-core/ExtUtils-ParseXS selected: 3.180.0-r1 protected: none omitted: none perl-core/IO-Compress selected: 2.60.0 protected: none omitted: none perl-core/CPAN-Meta selected: 2.120.921-r1 protected: none omitted: none perl-core/Compress-Raw-Bzip2 selected: 2.60.0 protected: none omitted: none perl-core/Parse-CPAN-Meta selected: 1.440.400-r1 protected: none omitted: none perl-core/Params-Check selected: 0.360.0-r1 protected: none omitted: none perl-core/Module-Load selected: 0.240.0 protected: none omitted: none perl-core/Scalar-List-Utils selected: 1.270.0 protected: none omitted: none perl-core/Module-Build selected: 0.400.300-r1 protected: none omitted: none perl-core/Compress-Raw-Zlib selected: 2.60.0 protected: none omitted: none perl-core/Digest-MD5 selected: 2.520.0-r1 protected: none omitted: none virtual/perl-IPC-Cmd selected: 0.800.0-r1 protected: none omitted: none perl-core/CPAN-Meta-YAML selected: 0.8.0-r1 protected: none omitted: none perl-core/Module-Metadata selected: 1.0.11-r1 protected: none omitted: none virtual/perl-ExtUtils-Manifest selected: 1.630.0-r1 protected: none omitted: none virtual/perl-ExtUtils-ParseXS selected: 3.180.0-r2 protected: none omitted: none virtual/perl-IO-Zlib selected: 1.100.0-r4 protected: none omitted: none virtual/perl-Test-Harness selected: 3.260.0-r2 protected: none omitted: none virtual/perl-Module-CoreList selected: 3.30.0 protected: none omitted: none virtual/perl-Module-Load selected: 0.240.0-r1 protected: none omitted: none virtual/perl-Params-Check selected: 0.360.0-r1 protected: none omitted: none virtual/perl-Compress-Raw-Bzip2 selected: 2.60.0-r2 protected: none omitted: none virtual/perl-Package-Constants selected: 0.20.0-r4 protected: none omitted: none virtual/perl-File-Temp selected: 0.230.0 protected: none omitted: none virtual/perl-CPAN-Meta-Requirements selected: 2.122.0-r2 protected: none omitted: none virtual/perl-Test-Simple selected: 0.980.0-r5 protected: none omitted: none virtual/perl-Digest selected: 1.170.0-r3 protected: none omitted: none virtual/perl-Perl-OSType selected: 1.3.0-r1 protected: none omitted: none virtual/perl-Archive-Tar selected: 1.900.0-r2 protected: none omitted: none virtual/perl-CPAN-Meta selected: 2.120.921-r2 protected: none omitted: none virtual/perl-Locale-Maketext-Simple selected: 0.210.0-r4 protected: none omitted: none virtual/perl-Module-Metadata selected: 1.0.11-r1 protected: none omitted: none virtual/perl-ExtUtils-CBuilder selected: 0.280.210-r1 protected: none omitted: none virtual/perl-Parse-CPAN-Meta selected: 1.440.400-r1 protected: none omitted: none virtual/perl-JSON-PP selected: 2.272.20-r1 protected: none omitted: none virtual/perl-CPAN-Meta-YAML selected: 0.8.0-r2 protected: none omitted: none virtual/perl-version selected: 0.990.200-r1 protected: none omitted: none All selected packages: virtual/perl-CPAN-Meta-2.120.921-r2 virtual/perl- Package-Constants-0.20.0-r4 perl-core/Compress-Raw-Bzip2-2.60.0 virtual/perl- Module-Metadata-1.0.11-r1 virtual/perl-Archive-Tar-1.900.0-r2 perl- core/Module-Lo
Re: [gentoo-user] Re: USE flags handling
On Wed, 30 Jul 2014 15:54:07 -0500, Dale wrote: > The biggest thing for me, is just stuff I don't use or ever see me > needing. At one point, can't recall version, KDE4 was a bit of a memory > hog. It seems they have cleaned that up a lot since tho. Even on my > old rig which had 3GBs of ram and KDE3, it wasn't to bad on memory. CPU > wise tho, I'd hate to run KDE4 on my old rig. It is just to slow for > KDE4. I used to run KDE on a netbook with 2GB and it ran very well. True, LXDE was faster, but it did less. Not doing stuff faster isn't a benefit in my book. -- Neil Bothwick Those who live by the sword get shot by those who don't. signature.asc Description: PGP signature
Re: [gentoo-user] Re: USE flags handling
Volker Armin Hemmann wrote: > and maybe you did exactly the wrong thing. KDE is very modular and > reuses its modules as much as it can. Which also means: memory is only > used once. There were once a very good (in my not so humble opinion. > It think very highly of myself) comparism here: > http://ktown.kde.org/~seli/memory/ (url is dead btw) and if you > actually use kde apps in kde - memory consumption is lower than in > either gnome or 'leightweight' solutions like xfce or > windowmaker+stuff. > http://web.archive.org/web/20071229030604/http://ktown.kde.org/~seli/memory/desktop_benchmark.html The biggest thing for me, is just stuff I don't use or ever see me needing. At one point, can't recall version, KDE4 was a bit of a memory hog. It seems they have cleaned that up a lot since tho. Even on my old rig which had 3GBs of ram and KDE3, it wasn't to bad on memory. CPU wise tho, I'd hate to run KDE4 on my old rig. It is just to slow for KDE4. Dale :-) :-)
Re: [gentoo-user] Re: USE flags handling
Am 30.07.2014 22:43, schrieb Alan McKinnon: > On 30/07/2014 22:22, Volker Armin Hemmann wrote: >> Am 30.07.2014 22:18, schrieb Joost Roeleveld: So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* the running speed, dude!" >>> It does! >>> I enabled -pipe in my CFLAGS and all the software was running a lot faster >>> on >>> my new machine compared to my old one ;) >>> >> aaah a aahhh thepainmakeitstop >> >> *g* > but but but but, -pipe is Gentoo's go-fast-stripes! > > I can see it for myself - my Acer Aspire One and my i7 laptop both have > -pipe enabled and the laptop is soo much faster at compiling! See? > > > so much pain. so much hatred.
Re: [gentoo-user] Re: USE flags handling
On 30/07/2014 22:22, Volker Armin Hemmann wrote: > Am 30.07.2014 22:18, schrieb Joost Roeleveld: >>> So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* >>> the running speed, dude!" >> It does! >> I enabled -pipe in my CFLAGS and all the software was running a lot faster >> on >> my new machine compared to my old one ;) >> > aaah a aahhh thepainmakeitstop > > *g* but but but but, -pipe is Gentoo's go-fast-stripes! I can see it for myself - my Acer Aspire One and my i7 laptop both have -pipe enabled and the laptop is soo much faster at compiling! See? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: USE flags handling
Am 30.07.2014 21:48, schrieb Dale: > Neil Bothwick wrote: >> Small software can be bloated, large software can be bloat-free. It's all >> about what is useful. "functional" != "bloated", but all too often >> "lightweight", "bloat free" software can also be described as "limited" >> or "functionally challenged". >> >> > That is true. Some code can be really small and do a lot. Same can be > said for the opposite. > > Maybe this comparison will work. Small and gets the job done. > Bicycle. Bloated. 18 wheeler truck. If all you want to do is ride a > relatively short distance with no load, bicycle will get the job done. > It won't do well if you want to move 20 tons somewhere tho. The 18 > wheeler truck is good if you need to pull 20 tons somewhere but is a bit > bloated if you are just going to ride up the street to see a neighbor. > It's also a bit harder to park too. ;-) > > While to me KDE is bloated, I just try to disable what I can and carry > on. If my system was limited on resources, then I may use something else. and maybe you did exactly the wrong thing. KDE is very modular and reuses its modules as much as it can. Which also means: memory is only used once. There were once a very good (in my not so humble opinion. It think very highly of myself) comparism here: http://ktown.kde.org/~seli/memory/ (url is dead btw) and if you actually use kde apps in kde - memory consumption is lower than in either gnome or 'leightweight' solutions like xfce or windowmaker+stuff. http://web.archive.org/web/20071229030604/http://ktown.kde.org/~seli/memory/desktop_benchmark.html
Re: [gentoo-user] Re: USE flags handling
Am 30.07.2014 22:18, schrieb Joost Roeleveld: >> So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* >> the running speed, dude!" > It does! > I enabled -pipe in my CFLAGS and all the software was running a lot faster on > my new machine compared to my old one ;) > aaah a aahhh thepainmakeitstop *g*
Re: [gentoo-user] Re: USE flags handling
On Wednesday 30 July 2014 20:26:48 Alan McKinnon wrote: > On 30/07/2014 20:02, Volker Armin Hemmann wrote: > > This 'de-bloat' crap - who came up with that? People who use it all the > > times seldomly realize that the 'small and unbloated' software they use > > is in a lot of cases neither small, nor not bloated. > > Usually it comes from the same headspace that ricing comes from. Humans > are all about perception, very very very few of them can actually look > at things in an unbiased way. So it goes like this: > > User hates Gnome. [opinion] > User decides that because Gnome integrates so many things vertically > then Gnome must necessarily be bloated. [invalid conclusion not backed > up by facts] > User decides to try Razor|LXDE|Enlightenment|*box|whatever [valid activity] > User likes [opinion] > User concludes that is therefore "better" than Gnome > [erronously equate specific opinion with fact for the general case] > Therefore is not bloated and Gnome is, to satisfy wrong > conclusion at #2 [I can't even begin to think what fallacy this is] > > > Not much opinion in any of that. > We humans are mostly hard-wired to react based on past experience and > data blindly accepted as fact in the past. 9 times out of 10 this helps > you leap out of the way of the tiger seeking to have you for lunch. You > got this ability from dad's genes and it must be raising the odds for > you and he otherwise he wouldn't have survived long enough to sire you. > If you stop to think about the tiger, he is for sure going to have a > nice lunch. So we humans that survived did so by jumping to conclusions > and having them work out OK on average. This new-fangled idea of > actually thinking about things all the way through is a very new idea, > and most of the species hasn't gotten the hang of it yet. This does still seem to be a valid survival requirement for a large part of the worlds population though, including where you are. For people living in a "so-called" civilized world, tigers are only found inside places commonly called a "zoo" :) > So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* > the running speed, dude!" It does! I enabled -pipe in my CFLAGS and all the software was running a lot faster on my new machine compared to my old one ;) -- Joost
Re: [gentoo-user] Re: USE flags handling
Neil Bothwick wrote: > Small software can be bloated, large software can be bloat-free. It's all > about what is useful. "functional" != "bloated", but all too often > "lightweight", "bloat free" software can also be described as "limited" > or "functionally challenged". > > That is true. Some code can be really small and do a lot. Same can be said for the opposite. Maybe this comparison will work. Small and gets the job done. Bicycle. Bloated. 18 wheeler truck. If all you want to do is ride a relatively short distance with no load, bicycle will get the job done. It won't do well if you want to move 20 tons somewhere tho. The 18 wheeler truck is good if you need to pull 20 tons somewhere but is a bit bloated if you are just going to ride up the street to see a neighbor. It's also a bit harder to park too. ;-) While to me KDE is bloated, I just try to disable what I can and carry on. If my system was limited on resources, then I may use something else. Dale :-) :-)
Re: [gentoo-user] Re: USE flags handling
On 30/07/2014 20:56, James wrote: >> Usually it comes from the same headspace that ricing comes from. > Wow, dude! a serious compliment from one of my many heros! > > Do remember that my knowledge of "ricing" comes from the very coolest > and early vintige motorcycles: The word ricing has a fine honourable heritage from way back many years ago. But lately it means something else altogether :-( Much like "hacking" -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: a question about updating process
On Wed, Jul 30, 2014 at 7:12 PM, James wrote: > Sorry for being blunt, but you just do not realize just how rediculous > this line of reasoning/questioning is? Well, honestly I don't blame myself! I am new to the Linux (FOSS) world and I don't know very much about it. After some distro hopping I decided to switch to gentoo because I learnt that easy necessarily doesn't mean simple and I liked the way gentoo is making an operating system. However I think it takes a long time for me to familiarize myself to this world, so I guess more of this rediculous statement will be on the way! And my apologies in advance! Thanks and have a nice time.
Re: [gentoo-user] Re: ECC-ram, it is worth it.
On 07/30/14 03:16, Volker Armin Hemmann wrote: Am 30.07.2014 11:14, schrieb Edward M: I just went to Alternate, clicked on their cheapest ASUS Am3 board: ECC yes. See? Easy. Yes, easy. I looked at many Asus boards and they do mention ECC in the Specs page. I stand corrected. Thanks for the info.
Re: [gentoo-user] Re: USE flags handling
On Wed, 30 Jul 2014 20:02:11 +0200, Volker Armin Hemmann wrote: > >> YOU have chosen a somewhat minimalist path with your desktop, wisely > >> avoiding "bloat_ware_city" > > Personally, I prefer USE="-hyperbole" :) > > > >> But, to avoid pain do keep some minimal > >> collection of flags. Python is CRITICAL on gentoo, so ask before > >> verging out on Python! > > Bear in mind that USE flags control *optional* features and > > dependencies. Setting USE="-python" will not prevent python being > > installed, nor will it break portage, but it will "de-bloat" those > > packages that come with optional python interfaces and bindings. > > and it might break packages in features in surprising ways. > > People who tell newbies that -* could be used at all, should be flogged. > > In a public place. With video. :-) > This 'de-bloat' crap - who came up with that? I hope you realise I was being ironic there, in responding to a "bloat hater" :) > People who use it all the > times seldomly realize that the 'small and unbloated' software they use > is in a lot of cases neither small, nor not bloated. Small software can be bloated, large software can be bloat-free. It's all about what is useful. "functional" != "bloated", but all too often "lightweight", "bloat free" software can also be described as "limited" or "functionally challenged". -- Neil Bothwick Yeah, but what's the speed of dark? signature.asc Description: PGP signature
[gentoo-user] Re: USE flags handling
behrouz khosravi gmail.com> writes: > On Wed, Jul 30, 2014 at 6:37 PM, James tampabay.rr.com> wrote: > Thanks for your advice. They were surely helpful. My pleasure. > This 'de-bloat' crap - who came up with that? People who use it all the > times seldomly realize that the 'small and unbloated' software they use > is in a lot of cases neither small, nor not bloated. I wish I could take credit for it; it is a very, very popular concept, characterize our newest noob, as you like Lots of folks have lots of reasons to reduce the space/ram/cup resource consumption, particularly for things they do not want and quite often due to constraints on resources(ymmv). > Usually it comes from the same headspace that ricing comes from. Wow, dude! a serious compliment from one of my many heros! Do remember that my knowledge of "ricing" comes from the very coolest and early vintige motorcycles: https://www.google.com/search?client=seamonkey-a&rls=org.mozilla: en-US:unofficial&tbm=isch&source=univ&sa=X&ei=BjzZU_iXEuvmsAT74oKADA& ved=0CEoQsAQ&biw=886&bih=829&q=Original rice-rockets motorcycle Bloat (http://www.merriam-webster.com/dictionary/bloated) Full Definition of BLOATED 1 : obnoxiously vain 2 a : being much larger than what is warranted now now boys, try not be so full of angst with your choices. Gentoo is about choices; and bloat by it's very nature, is in the eyes of the beholder. Some guys like a 'big boodie, some guys like it skinny! >From a technical perspective, just look at the amazing world of embedded systems.. bloat will get you fired cause your embedded system will run slower than your competitors on similar hardware. Enjoy! James
Re: [gentoo-user] USE flags handling
On 30/07/2014 19:57, Volker Armin Hemmann wrote: > Am 29.07.2014 19:04, schrieb behrouz khosravi: >> Hello everyone. >> I just concurred my fear and jumped to installing gentoo! >> So far so good! >> Before installing on my laptop and desktop, I am trying on virtual box >> and the system is running Fluxbox very good.(default profile) >> Now I am thinking about managing USE flags. >> What if I disable everything in the make.conf ( I mean USE="-*" ) and >> gradually add the needed flags to package.use? > you will break you system. Volker is correct. The reason you will break your system is that you do not have enough knowledge to know what to put back, and you don't know how to read the error messages and know what they mean. Here's what portage does NOT do: Tell you that flag x is missing and this will cause issues a, b and c, then give you exact instructions how to make it better. Here's what portage DOES do: Give you some weird error message with the word "backtrack" in it, or messages like "no parents that could not be satisfied by other packages in slot" or something about blockers in flashing red blink text, or it might even just say nothing giving the impression everything succeeded. And then your computer explodes. Still wanna try USE="-*" ? > >> I am not trying to have severe control, I just want to expand my knowledge! >> thanks. >> > then don't do stupid things like USE=-* > > > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] USE flags handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/29/14 21:04, behrouz khosravi wrote: | Hello everyone. I just concurred my fear and jumped to installing | gentoo! So far so good! Before installing on my laptop and | desktop, I am trying on virtual box and the system is running | Fluxbox very good.(default profile) Now I am thinking about | managing USE flags. What if I disable everything in the make.conf | ( I mean USE="-*" ) and gradually add the needed flags to | package.use? I am not trying to have severe control, I just want to | expand my knowledge! thanks. Smokey: Start emacs, Dude, I'm marking it -* . Walter Sobchak: [pulls out a gun] Smokey, my friend, you are entering a world of pain. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJT2TpTAAoJEK64IL1uI2hasZ8H/3w5EA6ymBpmdu0aWK+zB2Ol 7l5iKHwrwyssRLawxnW9PgvOxXivYIpHErs1NUR4HKMG4Jo+o1k/eVSULkvOGF1L eORmcQKpgJa0Nynq9/BeDQ6WT4rH8nKjnMDvQ8/XAf5VMB5qwH+iT0VocmA5RaXX JdFWYYOKOfmtYjT+Dp8ABueolcibZ0VQik/4rVZ2r4FBsZCUe70bTkteMYKhItSk DWkpkImLbTNoDNizaOAHvaBuBn/LJjpvrSei/wB1cbfQPqg7PRAChof6XCyOm4bC ZfEN5mKiY2cuZYHKu0lOXhCfJ4wiyAGm4/WUiImFmH9rWzdrbcga7IuWT08qtto= =aky0 -END PGP SIGNATURE-
Re: [gentoo-user] Re: USE flags handling
On 30/07/2014 20:02, Volker Armin Hemmann wrote: > This 'de-bloat' crap - who came up with that? People who use it all the > times seldomly realize that the 'small and unbloated' software they use > is in a lot of cases neither small, nor not bloated. > > > Usually it comes from the same headspace that ricing comes from. Humans are all about perception, very very very few of them can actually look at things in an unbiased way. So it goes like this: User hates Gnome. [opinion] User decides that because Gnome integrates so many things vertically then Gnome must necessarily be bloated. [invalid conclusion not backed up by facts] User decides to try Razor|LXDE|Enlightenment|*box|whatever [valid activity] User likes [opinion] User concludes that is therefore "better" than Gnome [erronously equate specific opinion with fact for the general case] Therefore is not bloated and Gnome is, to satisfy wrong conclusion at #2 [I can't even begin to think what fallacy this is] Not much opinion in any of that. We humans are mostly hard-wired to react based on past experience and data blindly accepted as fact in the past. 9 times out of 10 this helps you leap out of the way of the tiger seeking to have you for lunch. You got this ability from dad's genes and it must be raising the odds for you and he otherwise he wouldn't have survived long enough to sire you. If you stop to think about the tiger, he is for sure going to have a nice lunch. So we humans that survived did so by jumping to conclusions and having them work out OK on average. This new-fangled idea of actually thinking about things all the way through is a very new idea, and most of the species hasn't gotten the hang of it yet. So now you know why ricers swear blind that -pipe in CFLAGS "*doubles* the running speed, dude!" -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: USE flags handling
On Wed, Jul 30, 2014 at 6:37 PM, James wrote: > ... Thanks for your advice. They were surely helpful. > http://swift.siphos.be/linux_sea/ > > (Sven is a great human! He not only overseas much of the documentation, > he one of the SeLinux folks, should you venture into those waters) > Oh yea, I have read the "Linux Sea" and it was great. Very Informative.
Re: [gentoo-user] Re: USE flags handling
Am 30.07.2014 17:02, schrieb Neil Bothwick: > On Wed, 30 Jul 2014 14:07:30 + (UTC), James wrote: > >> YOU have chosen a somewhat minimalist path with your desktop, wisely >> avoiding "bloat_ware_city" > Personally, I prefer USE="-hyperbole" :) > >> But, to avoid pain do keep some minimal >> collection of flags. Python is CRITICAL on gentoo, so ask before >> verging out on Python! > Bear in mind that USE flags control *optional* features and dependencies. > Setting USE="-python" will not prevent python being installed, nor will > it break portage, but it will "de-bloat" those packages that come with > optional python interfaces and bindings. and it might break packages in features in surprising ways. People who tell newbies that -* could be used at all, should be flogged. In a public place. With video. This 'de-bloat' crap - who came up with that? People who use it all the times seldomly realize that the 'small and unbloated' software they use is in a lot of cases neither small, nor not bloated.
Re: [gentoo-user] USE flags handling
Am 29.07.2014 19:04, schrieb behrouz khosravi: > Hello everyone. > I just concurred my fear and jumped to installing gentoo! > So far so good! > Before installing on my laptop and desktop, I am trying on virtual box > and the system is running Fluxbox very good.(default profile) > Now I am thinking about managing USE flags. > What if I disable everything in the make.conf ( I mean USE="-*" ) and > gradually add the needed flags to package.use? you will break you system. > I am not trying to have severe control, I just want to expand my knowledge! > thanks. > then don't do stupid things like USE=-*
Re: [gentoo-user] USE flags handling
Peter Humphrey wrote: > On Wednesday 30 July 2014 05:37:08 Dale wrote: > >> English is the only language I know and even I mess it up at times. > Yes, but then you are American ;) > True but sometimes, I suck at it. For the record, I am bad to leave the word "not" or "n't" out. Talk about a monumental change in meaning. ROFL Imagine talking about the command rm and leaving that out. o_O Still, I think we do our best when someone posts and English is not their first language. I know it is hard sometimes for people to post and get it right but still, we all try. Dale :-) :-)
Re: [gentoo-user] Re: ECC-ram, it is worth it.
Am 30.07.2014 13:25, schrieb Rich Freeman: > On Wed, Jul 30, 2014 at 6:14 AM, Volker Armin Hemmann > wrote: >> pretty easy actually. When I looked for ECC support, ALL Asus boards >> supported it officially - and a whole bunch of Gigabyte boards according >> to their forums. >> > Interesting, the Gigabyte board I'm using makes no mention of it. > Just something that needs to be considered up-front. > > It is still a constraint though - if only 10% of the boards support > ECC on the AMD side, then you're committing to an AMD CPU, and you may > find it harder to find the other features you're looking for (number > of RAM slots, PCI(e) ports, SATA ports, SLI/crossfire, clock control, > good price, etc). > > Rich > > Asus M5A99X Evo 2.0 had all I ever wanted. Plus something. My old gigabyte does not mention ECC either. But the Gigabyte Forums said yes. Seriously, it looks like you guys are making excuses ...
Re: [gentoo-user] Re: USE flags handling
On Wed, 30 Jul 2014 14:07:30 + (UTC), James wrote: > YOU have chosen a somewhat minimalist path with your desktop, wisely > avoiding "bloat_ware_city" Personally, I prefer USE="-hyperbole" :) > But, to avoid pain do keep some minimal > collection of flags. Python is CRITICAL on gentoo, so ask before > verging out on Python! Bear in mind that USE flags control *optional* features and dependencies. Setting USE="-python" will not prevent python being installed, nor will it break portage, but it will "de-bloat" those packages that come with optional python interfaces and bindings. One USE flags that new users often select, mistakenly, is doc. Package documentation such as man pages, info pages and readmes is installed by default. The doc USE flag enables the building and installation of developer and API documentation, and usually comes with a swathe of dependencies. It should never be enabled globally. -- Neil Bothwick There is absolutely no substitute for a genuine lack of preparation. signature.asc Description: PGP signature
[gentoo-user] Re: a question about updating process
behrouz khosravi gmail.com> writes: > I guess I got it know ! > And I must say that the way Gentoo is working now, is simple, no doubts. If you are really interested in using GIT with gentoo, then read up on overlays and layman "layman -L" shows experimental and code_hacks in progress. GIT among other code management systems are used. Git is the most common. NEVER, use an overlay to replace a gentoo stable package, only to install something additional or non-critical! (you've been warned!). > And I am surprised to hear that Gentoo is so strict to follow upstream. > I guess it makes it the most vanilla flavored, And I really like it ! Are you kidding? Really? Who the hell is going to even touch, yet alone maintain some of the advanced mathematics libraries we all enjoy on Gentoo? Many are difficult as hell to get stable on gentoo and use in other (science) projects; just as one example. We stand tall, here at gentoo, because we have the collective wisdom to use the work provided by the larger community of hackers, coders, students and yes burnt_out_too_often_abused_admins who often appear to have bad attitudes.. (hi Alan!) Here's but one example, you should take on to manage, upgrade and enhance in your spare time? http://www.dune-project.org/ Here is another one (you do like video on your workstation?: media-video/ffmpeg Sorry for being blunt, but you just do not realize just how rediculous this line of reasoning/questioning is? hth, James
[gentoo-user] Re: USE flags handling
behrouz khosravi gmail.com> writes: > Walter Dnes waltdnes.org> wrote: > > In my make.conf I have... > > USE_BASE="-* a52 aac bzip2 cxx fortran ncurses netifrc nptl nptlonly > > nsplugin offensive openssl posix > readline ssl threads vim-syntax zlib" > > USE_CPU="mmx mmxext sse sse2 sse3 ssse3" > > USE_VIDEO="X dga dri exif ffmpeg flac classic gif intel jpeg mng mp3 > > mpeg ogg opengl png rtmp theora tiff > truetype vorbis xcomposite webm x264 xpm xv xvid xvmc" > > USE="${USE_BASE} ${USE_CPU} ${USE_VIDEO}" > > The way that you have managed the USE flag is neat, and I will do the same. > Thanks for your help. Howdy Behrouz, Gentoo is a very wonderful OS, and we have lots of "Special" folks that are very capable, wise but often tainted, as you will discover. Walter, like myself, is a minmalist. Others are right too, that your first journey into "Gentoo" you need to follow the beaten path for a while before you venture out, naked and alone. We've all borked a system or 2, some abuse the that honor YOU have chosen a somewhat minimalist path with your desktop, wisely avoiding "bloat_ware_city". But, to avoid pain do keep some minimal collection of flags. Python is CRITICAL on gentoo, so ask before verging out on Python! Look at the defaults for your selected profile and what Walter has suggested. jArch_Linux documentation is often useful too. When in doubt, keep the flag, until you are assured it's removal will not result in a broken (borked?) system. You have a lot of reading to do on the www.gentoo.wiki and other gentoo pages (here are a few) man euse (euse -iand euse -) eix (man eix) man equery gentoolkit (is your swiss army knife for gentoo) http://www.gentoo.org/dyn/use-index.xml#doc_chap1 http://wiki.gentoo.org/wiki/OpenRC (hopefully, you are using openrc and not systemd ?) http://swift.siphos.be/linux_sea/ (Sven is a great human! He not only overseas much of the documentation, he one of the SeLinux folks, should you venture into those waters) This is not a complete list of good reading by any means, but a start. good hunting! James
Re: [gentoo-user] USE flags handling
On Wednesday 30 July 2014 05:37:08 Dale wrote: > English is the only language I know and even I mess it up at times. Yes, but then you are American ;) -- Regards Peter
Re: [gentoo-user] Re: ECC-ram, it is worth it.
On Wed, Jul 30, 2014 at 6:14 AM, Volker Armin Hemmann wrote: > > pretty easy actually. When I looked for ECC support, ALL Asus boards > supported it officially - and a whole bunch of Gigabyte boards according > to their forums. > Interesting, the Gigabyte board I'm using makes no mention of it. Just something that needs to be considered up-front. It is still a constraint though - if only 10% of the boards support ECC on the AMD side, then you're committing to an AMD CPU, and you may find it harder to find the other features you're looking for (number of RAM slots, PCI(e) ports, SATA ports, SLI/crossfire, clock control, good price, etc). Rich
Re: [gentoo-user] Ideapad-laptop
On 30-Jul-2014 4:30 pm, "Mick" wrote: > > On Wednesday 30 Jul 2014 11:53:25 Nilesh Govindrajan wrote: > > So I got a new Lenovo G50. > > I found all the required drivers in kernel itself. Seems to be quite Linux > > friendly so far (not installed desktop yet). > > > > There's one problem though. The kernel module ideapad-laptop which > > apparently recognizes the hotkey stuff, backlight and some other things > > doesn't let me use wireless. rfkill shows it's hard blocked. Is there any > > way to change this? > > > > Some Google results tell me that this is related to the WiFi toggle via > > windows. The machine never contained windows ( I bought it with freedos). > > > > I'm not comfortable with opening it to remove CMOS battery as suggested by > > yet another Google search result. > > What does 'rfkill enable wlan0' give you? It should be able to override any > hotkey setting. > > -- > Regards, > Mick The soft block gets removed, but hard block remains, and there's no hardware switch for the same. If I remove the module it works without any problems.
Re: [gentoo-user] Ideapad-laptop
On Wednesday 30 Jul 2014 11:53:25 Nilesh Govindrajan wrote: > So I got a new Lenovo G50. > I found all the required drivers in kernel itself. Seems to be quite Linux > friendly so far (not installed desktop yet). > > There's one problem though. The kernel module ideapad-laptop which > apparently recognizes the hotkey stuff, backlight and some other things > doesn't let me use wireless. rfkill shows it's hard blocked. Is there any > way to change this? > > Some Google results tell me that this is related to the WiFi toggle via > windows. The machine never contained windows ( I bought it with freedos). > > I'm not comfortable with opening it to remove CMOS battery as suggested by > yet another Google search result. What does 'rfkill enable wlan0' give you? It should be able to override any hotkey setting. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Ideapad-laptop
So I got a new Lenovo G50. I found all the required drivers in kernel itself. Seems to be quite Linux friendly so far (not installed desktop yet). There's one problem though. The kernel module ideapad-laptop which apparently recognizes the hotkey stuff, backlight and some other things doesn't let me use wireless. rfkill shows it's hard blocked. Is there any way to change this? Some Google results tell me that this is related to the WiFi toggle via windows. The machine never contained windows ( I bought it with freedos). I'm not comfortable with opening it to remove CMOS battery as suggested by yet another Google search result.
Re: [gentoo-user] USE flags handling
Philip Webb wrote: > 140730 behrouz khosravi wrote: > >> Now it is obvious English is not my mother tongue! > I suspect that may be true of a majority of Gentooers : > we're all used to interpreting others' words > & trying to be careful to be clear when we do know English well. > > English is the only language I know and even I mess it up at times. So, we all have to read between the lines at times. ;-) Dale :-) :-)
Re: [gentoo-user] Re: ECC-ram, it is worth it.
Am 30.07.2014 11:14, schrieb Edward M: I just went to Alternate, clicked on their cheapest ASUS Am3 board: ECC yes. See? Easy.
Re: [gentoo-user] Re: ECC-ram, it is worth it.
Am 30.07.2014 11:14, schrieb Edward M: > On 07/29/14 11:18, Frank Steinmetzger wrote: >> On Sat, Jul 26, 2014 at 11:00:26PM -0700, Edward MN wrote: >>> On 07/26/14 15:55, walt wrote: On 07/26/2014 10:39 AM, Volker Armin Hemmann wrote: > [894019.770058] [Hardware Error]: MC4 Error (node 0): DRAM ECC error > detected on the NB. > […] > and this, my children, is why I am using ECC ram. > […] > And this evening, with a thunderstorm outside I got that beauty > above... Is ECC memory a drop-in replacement for ordinary RAM, or does it need a special motherboard? >>> yeah, requires a motherboard that supports ECC ram. >> >> Big was my surprise to learn that our old Pentium 3 PC from 1999 has ECC >> support in its three RAM sockets. The problem today is the artificial >> paritioning of the market. >> >> It seems nigh impossible (at least in the Intel world, please correct me >> regarding AMD) to have ECC RAM in a normal Home PC these days, >> especially in >> an ITX form factor, as I am currently investigating. There are Xeons >> for the >> 1150 “consumer socket”, but ECC is only supported by server chipsets >> such as >> the C series. Those come either on ITX boards with abysmal I/O >> capabilities >> for home use or on high-power workstation ATX boards that cost a small >> fortune. *sigh* >> >> I would have liked the aspect of a system that tells me when >> something goes >> wrong, but there seems no such thing for my requirements. So I must help >> myself with file checksums when dealing with my archive disks. >> > > > Unfortunately, I think it would be difficult finding a home-user board > with ECC support. since, nowadays appears ECC is mostly for systems > where data corruption is unacceptable, such a bank,etc > pretty easy actually. When I looked for ECC support, ALL Asus boards supported it officially - and a whole bunch of Gigabyte boards according to their forums.
Re: [gentoo-user] Re: ECC-ram, it is worth it.
On 07/29/14 11:18, Frank Steinmetzger wrote: On Sat, Jul 26, 2014 at 11:00:26PM -0700, Edward MN wrote: On 07/26/14 15:55, walt wrote: On 07/26/2014 10:39 AM, Volker Armin Hemmann wrote: [894019.770058] [Hardware Error]: MC4 Error (node 0): DRAM ECC error detected on the NB. […] and this, my children, is why I am using ECC ram. […] And this evening, with a thunderstorm outside I got that beauty above... Is ECC memory a drop-in replacement for ordinary RAM, or does it need a special motherboard? yeah, requires a motherboard that supports ECC ram. Big was my surprise to learn that our old Pentium 3 PC from 1999 has ECC support in its three RAM sockets. The problem today is the artificial paritioning of the market. It seems nigh impossible (at least in the Intel world, please correct me regarding AMD) to have ECC RAM in a normal Home PC these days, especially in an ITX form factor, as I am currently investigating. There are Xeons for the 1150 “consumer socket”, but ECC is only supported by server chipsets such as the C series. Those come either on ITX boards with abysmal I/O capabilities for home use or on high-power workstation ATX boards that cost a small fortune. *sigh* I would have liked the aspect of a system that tells me when something goes wrong, but there seems no such thing for my requirements. So I must help myself with file checksums when dealing with my archive disks. Unfortunately, I think it would be difficult finding a home-user board with ECC support. since, nowadays appears ECC is mostly for systems where data corruption is unacceptable, such a bank,etc