linuxism

https://www.makeopensourcegreatagain.com/rpms/

Mon 10 Aug 2020 // 06:55 UTC

Google has confirmed it plans to contribute some of its in-house threading code to the Linux kernel, but hasn’t disclosed its motivations beyond a desire to share.

As described by Googler Peter Oskolkov on the Linux kernel mailing list, the tech is “an M:N userspace threading subsystem backed by Google-private SwitchTo Linux Kernel API. This subsystem provides latency-sensitive services at Google with fine-grained user-space control/scheduling over what is running when, and this subsystem is used widely internally (called schedulers or fibers).”

Scheduling and managing threads matters when you want to make sure your CPU cores don’t lie idle if there’s work they could usefully be doing. M:N threading is one approach, and it's typically more efficient than the 1:1 approach most kernels tend to use.

The Register asked Google to explain what it’s up to with this contribution to the kernel and was told simply: "Threading technology is widely used across Google."

Which makes a lot of sense given Google tries to wring the most out of its colossal server fleet.

We were also told the web goliath “generally wants to open source helpful production APIs" and is releasing this code in the spirit that saw it share the Abseil scheduling code and tcmalloc memory allocation routines.

While the post to the kernel mailing list targets version 5.9 of the Linux kernel, Google told us it has: "No firm timeframe to share at this time" regarding when Linux users might be able to play with its SwitchTo API. According to Oskolkov, the latest patches are "the first step to open-source this work."

Google first discussed this work in 2013 in a talk, and the lengthy time elapsed since that event could mean that Google now runs more advanced scheduling code in-house and is therefore comfortable open-sourcing old work.

Android’s reliance on the Linux kernel could be another factor here, as with many smartphones now boasting multi-core processors better threading could be desirable.

A few posts to the mailing list discussed the API in recent weeks, and Oskolkov said he’d submitted the last of the code. With the Linux 5.9 merge window currently open, we’ll soon know if it will hit the kernel sooner or later.

source - www.theregister.com/2020/08/10/google_scheduling_code_reaches_linux/

Download the clientCitrix Workspace App

https://www.citrix.com/downloads/workspace-app/legacy-workspace-app-for-linux/workspace-app-for-linux-1912.html

# dnf install ./ICAClient-rhel-19.12.0.19-0.x86_64.rpm

# dnf install motif motif.i686 libXaw libXaw.i686 libidn1.34

# /opt/Citrix/ICAClient/util/ctx_rehash

# ALL_CERTS='/etc/pki/ca-trust/extracted/pem/*.pem /etc/pki/tls/*.pem /usr/share/pki/ca-trust-source/ca-bundle.trust.crt'

# CITRIX=/opt/Citrix/ICAClient/keystore/cacerts

# for x in ${ALL_CERTS}; do ln -sf "${x}" "${CITRIX}" done

# ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /opt/Citrix/ICAClient/keystore/cacerts/

# cd /opt/Citrix/ICAClient/keystore/cacerts/

# awk 'BEGIN {c=0;} /BEGIN CERT/{c++} { print > "cert." c ".pem"}' < tls-ca-bundle.pem

Edit /usr/share/applications/wfica.desktop (as root)

Change:

Exec=/opt/Citrix/ICAClient/wfica -icaroot /opt/Citrix/ICAClient %f

To:

Exec=env LD_PRELOAD="/lib64/libcrypto.so.1.0.2o" /opt/Citrix/ICAClient/wfica -icaroot /opt/Citrix/ICAClient %f

source - https://ask.fedoraproject.org/t/howto-citrix-receiver-on-fedora-30/1274/31