Language Selection

English French German Italian Portuguese Spanish

Servers: Concurrency, Purism, InSpec, Kubernetes, Docker/Containers

Filed under
Server
  • Thinking Concurrently: How Modern Network Applications Handle Multiple Connections

    The idea behind a process is fairly simple. A running program consists of not only executing code, but also data and some context. Because the code, data and context all exist in memory, the operating system can switch from one process to another very quickly. This combination of code + data + context is known as a "process", and it's the basis for how Linux systems work.

    When you start your Linux box, it has a single process. That process then "forks" itself, such that two identical processes are running. The second ("child") process reads new code, data and context ("exec"), and thus starts running a new process. This continues throughout the time that a system is running. When you execute a new program on the command line with & at the end of the line, you're forking the shell process and then exec'ing your desired program in its place.

  • New Purist Services – Standard Web Services Done Ethically

    When you sign up for a communication service, you are typically volunteering to store your personal, unencrypted data on someone else’s remote server farm. You have no way of ensuring that your data is safe or how it is being used by the owner of the server. However, online services are incredibly convenient especially when you have multiple devices.

  • Automated compliance testing with InSpec

    Don't equate compliance through certification with security, because compliance and security are not the same. We look at automated compliance testing with InSpec for the secure operation of enterprise IT.

  • How the Kubernetes Certification Ensures Interoperability

    Dan Kohn, executive director of the Cloud Native Computing Foundation, has called the launch of the new Kubernetes service provider certification program the most significant announcement yet made by the Foundation around the open source container orchestration engine.

    On this new episode of The New Stack Makers from KubeCon + CloudNativeCon 2017, we’ll learn more from Kohn and William Denniss, a product manager at Google, about how the program can help ensure interoperability and why that’s so important.

  • Container Structure Tests: Unit Tests for Docker Images

    Usage of containers in software applications is on the rise, and with their increasing usage in production comes a need for robust testing and validation. Containers provide great testing environments, but actually validating the structure of the containers themselves can be tricky. The Docker toolchain provides us with easy ways to interact with the container images themselves, but no real way of verifying their contents. What if we want to ensure a set of commands runs successfully inside of our container, or check that certain files are in the correct place with the correct contents, before shipping?

  • Prometheus vs. Heapster vs. Kubernetes Metrics APIs

    In this blog post, I will try to explain the relation between Prometheus, Heapster, as well as the Kubernetes metrics APIs and conclude with the recommended way how to autoscale workloads on Kubernetes.

  • Google Introduces Open Source Framework For Testing Docker Images

    Google has announced a new framework designed to help developers conduct unit tests on Docker container images. 

    The Container Structure Test gives enterprises a way to verify the structure and contents of individual containers to ensure that everything is as it should be before shipping to production, the company said in the company’s Open Source blog Jan. 9. 

    Google has been using the framework to test containers internally for more than a year and has released it publicly because it offers an easier way to validate the structure of Docker containers than other approaches, the company said.

More in Tux Machines

Licensing With GPL: Greater Certainty

  • A Movement Builds as a Diverse Group of 14 Additional Leaders Seek Greater Predictability in Open Source Licensing
    Today’s announcement demonstrates the expanded breadth and depth of support for the GPL Cooperation Commitment. Companies adopting the commitment now span geographic regions, include eight Fortune 100 companies, and represent a wide range of industries from enterprise software and hardware to consumer electronics, chip manufacturing to cloud computing, and social networking to automotive. The companies making the commitment represent more than 39 percent of corporate contributions to the Linux kernel, including six of the top 10 corporate contributors.1
  • ARM: Arm joins industry leaders in commitment to fair enforcement of open source licenses
    Today, Red Hat announced that several leading technology companies, including Arm, are joining a diverse coalition of organizations that have come together to promote greater predictability in open source license enforcement. Alongside Amazon, Canonical, Linaro, Toyota, VMware and many others we have committed to ensure fair opportunity for our licensees to correct errors in compliance with their GPL and LGPL licensed software before taking action to terminate the licenses.
  • Debian "stretch" 9.5 Update Now Available, Red Hat Announces New Adopters of the GPL Cooperation Commitment, Linux Audio Conference 2018 Videos Now Available, Latte Dock v0.8 Released and More
    Red Hat announced that 14 additional companies have adopted the GPL Cooperation Commitment, which means that "more than 39 percent of corporate contributions to the Linux kernel, including six of the top 10 contributors" are now represented. According to the Red Hat press release, these commitments "reflect the belief that responsible compliance in open source licensing is important and that license enforcement in the open source ecosystem operates by different norms." Companies joining the growing movement include Amazon, Arm, Canonical, GitLab, Intel Corporation, Liferay, Linaro, MariaDB, NEC, Pivotal, Royal Philips, SAS, Toyota and VMware.

Opinion: GitHub vs GitLab

So, Microsoft bought GitHub, and many people are confused or worried. It's not a new phenomenon when any large company buys any smaller company, and people are right to be worried, although I argue that their timing is wrong. Like Microsoft, GitHub has made some useful contributions to free and open-source software, but let's not forget that GitHub's main product is proprietary software. And, it's not just some innocuous web service either; GitHub makes and sells a proprietary software package you can download and run on your own server called GitHub Enterprise (GHE). Let's remember how we got here. BitMover made a tool called BitKeeper, a proprietary version control system that allowed free-of-charge licenses to free software projects. In 2002, the Linux kernel switched to using BitKeeper for its version control, although some notable developers made the noble choice to refuse to use the proprietary program. Many others did not, and for a number of years, kernel development was hampered by BitKeeper's restrictive noncommercial licenses. In 2005, Andrew Tridgell, working at OSDL, developed a client that bypassed this restriction, and as a result, BitMover removed licenses to BitKeeper from all OSDL employees—including Linus Torvalds. Eventually, all non-commercial licenses were stopped, and new licenses included clauses preventing the development of alternative version control systems. As a result of this, two new projects were born: Mercurial and Git. Created in a few short weeks in 2005, Git quickly became the version control system for Linux development. Proprietary version control tools aren't common in free software development, but proprietary collaboration websites have been around for some time. One of the earliest collaboration websites still around today is Sourceforge. Sourceforge was created in the late 1990s by VA Software, and the code behind the project was released in 2000. Read more

Comparing Latencies and Power consumption with various CPU schedulers

The low-latency kernel offering with Ubuntu provides a kernel tuned for low-latency environments using low-latency kernel configuration options. The x86 kernels by default run with the Intel-Pstate CPU scheduler set to run with the powersave scaling governor biased towards power efficiency. While power efficiency is fine for most use-cases, it can introduce latencies due to the fact that the CPU can be running at a low frequency to save power and also switching from a deep C state when idle to a higher C state when servicing an event can also increase on latencies. Read more

csplit: A Better Way to Split File in Linux Based on its Content

Learn some practical examples of the GNU coreutils csplit command for splitting files in Linux. It’s more useful than the popular split command. Read more