Language Selection

English French German Italian Portuguese Spanish

Servers: "Docker Not Doomed?" and Some IBM/Red Hat Leftovers

Filed under
Red Hat
Server
  • Docker Not Doomed?

    Modern application development essentially consists of composing an application from a variety of services. These services aren't just infrastructure components that live on a server any more. They're delivered via an API and could be almost anything underneath as the abstractions start to pile up.

    COBOL code at the other end of a message bus with a lambda-function frontend? Okay. Ephemeral container running a Spring Boot service that connects to an RDBMS on a physical Unix server on the other side of the country? Sure, why not? Modern applications don't really care, because it's all about getting the job done. The name of the game is loosely-coupled modular components.

    This is why Docker has joined forces with Microsoft, Bitnami, HashiCorp, and a few others to create the Cloud Native Application Bundle (CNAB) specification. Docker uses this spec as part of its Docker App tool, which behaves a lot like docker-compose to collect a variety of services together into a single application bundle that can be shared around. It's a lot like a container collection, and brings the same easy portability of containers to composed applications.

    "[Docker App] allows you to describe not just containers, but other services around which the app is dependent," says Johnston. "And it allows you to do things that enterprises care about, such as signing the bundle, verifying that signature, and automatically promoting it based on that signature and things like that."

  • Red Hat OpenShift Service Mesh is now available: What you should know

    As Kubernetes and Linux-based infrastructure take hold in digitally transforming organizations, modern applications frequently run in a microservices architecture and therefore can have complex route requests from one service to another. With Red Hat OpenShift Service Mesh, we’ve gone beyond routing the requests between services and included tracing and visualization components that make deploying a service mesh more robust. The service mesh layer helps us simplify the connection, observability and ongoing management of every application deployed on Red Hat OpenShift, the industry’s most comprehensive enterprise Kubernetes platform.

    Red Hat OpenShift Service Mesh is available through the OpenShift Service Mesh Operator, and we encourage teams to try this out on Red Hat OpenShift 4 here.

  • Catching up with Red Hat at Sibos 2019

    Red Hat is excited to once again be attending Sibos, an annual financial services industry conference exhibition and networking event that is hosted by SWIFT. This year, the event is being held in London, England from September 23rd through 26th. Red Hat will be attending to sponsor a number of activities and discuss how and why enterprise open source technologies offer innovative capabilities that can help firms thrive in their digital journeys.

More in Tux Machines

EasyNAS 1.0 Beta 3 is out

This version is a bug fix version. Shutdown & Restart are working properly, network setting is working fine, Chinese language is now downloadable, Firmware updates is now faster, Addons installation works fine. You won’t need to download the ISO of the new version, just use the Update feature in the menu and you’ll get the new full new version including Beta-4 and the final release. You’ll see many updates for all components , update it when it’s available. Read more

Linux 5.6-rc3

Fairly normal rc3 as far as I can tell. We've seen bigger, but we've
seen smaller ones too. Maybe this is slightly on the low side of
average at this time, which would make sense since this was a smaller
merge window. Anyway, too much noise in the signal to be sure either
way.

The overall stats look fairly regular too: about 55% drivers (staging,
sound, gpu, networking,  and usb look noticeable, with some noise
elsewhere). The bulk of the staging diff is actually the vsoc removal,
so that's nice.

Outside of drivers, we have the usual suspects: arch fixes (powerpc,
s390, x86, but also a late csky update that I couldn't find it in
myself to worry about). Filesystems (ext4 and btrfs) and networking.
And misc sprinkles of small fixes elsewhere.

See the appended shortlog for details,

             Linus
Read more Also: Linux 5.6-rc3 Released As A "Fairly Normal" Kernel

Programming: Thoughts From Jussi Pakkanen, Releases From Debian Developers, GSoC Projects and Python Leftovers

  • Jussi Pakkanen: Open source does not have a reward mechanism for tedious

    Many software developers are creators and builders. They are drawn to problems of the first type. The fact that they are difficult is not a downside, it is a challenge to be overcome. It can even be a badge of merit which you can wave around your fellow developers. These projects include things like writing your own operating system or 3D game engine, writing device drivers that saturate the fastest of transfer links, lock free atomic parallelism, distributed file systems that store exabytes of data as well as embedded firmware that has less than 1 kilobyte of RAM. Working on these kinds of problems is rewarding on its own, even if the actual product never finishes or fails horribly when eventually launched. They are, in a single word, sexy. Most problems are not like that, but are instead the programming equivalent of ditch digging. They consist of a lot of hard work, which is not very exciting on its own but it still needs to be done. It is difficult to get volunteers to work on these kinds of problems and this is where the problem gets amplified in open source. Corporations have a very strong way to motivate people to work on tedious problems and it is called a paycheck. Volunteer driven open source development does not have a way to incentivise people in the same way. This is a shame, because the chances of success for any given software project (and startup) is directly proportional to the amount of tedious work people working on it are willing to do.

  • ledger2beancount 2.0 released

    I released version 2.0 of ledger2beancount, a ledger to beancount converter.

  • digest 0.6.25: Spookyhash bugfix

    digest creates hash digests of arbitrary R objects (using the md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, and spookyhash algorithms) permitting easy comparison of R language objects. It is a fairly widely-used package (currently listed at 889k monthly downloads with 255 direct reverse dependencies and 7340 indirect reverse dependencies) as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation. This release is a one issue fix. Aaron Lun noticed some issues when spookyhash is used in streaming mode. Kendon Bell, who also contributed spookyhash quickly found the issue which is a simple oversight. This was worth addressing in new release, so I pushed 0.6.25.

  • Google announces 200 open-source mentors for the 2020 GSoC event

    With this year's Google Summer of Code event right around the corner, the organizers considered this to be the perfect time to announce the mentoring organizations for the participants. In this year's edition of GSoC, there will be 200 mentoring organizations, including 30 new teams. Read on to find out more details of this open-source event.

  • Python 101 2nd Edition Sample Chapters

    I have put together some sample chapters for the 2nd edition of Python 101 which is coming out later this year. You can download the PDF version of these sample chapters here. Note that these chapters may have minor typos in them. Feel free to let me know if you find any bugs or errors.

  • Python 3.7.6 : The SELinux python package.

    The tutorial for today is about the SELinux python package.

  • Release 0.7.0 of GooCalendar
  • Python in Production

    I’m missing a key part from the public Python discourse and I would like to help to change that. The other day I was listening to a podcast about running Python services in production. While I disagreed with some of the choices they made, it acutely reminded me about what I’ve been missing in the past years from the public Python discourse.

  • Python Packaging Metadata

    Since this topic keeps coming up, I’d like to briefly share my thoughts on Python package metadata because it’s – as always – more complex than it seems. When I say metadata I mean mostly the version so I will talk about it interchangeably. But the description, the license, or the project URL are also part of the game.

  • Better Python tracebacks with Rich

    One of my goals in writing Rich was to render really nice Python tracebacks. And now that feature has landed. I've never found Python tracebacks to be a great debugging aid beyond telling me what the exception was, and where it occurred. In a recent update to Rich, I've tried to refresh the humble traceback to give enough context to diagnose errors before switching back to the editor.

DPL Sam Hartman proves blackmail is alive and well in Debian

Debian has gone as far as humiliating and shaming people on a number of occasions to force them to bend over and submit to the monoculture. That may work with one or two victims at a time, as revealed in the Debian Christmas lynchings but the number of people expressing concerns about Israel appears to be too large for plain vanilla blackmailing. Read more