Language Selection

English French German Italian Portuguese Spanish

SUSE on Servers

Filed under
SUSE
  • The University of Maine: High-Performance Computing, Climate Change Research, and Ocean Modeling created a Whale of an appetite when it comes to data. SUSE Enterprise Storage satisfied that appetite!

    With research projects like climate change research and ocean modeling, the university’s high-performance computing center is generating data like a Whale eating Krill.  And that’s a whole lot considering a Blue Whale will consume some 40 million Krill, or about 8000 pounds daily.  The University of Maine is one of only 11 Land, Sea and Space grant institutions in the country. And establishing a stronger and more flexible HPC and storage infrastructure is integral to their success.  It also supports the people of Maine and its businesses across a wide variety of activities.

    Their challenge was with all the current and new larger research projects it increased the demands on data storage and the amount of data collected and consumed. For example, one project at the University of Maine generates high-resolution ocean models to map climate change and requires half a petabyte of data. Another project, employing deep learning to help detect tumors, requires a single directory with over two million files. With these projects and more, the university’s storage architecture was on the brink of collapse under the strain of these diverse and demanding data workloads. The existing system was difficult to scale up and tight budgets would not support a rip-and-replace of the entire system.

  • The Holy Grail of PaaS on Kubernetes

    Kubernetes will solve all of our problems right? It’s the container platform that will allow our development teams to deploy their microservice applications in all their cloud native glory. We’ll all be able to deploy our web apps without needing to worry about the servers that are running them or interact with the system administrators that look after those servers. Self-service for Developers!

More in Tux Machines

Programming/Development Leftovers

  • ‘I code in my dreams too’, say developers in Jetbrains State of Developer Ecosystem 2019 Survey
    Last week, Jetbrains published its annual survey results known as The State of Developer Ecosystem 2019. More than 19,000 people participated in this developer ecosystem survey. But responses from only 7000 developers from 17 countries were included in the report. The survey had over 150 questions and key results from the survey are published, complete results along with the raw data will be shared later. Jetbrains prepared an infographics based on the survey answers they received. Let us take a look at their key takeaways:
  • Python and "dead" batteries
    Python is, famously, a "batteries included" language; it comes with a rich standard library right out of the box, which makes for a highly useful starting point for everyone. But that does have some downsides as well. The standard library modules are largely maintained by the CPython core developers, which adds to their duties; the modules themselves are subject to the CPython release schedule, which may be suboptimal. For those reasons and others, there have been thoughts about retiring some of the older modules; it is a topic that has come up several times over the last year or so. It probably had been discussed even earlier, but a session at the 2018 Python Language Summit (PLS) is the starting point this time around. At that time, Christian Heimes listed a few modules that he thought should be considered for removal; he said he was working on a PEP to that end. PEP 594 ("Removing dead batteries from the standard library") surfaced in May with a much longer list of potentially dead batteries. There was also a session at this year's PLS, where Amber Brown advocated moving toward a much smaller standard library, arguing that including modules in the standard library stifles their growth. Some at PLS seemed to be receptive to Brown's ideas, at least to some extent, though Guido van Rossum was apparently not pleased with her presentation and "stormed from the room".
  • When and How to Win With New Programming Languages
  • Understanding Data Ops and it's impact on Application Quality

Latest Security FUD

Linux Foundation, Kernel, and Linux Plumbers Conference

  • Tech Giants Join Linux Foundation's Connected-Cities Efforts [Ed: Just surveillance capitalism inside Zemlin's PAC. Reminder: the spokesperson of the "Linux" Foundation is the former spokesperson of James Clapper.]
  • Generalized events notification and security policies
    Interfaces for the reporting of events to user space from the kernel have been a recurring topic on the kernel mailing lists for almost as long as the kernel has existed; LWN covered one 15 years ago, for example. Numerous special-purpose event-reporting APIs exist, but there are none that are designed to be a single place to obtain any type of event. David Howells is the latest to attempt to change that situation with a new notification interface that, naturally, uses a ring buffer to transfer events to user space without the need to make system calls. The API itself (which hasn't changed greatly since it was posted in 2018) is not hugely controversial, but the associated security model has inspired a few heated discussions.
  • Detecting and handling split locks
    The Intel architecture allows misaligned memory access in situations where other architectures (such as ARM or RISC-V) do not. One such situation is atomic operations on memory that is split across two cache lines. This feature is largely unknown, but its impact is even less so. It turns out that the performance and security impact can be significant, breaking realtime applications or allowing a rogue application to slow the system as a whole. Recently, Fenghua Yu has been working on detecting and fixing these issues in the split-lock patch set, which is currently on its eighth revision. [...] With a split lock, the value needs to be kept coherent between different CPUs, which means assuring that the two cache lines change together. As this is an uncommon operation, the hardware design needs to take a special path; as a result, split locks may have important consequences as described in the cover letter of Yu's patch set. Intel's choice was to lock the whole memory bus to solve the coherency problem; the processor locks the bus for the duration of the operation, meaning that no other CPUs or devices can access it. The split lock blocks not only the CPU performing the access, but also all others in the system. Configuring the bus-locking protocol itself also adds significant overhead to the system as a whole. On the other hand, if the atomic operation operand fits into a single cache line, the processor will use a less expensive cache lock. This all means that developers may increase performance and avoid split locks by actions like simply correctly aligning their variables.
  • Real-Time Microconference Accepted into 2019 Linux Plumbers Conference
    We are pleased to announce that the Real-Time Microconference has been accepted into the 2019 Linux Plumbers Conference! The PREEMPT_RT patch set (aka “The Real-Time Patch”) was created in 2004 in the effort to make Linux into a hard real-time designed operating system. Over the years much of the RT patch has made it into mainline Linux, which includes: mutexes, lockdep, high-resolution timers, Ftrace, RCU_PREEMPT, priority inheritance, threaded interrupts and much more. There’s just a little left to get RT fully into mainline, and the light at the end of the tunnel is finally in view. It is expected that the RT patch will be in mainline within a year, which changes the topics of discussion. Once it is in Linus’s tree, a whole new set of issues must be handled. The focus on this year’s Plumbers events will include:

Renaming openSUSE

At the 2019 openSUSE Conference, the openSUSE board discussed governance options at length. There will evidently be an official statement on its conclusions in the near future, but that has not been posted as of this writing. It would appear, though, that the board chose a foundation structure over the other options. A German registered association (e. V.) would have been easier to set up than a foundation, but an association has weaker restrictions so it could potentially shift its focus away from the openSUSE mission. Joining another umbrella group seemingly lacked appeal from the beginning, as did the option of doing nothing and leaving things as they are now. The stated purpose of the foundation is to make it easier for openSUSE to accept donations and manage its own finances — things that are hard for the project to do now. The foundation structure, in particular, allows the project to enshrine its core objectives (such as support for free software) into the DNA of the organization, making it hard to divert the foundation toward some other goal. A foundation also allows openSUSE to retain its current governing board and membership structure. In the absence of an official statement from the board, details on the decision and the reasoning behind it can be had by watching this YouTube video of a question-and-answer session with the board at the openSUSE Conference. One motivation for the change that wasn't highlighted in the board session, but which was an undercurrent in the discussions leading up to it, is a desire for more independence from SUSE in general driven by concerns about what the company might do in the future. Such worries are not entirely irrational, even though by all accounts SUSE management is fully supportive of openSUSE now. A company's attitude can change quickly even in the absence of external events like a change of ownership. If SUSE were to be sold yet again, the new owners could take a rather dimmer view of the openSUSE project. Read more