Eclipse – too small icons on high dpi screens – workaround for KDE Plasma by scaling on X11 and Wayland

I have to work with Eclipse (version 4.32) again for a while. After two days of relatively intensive work, I am a bit frustrated. One reason is the small size of the icons – 16×16 px. Not only in the main icon taskbar. There are minuscule symbols elsewhere – e.g. in the bar on the left side of the editor section. Regarding e.g. the tiny symbol for code folding: You can almost not see the “+” or “-” symbols on a high resolution screen …

One can scale almost all font-sizes within Eclipse – but not such a basic thing as the icon/symbol size or the icon bar height.

I have three QHD screens (2560×1440) at my present workplace. At another site there are 2 4K screens. The following image can give you an impression for the QHD situation – if you have a QHD, UHD or 4K screen yourself and not zoomed the browser contents already. For screens with lower resolution see below.

Before you say this looks quite OK, check the following:

  • Open this post on a desktop screen in a window wider than 800 px.
  • Enforce normal content size size in your browser (no zoom! Ctrl-0).
  • Get a natural distance to your working QHD, UHD or 4K monitor (like 80+ cm). In case you have a QHD screen you get already the right impression.
  • Users who just have a monitor with a 1920×1200 resolution must in addition downscale their browser contents to around 80% (QHD) or 55% (UHD, 4K) to get the right impression of the problem. (After Ctrl-0)
  • Folks with QHD get the right 4K impression by scaling down to 66%. (After Ctrl-0)

While for QHD the working conditions may still appear to be OK, you get a real problem for UHD and 4K resolutions. The font-size may still be OK (after having adapted it). The unadaptable symbol sizes, however, are far too small. At least in my opinion. But even on my standard QHD screens I personally do not feel comfortable after a while.

In this post I want to share some workarounds. The methods described may be interesting for other GTK applications, too. Keep in mind that the images in this post may give you a wrong impression if you zoomed the browser contents. But later on, when I demonstrate the effect of some measures, only relative sizes of fonts and icons are of interest.

Continue reading

Eclipse IDE – how to limit the number of of CPU cores used on a Linux PC

In the very hot days which we experienced in Germany the last week my old ventilation cooled PC suffers a bit when all of my CPU cores get under full load. Temperatures up to 70&grad; Celsius despite an Alpenföhn ventilator are beyond my normal experience and tolerance. The culprit was Eclipse with PyDev.

I had installed the latest Eclipse version (4.32.0) some days before. And opened a new Python project based on a directory with tons of code for Machine Learning classes. As a default the PyDev validator started to check the code for problems. It does so by using all available CPU cores and threads in parallel. Yeah, Eclipse works highly parallelized with its underlying Java VM. As I had a lot of complex code the code analysis lasted for some minutes – putting an extreme load on my PC.

So, my question was: How can one limit the number of CPU cores/threads used by Eclipse?

For Linux the answer is surprisingly simple:

We can use the “taskset” command. E.g., if I wanted to use the first 4 CPU cores (or recognized threads) we would write on the command line:

taskset -c 0-3 ./eclipse & 

This works perfectly! The initial code analysis takes a bit longer – but the load on the PC got down. Happy coding!

 

More fun with veth, network namespaces, VLANs – IV – L2-segments, same IP-subnet, ARP and routes

In the course of my present post series on veths, network namespaces and virtual VLANs

we have studied a somewhat academic network scenario:

Two L2-segments were attached to a common network namespace, with all IPs of both segments belonging to one and the same IP subnet class. The network traffic was analyzed for different route configurations. Only detailed routes ensured a symmetric handling of packets in both segments.

The IP-setup makes the scenario a bit peculiar. It is not a situation an admin would normally create. Instead the IPs of each segment would be members of one of two distinct and different IP-subnets.

However, our scenario already taught us some important lessons to keep in mind when we approach our eventual objective:

Sooner or later we want to answer the question how to configure virtual VLAN configurations, in which veth subdevices for tagged VLAN lines terminate in a common and routing namespace.

By our academic scenario we found out that we need to set up much more specific routes than the standard ones which are automatically created in the wake of “ip addr add” commands. Despite the fact that forwarding was disabled in the coupling network namespace! Only with clear and fitting routes we got a reasonable behavior of our artificial network with respect to ICMP- and ARP-requests in the last post (III).

Well, this is, in a way, a platitude. Whenever you have a special network you must adapt the routes to your network layout. This, of course, includes the resolution of ambiguities which our scenario introduced. The automatically defined routes were insufficient and caused an asymmetry in the ICMP-replies in the otherwise very symmetric configuration (see the drawing below).

Nevertheless, the last post and also older posts on veths and virtual VLANs triggered an intense discussion of two of my readers with me concerning ARP. In this post I, therefore, want to look at the impact of routes on ARP-requests and ARP-replies between the namespaces in more detail.

The key question is whether and to what extend the creation and emission of ARP-packets via a particular network interface may become route-dependent in namespaces (or on hosts) with multiple network interfaces.

While we saw a clear and route dependent asymmetry in the reaction of the network to ICMP-requests, we did not fully analyze how this asymmetry showed up on the ARP-level.

In my opinion we have already seen that ARP-requests triggered within ICMP-requests showed some asymmetry regarding the NIC used and the segment addressed – depending on the defined routes. But the experimental data of the last post did not show the flow of ARP-replies in detail. And we only regarded ARP-requests triggered by ICMP-requests. I.e. we watched ARP-requests created by the Linux-kernel to support the execution of ICMP-requests, but not pure and standalone ARP-requests.

Therefore, it is still unclear

  • whether routes have an impact on pure standalone ARP-requests, i.e. ARP-requests not caused by ICMP-requests (or by other requests of higher layer protocols),
  • whether routes do have an impact on ARP-replies.

The experiments below will deliver detailed information to clarify these points.

When I speak of ARP-tables below, I am referring to the ARP-caches of the various network namespaces in our scenario.

Continue reading