Language Selection

English French German Italian Portuguese Spanish

Servers: Kubernetes, Red Hat, USENET and Solaris

Filed under
Server
  • HPE launches container platform, aims to be 100% open source Kubernetes

    Hewlett Packard Enterprise launched its HPE Container Platform, a Kubernetes container system designed to run both cloud and on-premises applications.

    On the surface, HPE Container Platform will face an uphill climb as all the top cloud providers have Kubernetes management tools and instances and IBM with Red Hat has a big foothold for hybrid cloud deployments and the container management that goes with it.

    HPE, which recently outlined a plan to make everything a service, is betting that the HPE Container Platform can differentiate itself based on two themes. First, HPE is pledging that its container platform will be 100% open source Kubernetes compared to other systems that have altered Kubernetes. In addition, HPE Container Platform will be able to run across multiple environments and provide one management layer.

  • Virtio-networking: first series finale and plans for 2020

    Let's take a short recap of the Virtio-networking series that we've been running the past few months. We've covered a lot of ground! Looking at this series from a high level, let's revisit some of the topics we covered:

    [...]

    For those who didn't crack and made it all the way here, we hope this series helped you clarify the dark magic of virtio and low-level networking both in the Linux kernel and in DPDK.

  • Inside the Book of Red Hat

    Shared stories are the cornerstone of community. And in open organizations like Red Hat—where community is paramount—shared stories are especially important to the collective identity that binds participants together.

    At Red Hat, we're quite fond of the stories that inform our shared history, purpose, and culture. We've just collected some of them in a new version of the Book of Red Hat, which is available now.

    Here are just three of the community-defining moments the book recounts.

  • The Early History of Usenet, Part III: File Format

    When we set out to design the over-the-wire file format, we were certain of one thing: we wouldn't get it perfectly right. That led to our first decision: the very first character of the transmitted file would be the letter "A" for the version. Why not a number on the first line, including perhaps a decimal point? If we ever considered that, I have no recollection of it.
    A more interesting question is why we didn't use email-style headers, a style later adopted for HTTP. The answer, I think, is that few, if any, of us had any experience with those protocols at that time. My own personal awareness of them started when I requested and received a copy of the Internet Protocol Transition Workbook a couple of years later — but I was only aware of it because of Usenet. (A few years earlier, I gained a fair amount of knowledge of the ARPANET from the user level, but I concentrated more on learning Multics.)

    Instead, we opted for the minimalist style epitomized by 7th Edition Unix. In fact, even if we had known of the Internet (in those days, ARPANET) style, we may have eschewed it anyway. Per a later discussion of implementation, the very first version of our code was a shell script. Dealing with entire lines as single units, and not trying to parse headers that allowed arbitrary case, optional white space, and continuation lines was certainly simpler!

    [...]

    Sending a date and an article title were obvious enough that these didn't even merit much discussion. The date and time line used the format generated by the ctime() or asctime() library routines. I do not recall if we normalized the date and time to UTC or just ignored the question; clearly, the former would have been the proper choice. (There is an interesting discrepancy here. A reproduction of the original announcement clearly shows a time zone. Neither the RFC nor the ctime() routine had one. I suspect that announcement was correct.) The most interesting question, though, was about what came to be called newsgroups.

    We decided, from the beginning, that we needed multiple categories of articles — newsgroups. For local use, there might be one for academic matters ("Doctoral orals start two weeks from tomorrow"), social activities ("Reminder: the spring picnic is Sunday!"), and more. But what about remote sites? The original design had one relayed newsgroup: NET. That is, there would be no distinction between different categories of non-local articles.

  • From humble Unix sysadmin to brutal separatist suppressor to president of Sri Lanka

    A former Unix sysadmin has been elected the new president of Sri Lanka, giving hope to all those IT workers who fear they are trapped in a role where the smallest of decisions can have catastrophic consequences if it goes wrong.

    Gotabaya Rajapaksa, younger brother of former president Mahindra, won the popular vote in an election held on Saturday (16 November). He is notable to The Register's readership for his stint working in America as a Solaris system integrator and later as a Unix sysadmin for a Los Angeles university.

