Language Selection

English French German Italian Portuguese Spanish

IBM, Red Hat and Fedora Leftovers

Filed under
Red Hat
  • OpenShift 4: Image Builds

    One of the key differentiators of Red Hat OpenShift as a Kubernetes distribution is the ability to build container images using the platform via first class APIs. This means there is no separate infrastructure or manual build processes required to create images that will be run on the platform. Instead, the same infrastructure can be used to produce the images and run them. For developers, this means one less barrier to getting their code deployed.

    With OpenShift 4, we have significantly redesigned how this build infrastructure works. Before that sets off alarm bells, I should emphasize that for a consumer of the build APIs and resulting images, the experience is nearly identical. What has changed is what happens under the covers when a build is executed and source code is turned into a runnable image.

  • libinput's new thumb detection code

    The average user has approximately one thumb per hand. That thumb comes in handy for a number of touchpad interactions. For example, moving the cursor with the index finger and clicking a button with the thumb. On so-called Clickpads we don't have separate buttons though. The touchpad itself acts as a button and software decides whether it's a left, right, or middle click by counting fingers and/or finger locations. Hence the need for thumb detection, because you may have two fingers on the touchpad (usually right click) but if those are the index and thumb, then really, it's just a single finger click.

    libinput has had some thumb detection since the early days when we were still hand-carving bits with stone tools. But it was quite simplistic, as the old documentation illustrates: two zones on the touchpad, a touch started in the lower zone was always a thumb. Where a touch started in the upper thumb area, a timeout and movement thresholds would decide whether it was a thumb. Internally, the thumb states were, Schrödinger-esque, "NO", "YES", and "MAYBE". On top of that, we also had speed-based thumb detection - where a finger was moving fast enough, a new touch would always default to being a thumb. On the grounds that you have no business dropping fingers in the middle of a fast interaction. Such a simplistic approach worked well enough for a bunch of use-cases but failed gloriously in other cases.

  • 21 to 1: How Red Hat amplifies partner revenue

    At Red Hat Summit, we announced new research from IDC looking at the contributions of Red Hat Enterprise Linux (RHEL) to the global economy. The study, sponsored by Red Hat, found that the workloads running on Red Hat Enterprise Linux are expected to "touch" more than $10 trillion worth of global business revenues in 2019 - powering roughly 5% of the worldwide economy. While that statistic alone is eye popping, these numbers, according to the report, are only expected to grow in the coming years, fueled by more organizations embracing hybrid cloud infrastructures. As a result, there is immense opportunity for Red Hat partners and potential partners to capitalize on the growth and power of RHEL.

  • Executing .NET Core functions in a separate process [Ed: IBM/Red Hat is pushing Microsoft patent traps again (and yes, Microsoft still suing]
  • DevNation Live: 17-million downloads of Visual Studio Code Java extension [Ed: Also celebrating for Microsoft again (as if helping the proprietary MSVS 'ecosystem' is their goal now)]
  • The NeuroFedora Blog: NEURON in NeuroFedora needs testing

    We have been working on including the NEURON simulator in NeuroFedora for a while now. The build process that NEURON uses has certain peculiarities that make it a little harder to build.

    For those that are interested in the technical details, while the main NEURON core is built using the standard ./configure; make ; make install process that cleanly differentiates the "build" and "install" phases, the Python bits are built as a "post-install hook". That is to say, they are built after the other bits in the "install" step instead of the "build" step. This implies that the build is not quite straightforward and must be slightly tweaked to ensure that the Fedora packaging guidelines are met.

More in Tux Machines

KDE Frameworks 5.61, Applications 19.08 in FreeBSD

Recent releases were KDE Frameworks 5.61 and KDE Applications 19.08. These have both landed in the official FreeBSD ports tree, after Tobias did most of the work and I pushed the big red button. Your FreeBSD machine will need to be following current ports – not the quarterly release branches, since we don’t backport to those. All the modern bits have arrived, maintaining the KDE-FreeBSD team’s commitment to up-to-date software for the FreeBSD desktop. The one thing we’re currently lagging on is Qt 5.13. There’s a FreeBSD problem report tracking that update. Read more

Dev branch moving towards Qt 6

As you know, Qt 5.14 will be branched pretty soon. After that I would expect that most new development work would start to be aimed towards Qt 6. As it looks right now, 5.15 will be a smaller release where we polish what we have in 5.14, and prepare some things for Qt 6. To reflect that and help us all understand that the development focus is now towards Qt 6, I would like to propose that dev becomes the Qt 6 branch after we branched away 5.14 (and we merge wip/qt6 back into dev). We can then either create a 5.15 branch at the same time, or slightly later, once 5.14 has stabilised a bit more (e.g. after the beta or RC). Read more Also: Qt's Development Branch To Begin Forming Qt 6

Today in Techrights

How to Check Which Debian Version are you Running

Wondering which Debian version are you running? This tutorial teaches you several ways to check Debian version in the terminal. Read more