Re: [gentoo-user] BINPKG_COMPRESS portage variable
> On 31 Aug 2017, at 13:55, Francesco Turco wrote: > > I just set BINPKG_COMPRESS="xz" in /etc/portage/make.conf in order to > compress binary packages with the xz algorithm. It seems to work, but > binary packages filenames still end with .tbz2 instead of .txz. That doesn't sound right. I'd file a report at bugs.gentoo.org Stroller.
[gentoo-user] Is my SSD dying?
Hello list, For the last week or two my NVMe SSD isn't being detected on startup. I get this error on manual invocation: # smartctl -a /dev/nvme0n1 smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.12.5-gentoo] (local build) Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org /dev/nvme0n1: Unable to detect device type Please specify device type with the -d option. Most things still seem to be working, but do I need to rush out and buy another drive? This one's only 18 months old. I don't really want to box up the machine and send it to Watford under warranty. Two things that aren't working properly are KMail (surprise!), and BOINC, which insists that VirtualBox isn't installed, when of course it (more or less) always has been. -- Regards, Peter.
Re: [gentoo-user] Is my SSD dying?
În 1 septembrie 2017 12:46:39 EEST, Peter Humphrey a scris: >Hello list, > >For the last week or two my NVMe SSD isn't being detected on startup. I >get >this error on manual invocation: > ># smartctl -a /dev/nvme0n1 >smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.12.5-gentoo] (local >build) >Copyright (C) 2002-15, Bruce Allen, Christian Franke, >www.smartmontools.org > >/dev/nvme0n1: Unable to detect device type >Please specify device type with the -d option. > Smartmontools supports NVMe starting from version 6.5. > >Most things still seem to be working, but do I need to rush out and buy > >another drive? This one's only 18 months old. I don't really want to >box up >the machine and send it to Watford under warranty. > >Two things that aren't working properly are KMail (surprise!), and >BOINC, >which insists that VirtualBox isn't installed, when of course it (more >or >less) always has been. Is the boinc user in the vboxusers group?
Re: [gentoo-user] BINPKG_COMPRESS portage variable
On Fri, Sep 1, 2017, at 11:28, Stroller wrote: > That doesn't sound right. I'd file a report at bugs.gentoo.org Done: https://bugs.gentoo.org/show_bug.cgi?id=629538 -- https://www.fturco.net/
Re: [gentoo-user] processor speed
On 08/30/2017 01:51 PM, R0b0t1 wrote: > Like I mention in another thread (and like Rich touches on) power > savings can be an incentive to upgrade, besides the increase in speed. > Power efficiency and speed generally increase in multiples greater > than one, so you are reducing the cost and time of compilations or > general use by a lot in the end. > > Look at Alan's quoted build times for an example. > I plan to upgrade but it probably won't be until early next year. Broken appliances and vehicles in need of repair... Where I am power is 8.5c/kWh CAD, it's so cheap compared to other parts of the world... spending over a thousand dollars to save $20/year in power is not really worth it. If I was paying 30c/kWh I would've upgraded already. Dan
Re: [gentoo-user] Is my SSD dying?
On 09/01/2017 02:46 AM, Peter Humphrey wrote: > Hello list, > > For the last week or two my NVMe SSD isn't being detected on startup. I get > this error on manual invocation: > > # smartctl -a /dev/nvme0n1 > smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.12.5-gentoo] (local build) > Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org > > /dev/nvme0n1: Unable to detect device type > Please specify device type with the -d option. > > > Most things still seem to be working, but do I need to rush out and buy > another drive? This one's only 18 months old. I don't really want to box up > the machine and send it to Watford under warranty. > > Two things that aren't working properly are KMail (surprise!), and BOINC, > which insists that VirtualBox isn't installed, when of course it (more or > less) always has been. > If your BIOS isn't detecting it, it's probably on its way out. Before dismissing it to that though, I'd see if there's a firmware update for it. I had a Crucial (regular SSD, non-NVME) that was doing this and after a firmware update it's still going 3 years later. Make sure you back up your data on it (if you can.) Dan
[gentoo-user] Rename /dev/nvme0n1 to /dev/sda
My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts with the script I use to manage about 12 similar laptops running Gentoo. Is there a udev method for renaming the disk that will work well with any USB disks that happen to also be attached? crw--- 1 root root 252, 0 Aug 31 11:34 /dev/nvme0 brw-rw 1 root disk 259, 0 Aug 31 11:34 /dev/nvme0n1 brw-rw 1 root disk 259, 1 Aug 31 11:34 /dev/nvme0n1p1 brw-rw 1 root disk 259, 2 Aug 31 11:34 /dev/nvme0n1p2 - Grant
[gentoo-user] High resolution on a 13 inch screen
My laptop's 13" screen has a native resolution of 3200x1800 which makes everything crazy small on-screen. Is there a good method for telling Xorg or xfce4 to compensate, or should I one-at-a-time my applications? I can adjust the resolution down but it makes the colors look weird. - Grant
[gentoo-user] Re: High resolution on a 13 inch screen
On 2017-09-01, Grant wrote: > My laptop's 13" screen has a native resolution of 3200x1800 which > makes everything crazy small on-screen. Is there a good method for > telling Xorg or xfce4 to compensate, or should I one-at-a-time my > applications? I can adjust the resolution down but it makes the > colors look weird. There's a DPI setting in X which most modern desktops/apps pay attention to when scaling fonts and images, but it's ignored by older apps that use fixed, bitmapped fonts and hard-wired icon images. So, first check to make sure that the DPI setting is correct: $ grep DPI /var/log/Xorg.0.log [ 408.135] (--) NVIDIA(0): DPI set to (99, 98); computed from "UseEdidDpi" X config [ 408.141] (--) NVIDIA(1): DPI set to (99, 98); computed from "UseEdidDpi" X config [ 408.145] (==) intel(2): DPI set to (96, 96) On anything even remotely modern, it should get read auto-magically from the display itself. If that's correct, then I'm not sure what the next step would be. -- Grant Edwards grant.b.edwardsYow! The SAME WAVE keeps at coming in and COLLAPSING gmail.comlike a rayon MUU-MUU ...
[gentoo-user] Re: High resolution on a 13 inch screen
> My laptop's 13" screen has a native resolution of 3200x1800 which > makes everything crazy small on-screen. Is there a good method for > telling Xorg or xfce4 to compensate, or should I one-at-a-time my > applications? I can adjust the resolution down but it makes the > colors look weird. After some more research, it turns out this is a pretty well-known problem on the Linux desktop (it's called HiDPI) without a good solution... except for this: https://forums.linuxmint.com/viewtopic.php?t=159064 https://bugs.freedesktop.org/show_bug.cgi?id=94816 The solution is to patch xrandr with the capability to do nearest neighbor filtering and run xrandr like this: xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" It works great. - Grant
Re: [gentoo-user] Re: High resolution on a 13 inch screen
Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: > > My laptop's 13" screen has a native resolution of 3200x1800 which > > makes everything crazy small on-screen. Is there a good method for > > telling Xorg or xfce4 to compensate, or should I one-at-a-time my > > applications? I can adjust the resolution down but it makes the > > colors look weird. > > > After some more research, it turns out this is a pretty well-known > problem on the Linux desktop (it's called HiDPI) without a good > solution... except for this: > > https://forums.linuxmint.com/viewtopic.php?t=159064 > https://bugs.freedesktop.org/show_bug.cgi?id=94816 > > The solution is to patch xrandr with the capability to do nearest > neighbor filtering and run xrandr like this: > > xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" > > It works great. > I don't see how it can be called great. This is pretty much losing most of the benefits you have with a HiDPI screen, by just making it be almost the same as a 1600x900 screen, except the scaling involves some nearest neighbor filtering, which sometimes might be good, sometimes bad, and never as good as rendering things in HiDPI. For HiDPI you want the toolkit to support it properly and configure it as such. GTK+3 is such a toolkit, but outside of GNOME (where it works out of the box), I don't know what exactly it takes to set things up. Plus you'll need a solution for your gtk2/whatever other things, preferably one that doesn't make things worse for gtk3 things, like that xrandr hack does. Probably something like gsettings set org.gnome.desktop.interface scaling-factor 2 combined with something for the other stuff that doesn't mess with the former. Outside GNOME, maybe exporting GDK_SCALE=2 works, if the dconf setting isn't honored outside it. Mart
Re: [gentoo-user] Re: High resolution on a 13 inch screen
>> > My laptop's 13" screen has a native resolution of 3200x1800 which >> > makes everything crazy small on-screen. Is there a good method for >> > telling Xorg or xfce4 to compensate, or should I one-at-a-time my >> > applications? I can adjust the resolution down but it makes the >> > colors look weird. >> >> >> After some more research, it turns out this is a pretty well-known >> problem on the Linux desktop (it's called HiDPI) without a good >> solution... except for this: >> >> https://forums.linuxmint.com/viewtopic.php?t=159064 >> https://bugs.freedesktop.org/show_bug.cgi?id=94816 >> >> The solution is to patch xrandr with the capability to do nearest >> neighbor filtering and run xrandr like this: >> >> xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" >> >> It works great. >> > > I don't see how it can be called great. This is pretty much losing most > of the benefits you have with a HiDPI screen, by just making it be > almost the same as a 1600x900 screen, except the scaling involves some > nearest neighbor filtering, which sometimes might be good, sometimes > bad, and never as good as rendering things in HiDPI. > > For HiDPI you want the toolkit to support it properly and configure it > as such. GTK+3 is such a toolkit, but outside of GNOME (where it works > out of the box), I don't know what exactly it takes to set things up. > Plus you'll need a solution for your gtk2/whatever other things, > preferably one that doesn't make things worse for gtk3 things, like > that xrandr hack does. > > Probably something like > gsettings set org.gnome.desktop.interface scaling-factor 2 > combined with something for the other stuff that doesn't mess with the > former. > Outside GNOME, maybe exporting GDK_SCALE=2 works, if the dconf setting > isn't honored outside it. I hope you'll agree that sounds like a mess. When I said it was great I meant in comparison to running 3200x1800 with defaults (unusable) or running 1600x900 (blurry and hard to look at). Admittedly this is not a good place for Linux desktop to be. Is there a good way to run xrandr when X starts so it doesn't have to be run per user and will apply to lightdm? - Grant
Re: [gentoo-user] Re: High resolution on a 13 inch screen
On Friday, September 1, 2017 7:28:48 PM CEST Mart Raudsepp wrote: > Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: > > > My laptop's 13" screen has a native resolution of 3200x1800 which > > > makes everything crazy small on-screen. Is there a good method for > > > telling Xorg or xfce4 to compensate, or should I one-at-a-time my > > > applications? I can adjust the resolution down but it makes the > > > colors look weird. > > > > After some more research, it turns out this is a pretty well-known > > problem on the Linux desktop (it's called HiDPI) without a good > > solution... except for this: > > > > https://forums.linuxmint.com/viewtopic.php?t=159064 > > https://bugs.freedesktop.org/show_bug.cgi?id=94816 > > > > The solution is to patch xrandr with the capability to do nearest > > neighbor filtering and run xrandr like this: > > > > xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" > > > > It works great. > > I don't see how it can be called great. This is pretty much losing most > of the benefits you have with a HiDPI screen, by just making it be > almost the same as a 1600x900 screen, except the scaling involves some > nearest neighbor filtering, which sometimes might be good, sometimes > bad, and never as good as rendering things in HiDPI. > > For HiDPI you want the toolkit to support it properly and configure it > as such. GTK+3 is such a toolkit, but outside of GNOME (where it works > out of the box), I don't know what exactly it takes to set things up. > Plus you'll need a solution for your gtk2/whatever other things, > preferably one that doesn't make things worse for gtk3 things, like > that xrandr hack does. > > Probably something like > gsettings set org.gnome.desktop.interface scaling-factor 2 > combined with something for the other stuff that doesn't mess with the > former. > Outside GNOME, maybe exporting GDK_SCALE=2 works, if the dconf setting > isn't honored outside it. In KDE/Plasma there is a scaling setting in the display section. The scales go from 1 to 3 (in steps of 0.1) Seems to work, I don't need it on my displays as I tend to simply increase the font-sizes where necessary. -- Joost
[gentoo-user] electron and sslv3
Hello,
I am having troubles installing dev-util/electron, related to linking in
"ssl3" in the final step of the ebuild, from build log:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lssl3
FYI on ssl, I only want a "working/current" ssl and/or tls installation and
I don't care for the details around the installation other than I would
like - as much as possible - "ssl" to be future proof and compatible with
current and new installs; in this case I just want electron, and I can't
install the package because of this linking error. I can successfully build
by hacking the final link step and simply remove the reference to "-lssl",
below:
> cd
$PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/chromium-52.0.2743.82/out/R
> x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a
obj/atom/app/electron.atom_main.o obj/libelectron_lib.a
o... lib/libnode.so lib/libv8.so -lz -lhttp_parser -lssl -lcrypto -
and compiles fine.
There are no "ssl" use flags on electron?:
my build:
[ebuild N~] dev-util/electron-1.3.13-r1 USE="proprietary-codecs
system-ffmpeg tcmalloc -cups -custom-cflags -gnome -gnome-keyring -hidpi
-kerberos -lto (-neon) -pic -pulseaudio (-selinux) {-test}" L10N="en-GB"
from https://packages.gentoo.org/packages/dev-util/electron:
LOCAL USE FLAGS
- hidpi
- lto
- pic
- proprietary-codecs
- system-ffmpeg
- tcmalloc
FYI, this is state of ssl on my machine:
* dev-libs/openssl
Latest version available: 1.0.2l
Latest version installed: 1.0.2l
* dev-perl/IO-Socket-SSL
Latest version available: 2.24.0
Latest version installed: 2.24.0
* dev-perl/Net-SMTP-SSL
Latest version available: 1.30.0
Latest version installed: 1.30.0
* dev-perl/Net-SSLeay
Latest version available: 1.810.0
Latest version installed: 1.810.0
* net-libs/gnutls
Latest version available: 3.5.13
Latest version installed: 3.5.13
Any help on how to successfully compile and install electron would be much
appreciated.
Re: [gentoo-user] Re: High resolution on a 13 inch screen
Hi everybody, Am Freitag, 1. September 2017, 21:08:51 CEST schrieb J. Roeleveld: > On Friday, September 1, 2017 7:28:48 PM CEST Mart Raudsepp wrote: > > Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: > [...] > > In KDE/Plasma there is a scaling setting in the display section. > The scales go from 1 to 3 (in steps of 0.1) > > Seems to work, I don't need it on my displays as I tend to simply increase > the font-sizes where necessary. this led to really ugly proportions on my 317,5 mm FullHD display (1920x1080 pi). I added "-dpi 144" to my Xorg string; in my case that’s a line in sddm config. That one does not reflect my actual DPI (simplified sqrt(1920^2+1080^2)/12.5 = 176), but was after trial and error the best result I got. Hope that helps, Nils -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: High resolution on a 13 inch screen
Nils Freydank wrote: > Hi everybody, > > Am Freitag, 1. September 2017, 21:08:51 CEST schrieb J. Roeleveld: > > On Friday, September 1, 2017 7:28:48 PM CEST Mart Raudsepp wrote: > > > Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: > > [...] > > > > In KDE/Plasma there is a scaling setting in the display section. > > The scales go from 1 to 3 (in steps of 0.1) > > > > Seems to work, I don't need it on my displays as I tend to simply > > increase the font-sizes where necessary. > this led to really ugly proportions on my 317,5 mm FullHD display > (1920x1080 pi). > > I added "-dpi 144" to my Xorg string; in my case that’s a line in > sddm config. That one does not reflect my actual DPI (simplified > sqrt(1920^2+1080^2)/12.5 = 176), but was after trial and error the > best result I got. You can also set this parameter in XFCE preferences: xfce4-appearance-settings -> Fonts tab -> Own DPI-Value But AFAIK the dpi setting is only for fonts. If you also wanna have bigger window decorations then start xfwm4-settings and set Default-hdpi or Default-xhdpi as theme. AFAIK both themes are part of x11-themes/xfwm4-themes. If you wanna set the icon sizes (panel, menu, buttons, toolbar) for the gtk2-theme that you use, then edit the gtkrc file of this theme. Before you do this you should copy the complete theme directory into ~/.themes/ (if .themes doesn't exist then create it), then rename it and then edit the gtkrc file. Finally you can set this theme as your new theme. By example: cp -r /usr/share/themes/Xfce-basic/ ~/.themes/ mv ~/.themes/Xfce-basic ~/.themes/Xfce-basic_big-icons vi ~/.themes/Xfce-basic_big-icons/gtk-2.0/gtkrc I have a 140 DPI display and insert these two lines at top of my gtkrc: gtk-toolbar-icon-size = large-toolbar gtk-icon-sizes = "panel-menu=32,32:panel=32,32:gtk-button=24,24:gtk-large-toolbar=48,48:gtk-small-toolbar=32,32" To be honest, I forgot for what the first line is good for. It's some time ago that I did this and my memory isn't as reliable as it was 20 years ago. ;-) However some programs don't have a GUI that is ready yet for HiDPI displays. By example I have not found an option in Gimp to increase the size of its tiny toolbar icons. -- Regards wabe
Re: [gentoo-user] Is my SSD dying?
On Fri, Sep 1, 2017 at 7:46 PM, Peter Humphrey wrote: > Hello list, > > For the last week or two my NVMe SSD isn't being detected on startup. I get > this error on manual invocation: > > # smartctl -a /dev/nvme0n1 > smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.12.5-gentoo] (local build) > > Probably also worth updating to 4.12.10, there's some important sounding security fixes in it, and the Changelogs for 4.12.6 and 4.12.8 mention nvme.
Re: [gentoo-user] electron and sslv3
On Sat, Sep 2, 2017 at 6:26 AM, Damo Brisbane wrote: > Hello, > > I am having troubles installing dev-util/electron, related to linking in > "ssl3" in the final step of the ebuild, from build log: > > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lssl3 > > > FYI on ssl, I only want a "working/current" ssl and/or tls installation > and I don't care for the details around the installation other than I would > like - as much as possible - "ssl" to be future proof and compatible with > current and new installs; in this case I just want electron, and I can't > install the package because of this linking error. I can successfully build > by hacking the final link step and simply remove the reference to "-lssl", > below: > > > > cd $PORTAGE_TMPDIR/dev-util/electron-1.3.13-r1/work/ > chromium-52.0.2743.82/out/R > > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--a obj/atom/app/electron. > atom_main.o obj/libelectron_lib.a o... lib/libnode.so lib/libv8.so -lz > -lhttp_parser -lssl -lcrypto - > > > and compiles fine. > > There are no "ssl" use flags on electron?: > My first guess would be that your openssl is not compiled with sslv3. The ebuild for electron only asks for >=dev-libs/openssl-1.0.2g:0=[-bindist] not openssl[sslv3]. If that's the problem then there's a bug in electrons ebuild. What does emerge -pv openssl show for use flags? However, ssl is pretty much deprecated these days due to security issues, so unless you have a need to support something that cant do TLS, you're better off leaving it out. Another issue may be that -lssl may be a loose term for SSL+TLS...
Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda
On Fri, Sep 1, 2017 at 11:10 AM, Grant wrote: > My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts > with the script I use to manage about 12 similar laptops running > Gentoo. Is there a udev method for renaming the disk that will work > well with any USB disks that happen to also be attached? > > crw--- 1 root root 252, 0 Aug 31 11:34 /dev/nvme0 > brw-rw 1 root disk 259, 0 Aug 31 11:34 /dev/nvme0n1 > brw-rw 1 root disk 259, 1 Aug 31 11:34 /dev/nvme0n1p1 > brw-rw 1 root disk 259, 2 Aug 31 11:34 /dev/nvme0n1p2 > Admittedly I don't know how to do what you are asking, but my experience has shown me the better solution is likely to modify your management script and to store the device-specific configuration external to the script and associate it with the device. R0b0t1.
Re: [gentoo-user] BINPKG_COMPRESS portage variable
On Fri, Sep 1, 2017 at 8:17 AM, Francesco Turco wrote: > On Fri, Sep 1, 2017, at 11:28, Stroller wrote: >> That doesn't sound right. I'd file a report at bugs.gentoo.org > > Done: https://bugs.gentoo.org/show_bug.cgi?id=629538 > This is happening? I was positive crossdev was generating .tar.xz package files in my arm64 root. I need to find a time to check that.
Re: [gentoo-user] Re: High resolution on a 13 inch screen
Hello friends, On Fri, Sep 1, 2017 at 12:16 PM, Grant wrote: >> My laptop's 13" screen has a native resolution of 3200x1800 which >> makes everything crazy small on-screen. Is there a good method for >> telling Xorg or xfce4 to compensate, or should I one-at-a-time my >> applications? I can adjust the resolution down but it makes the >> colors look weird. > Which laptop do you have? I would recommend configuring applications one at a time and submitting bug reports to applications which are not sufficiently configurable. > After some more research, it turns out this is a pretty well-known > problem on the Linux desktop (it's called HiDPI) without a good > solution... except for this: > The problems quoted here still apply to Windows despite Microsoft exercising complete control over the display subsystem. On OSX, Apple decided to specify UI sizes in "points" by default and require that programs make API calls to enable HiDPI awareness. This has its own problems, and can make things look worse. Surprisingly I find myself agreeing with Microsoft's solution more often than not. Regardless of my opinion, Apple's solution is impossible to implement on Linux as there is no controlling body that dictates how X11/Wayland toolkits work. Most issues are in individual programs and libraries and can't be solved at the same time. If I want to render something and be HiDPI aware, I must: 0) Have appropriately sized assets for higher resolutions. Most programs fail this step. 1) Retrieve the display metrics. 2) Use the display metrics to calculate all sizes. Without #0, menu items will look extremely grainy if they are enlarged. The UI will be usable but it will be extremely unpleasant to look at. There are some Microsoft-authored programs that use this strategy, and all unupdated OSX programs do this. Even if a programmer attempts #2, there are a lot of sizes. It can be extremely hard to position a window or size it in anything but pixels and some positioning mechanisms do not take relative locations. There may be interfaces that one needs to interact with that are not specific in how sizes are specified, and the application developer may not have access to a HiDPI screen. On Fri, Sep 1, 2017 at 12:28 PM, Mart Raudsepp wrote: > Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: >> > My laptop's 13" screen has a native resolution of 3200x1800 which >> > makes everything crazy small on-screen. Is there a good method for >> > telling Xorg or xfce4 to compensate, or should I one-at-a-time my >> > applications? I can adjust the resolution down but it makes the >> > colors look weird. >> >> >> After some more research, it turns out this is a pretty well-known >> problem on the Linux desktop (it's called HiDPI) without a good >> solution... except for this: >> >> https://forums.linuxmint.com/viewtopic.php?t=159064 >> https://bugs.freedesktop.org/show_bug.cgi?id=94816 >> >> The solution is to patch xrandr with the capability to do nearest >> neighbor filtering and run xrandr like this: >> >> xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" >> >> It works great. >> > > I don't see how it can be called great. This is pretty much losing most > of the benefits you have with a HiDPI screen, by just making it be > almost the same as a 1600x900 screen, except the scaling involves some > nearest neighbor filtering, which sometimes might be good, sometimes > bad, and never as good as rendering things in HiDPI. > I think this might be an acceptable solution, but I would suggest turning antialiasing off so fonts are shown with crisp edges. > For HiDPI you want the toolkit to support it properly and configure it > as such. GTK+3 is such a toolkit, but outside of GNOME (where it works > out of the box), I don't know what exactly it takes to set things up. > Plus you'll need a solution for your gtk2/whatever other things, > preferably one that doesn't make things worse for gtk3 things, like > that xrandr hack does. > I would recommend switching to a CLI workflow. Then all that needs to be set up properly is your terminal emulator. R0b0t1.
Re: [gentoo-user] Easiest way to block domains?
On Tue, 29 Aug 2017 01:38:42 -0400 Walter Dnes wrote: > I'm running a Core2-duo desktop from 2008 with 3 gigs of ram. I want > to run it into the ground, not throw it away while it's still > functional. With Gentoo optimization, pluse using ICEWM, it's generally > snappy. But there are a few web pages that throw the kitchen sink of > 3rd-pary adservers+trackers. 178 unique servers for one web page will > peg the load from the web browser to 150% of 1 cpu core. On a 2-core > machine, that is bad. The browser is unresponsive for a few seconds at > a time. > > I'm building up a rather large hosts file, but the adservers have a > gazillion subnames for each domain, in a deliberate attempt to bypass > hosts files. It would be more effective block entire domains. Is there > a lightweight DNS server, or some iptables trick, or whatever, that'll > block specified domains? Use uBlock origin. Both firefox and chromium work perfectly fine for me on a Core2Duo host. Best regards, Andrew Savchenko pgp0mlyc7absR.pgp Description: PGP signature
Re: [gentoo-user] Rename /dev/nvme0n1 to /dev/sda
On Fri, 1 Sep 2017 09:10:13 -0700 Grant wrote: > My new laptop uses /dev/nvme0n1 instead of /dev/sda which conflicts > with the script I use to manage about 12 similar laptops running > Gentoo. Is there a udev method for renaming the disk that will work > well with any USB disks that happen to also be attached? Yes, you can write an udev rule to create any names or symlinks you want on any events selected by triggers. See http://www.reactivated.net/writing_udev_rules.html and udev docs. Best regards, Andrew Savchenko pgpzaY5zG6AW0.pgp Description: PGP signature