HPE Launches Kubernetes-Based Container Platform

  • HPE Launches Kubernetes-Based Container Platform

    Hewlett Packard Enterprise (HPE) has launched an enterprise-grade Kubernetes-based container platform. Called HPE Container Platform, it is designed for both cloud-native applications and monolithic applications with persistent storage.

    According to the company, HPE Container Platform is built on innovations from HPE’s acquisitions of BlueData and MapR, together with 100 percent open source Kubernetes. The new platform addresses the requirements for large-scale enterprise Kubernetes deployments across a range of use cases, from machine learning and edge analytics to CI/CD pipelines and application modernization, the company said.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Screencasts/Audiocasts: Zorin OS 15.1 Run Through, Linux Action News and Open Source Security Podcast

XFS - 2019 Development Retrospective

We frequently hear two complaints lodged against XFS -- memory reclamation runs very slowly because XFS inode reclamation sometimes has to flush dirty inodes to disk; and deletions are slow because we charge all costs of freeing all the file's resources to the process deleting files. Dave Chinner and I have been collaborating this year and last on making those problems go away. Dave has been working on replacing the current inode memory reclaim code with a simpler LRU list and reorganizing the dirty inode flushing code so that inodes aren't handed to memory reclaim until the metadata log has finished flushing the inodes to disk. This should eliminate the complaints that slow IO gets in the way of reclaiming memory in other parts of the system. Meanwhile, I have been working on the deletion side of the equation by adding new states to the inode lifecycle. When a file is deleted, we can tag it as needing to have its resources freed, and move on. A background thread can free all those resources in bulk. Even better, on systems with a lot of IOPs available, these bulk frees can be done on a per-AG basis with multiple threads. Read more Also: Oracle Talks Up Recent Features For XFS + Some File-System Improvements On The Horizon

Review: OpenIndiana 2019.10 Hipster

For me, the conclusion after battling with OpenIndiana for a few weeks is quite simple: the operating system's aim is to "ensure the continued availability of an openly developed distribution based on OpenSolaris" and it clearly achieves that goal. However, it does very little beyond that modest aim, and the lack of documentation makes it difficult to use OpenIndiana for people unfamiliar with OpenSolaris and/or Solaris. My advice for Linux users like me is to take plenty of time to get familiar with the operating system. At times I found using OpenIndiana hugely frustrating but that was largely because things weren't working as I expected. I am fairly confident that I would have solved most of the issues I encountered if I had spent more time with OpenIndiana. Some issues may be show-stoppers, including OpenIndiana's struggle with connecting to wireless networks and the limited amount of applications that are available. Many of these issues can be solved though. One of the main struggles I faced was finding documentation. The best place to look for information appears to be Oracle's Solaris documentation. Unfortunately, OpenIndiana's Hipster Handbook is not much use. It is mostly populated with content placeholders and the section on web servers counts exactly two words: "Apache" and "nginx". Even new features, such as the "native and metadata encryption" for ZFS and an option to disable hyper-treading are not mentioned in the handbook. At times OpenIndiana felt like an operating system that belongs in a museum. The set-up is quite old-school, the theme looks very dated and everything felt sluggish; the system is slow to boot and launching applications always took just a little too long for my liking. OpenIndiana's stand-out features are also nothing new - they are what made OpenSolaris a powerful operating system a decade years ago. Yet, in the Linux world there aren't many distros - if any - that have something like the Time Slider. openSUSE comes close but, in my humble opinion, OpenIndiana's Time Slider is more advanced and easier to use than OpenSUSE's Snapper. I am hoping Linux will catch up when it comes to OpenIndiana's ZFS goodness. Ubuntu is working on integrating ZFS, and I for one hope that in time there will be a Time Slider in file managers such as GNOME Files and Dolphin. Read more

OpenWiFi Open-Source Linux-compatible WiFi Stack Runs on FPGA Hardware

WiFi is omnipresent on most connected hardware, and when it works it’s great, but when there are issues oftentimes they can not be solved because the firmware is a closed-source binary. Read more