Today we announce Git protocol version 2, a major update of Git’s wire protocol (how clones, fetches and pushes are communicated between clients and servers). This update removes one of the most inefficient parts of the Git protocol and fixes an extensibility bottleneck, unblocking the path to more wire protocol improvements in the future.
The protocol version 2 spec can be found here. The main improvements are:
The main motivation for the new protocol was to enable server side filtering of references (branches and tags). Prior to protocol v2, servers responded to all fetch commands with an initial reference advertisement, listing all references in the repository. This complete listing is sent even when a client only cares about updating a single branch, e.g.: `git fetch origin master`.
Measuring latency and being able to react to latency issues are getting equally complex as our systems got more complex. This article will help you how to navigate yourself at a latency problem and what you need to put in place to effectively do so.
Latency
So, what is latency? Latency is how long it takes to do something. How long does it take to have a response back? How long does it take to process a message in a queue?
We use latency as one of the core measures to tell whether a system is working as intended end-to-end. On the critical path (in the lifetime of a user request), latency is the core element that contributes to the overall user experience. It also allows us whether we are utilizing our resources as expected or our throughput is less than our trajectory.
Sometimes you want to monitor what new information is being written to a file (think of log files), or for whatever reasons, want to access the last few lines of a file. Well, there’s a command line utility that lets you do this in Linux, and it’s call tail.
In this tutorial, we will discuss the basics of the tail command using some easy to understand examples. But before we do that, it’s worth mentioning that all examples included in this article have been tested on Ubuntu 16.04 LTS.
Linux tail command
As already mentioned, the tail command outputs the last part of files supplied to it as input. Following is its syntax:
tail [OPTION]… [FILE]…
And here’s what the tool’s man page says about it:
Print the last 10 lines of each FILE to standard output. With more than one FILE, precede each with
a header giving the file name. With no FILE, or when FILE is -, read standard input.
Continuous integration (CI) and continuous delivery (CD) embody a culture, set of operating principles, and collection of practices that enable application development teams to deliver code changes more frequently and reliably. The implementation is also known as the CI/CD pipeline and is one of the best practices for devops teams to implement.
CI/CD defined
Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes. …
Teams implementing continuous integration often start with version control configuration and practice definitions. Even though checking in code is done frequently, features and fixes are implemented on both short and longer time frames. Development teams practicing continuous integration use different techniques to control what features and code is ready for production.
Not only do I write technical documentation, I write novels. And because I’m comfortable with tools like GIMP, I also create my own book covers (and do graphic design for a few clients). That artistic endeavor depends upon a lot of pieces falling into place, including fonts.
Although font rendering has come a long way over the past few years, it continues to be an issue in Linux. If you compare the look of the same fonts on Linux vs. macOS, the difference is stark. This is especially true when you’re staring at a screen all day. But even though the rendering of fonts has yet to find perfection in Linux, one thing that the open source platform does well is allow users to easily manage their fonts. From selecting, adding, scaling, and adjusting, you can work with fonts fairly easily in Linux.
Here, I’ll share some of the tips I’ve depended on over the years to help extend my “font-ability” in Linux. These tips will especially help those who undertake artistic endeavors on the open source platform. Because there are so many desktop interfaces available for Linux (each of which deal with fonts in a different way), when a desktop environment becomes central to the management of fonts, I’ll be focusing primarily on GNOME and KDE.
With that said, let’s get to work.
Adding new fonts
For the longest time, I have been a collector of fonts. Some might say I have a bit of an obsession. And since my early days of using Linux, I’ve always used the same process for adding fonts to my desktops. There are two ways to do this:
Make the fonts available on a per-user basis.
Make the fonts available system-wide.
Because my desktops never have other users (besides myself), I only ever work with fonts on a per-user basis. However, I will show you how to do both. First, let’s see how to add fonts on a per-user basis. The first thing you must do is find fonts. Both True Type Fonts (TTF) and Open Type Fonts (OTF) can be added. I add fonts manually. Do this is, I create a new hidden directory in ~/ called ~/.fonts. This can be done with the command:
mkdir ~/.fonts
With that folder created, I then move all of my TTF and OTF files into the directory. That’s it. Every font you add into that directory will now be available for use to your installed apps. But remember, those fonts will only be available to that one user.
If you want to make that collection of fonts available to all, here’s what you do:
Open up a terminal window.
Change into the directory housing all of your fonts.
Copy all of those fonts with the commands sudo cp *.ttf *.TTF /usr/share/fonts/truetype/ and sudo cp *.otf *.OTF /usr/share/fonts/opentype
The next time a user logs in, they’ll have access to all those glorious fonts.
GUI Font Managers
There are a few ways to manage your fonts in Linux, via GUI. How it’s done will depend on your desktop environment. Let’s examine KDE first. With the KDE that ships with Kubuntu 18.04, you’ll find a Font Management tool pre-installed. Open that tool and you can easily add, remove, enable, and disable fonts (as well as get information about all of the installed fonts. This tool also makes it easy for you to add and remove fonts for personal and system-wide use. Let’s say you want to add a particular font for personal usage. To do this, download your font and then open up the Font Management tool. In this tool (Figure 1), click on Personal Fonts and then click the + Add button.
Figure 1: Adding personal fonts in KDE.
Navigate to the location of your fonts, select them, and click Open. Your fonts will then be added to the Personal section and are immediately available for you to use (Figure 2).
Figure 2: Fonts added with the KDE Font Manager.
To do the same thing in GNOME requires the installation of an application. Open up either GNOME Software or Ubuntu Software (depending upon the distribution you’re using) and search for Font Manager. Select Font Manager and then click the Install button. Once the software is installed, launch it from the desktop menu. With the tool open, let’s install fonts on a per-user basis. Here’s how:
Select User from the left pane (Figure 3).
Click the + button at the top of the window.
Navigate to and select the downloaded fonts.
Click Open.
Figure 3: Adding fonts in GNOME.
Tweaking fonts
There are three concepts you must first understand:
Font Hinting: The use of mathematical instructions to adjust the display of a font outline so that it lines up with a rasterized grid.
Anti-aliasing: The technique used to add greater realism to a digital image by smoothing jagged edges on curved lines and diagonals.
Scaling factor:A scalable unit that allows you to multiple the point size of a font. So if you’re font is 12pt and you have an scaling factor of 1, the font size will be 12pt. If your scaling factor is 2, the font size will be 24pt.
Let’s say you’ve installed your fonts, but they don’t look quite as good as you’d like. How do you tweak the appearance of fonts? In both the KDE and GNOME desktops, you can make a few adjustments. One thing to consider with the tweaking of fonts is that taste is very much subjective. You might find yourself having to continually tweak until you get the fonts looking exactly how you like (dictated by your needs and particular taste). Let’s first look at KDE.
Open up the System Settings tool and clock on Fonts. In this section, you can not only change various fonts, you can also enable and configure both anti-aliasing and enable font scaling factor (Figure 4).
Figure 4: Configuring fonts in KDE.
To configure anti-aliasing, select Enabled from the drop-down and then click Configure. In the resulting window (Figure 5), you can configure an exclude range, sub-pixel rendering type, and hinting style.
Figure 5: Configuring anti-aliasing in KDE.
Once you’ve made your changes, click Apply. Restart any running applications and the new settings will take effect.
To do this in GNOME, you have to have either use Font Manager or GNOME Tweaks installed. For this, GNOME Tweaks is the better tool. If you open the GNOME Dash and cannot find Tweaks installed, open GNOME Software (or Ubuntu Software), and install GNOME Tweaks. Once installed, open it and click on the Fonts section. Here you can configure hinting, anti-aliasing, and scaling factor (Figure 6).
Figure 6: Tweaking fonts in GNOME.
Make your fonts beautiful
And that’s the gist of making your fonts look as beautiful as possible in Linux. You may not see a macOS-like rendering of fonts, but you can certainly improve the look. Finally, the fonts you choose will have a large impact on how things look. Make sure you’re installing clean, well-designed fonts; otherwise, you’re fighting a losing battle.
Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.
This week in open source and Linux news, Hyperledger’s Brian Behlendorf predicts blockchain consolidation, Sprint joins LFN and ORAN Alliance, AGL is furthering the connected car movement in new and comprehensive ways, and more!
1) Hyperledger’s Brian Behlendorf “predicts the industry will begin to consolidate among a core set of technology stacks.”
So, what is a blockchain? It’s a complicated question because the inventor of Bitcoin, the pseudonymous Satoshi Nakamoto, didn’t use the term in the original Bitcoin paper. For many, “the blockchain” is nothing more than a shorthand for “how Bitcoin works.” But more usefully, the blockchain is a distributed ledger, shared by untrusted participants, with strong guarantees about accuracy and consistency. What does that mean? Let’s unpack it term by term:
A ledger: If you go into antiquarian bookstores, you may have seen piles of books from the 19th century in which accountants entered transactions by hand. Those are ledgers. Ledgers are lists of transactions: items sold, and for how much; items purchased, and for how much. Those transactions are dated (timestamped) and ordered. Ledgers are strictly append-only: transactions can be added, but you can’t go back and edit or delete them. A blockchain can have ledger entries that are significantly more complex than credits and debits, but the concept is the same: a set of ordered entries to which new entries can be added, but old entries can be neither deleted or modified.
Cloud-native technologies and architectures are the means by which more traditional businesses — like insurance, financial services or even heavy machinery — can transition from simply consuming cloud resources into operating like the cloud providers themselves. This is shifting the way they run their businesses, making them more agile, distributed and ready to tackle via software, whatever their businesses demand. As with most new technologies, however, it’s important to look at Kubernetes with some perspective.
For large enterprises especially, Kubernetes and its growing ecosystem are just the latest developments in a continuum that spans decades. It might be the tool of choice for teams that want a great way to manage fleets of containers, but it still comprises only a fraction of enterprise workloads. And despite the massive migration to cloud platforms such as AWS and Google Cloud, enterprises will, for the foreseeable future, require a level of control and flexibility that managed cloud services and developer-centric technologies simply cannot provide.
Many organizations are making the move to cloud-native platforms as their strategy for digital transformation. cloud-native allows companies to deliver fast-responding, user-friendly applications with greater agility. However, the architecture of the data in support of cloud-native transformation is often ignored in the hope that it will take care of itself. With data becoming the information currency of every organization, how do you avoid the data mistakes commonly made during this cloud transformation journey? What data questions should you ask when building cloud-native applications? How can you gain valuable insight from your data?
The ensuing presentation includes six key considerations companies must have when they make this transition to cloud-native. …
While there are many legacy applications that are still SOA-based, the architectural mindset has changed and microservices have gained much popularity. Rather than architecting monolithic applications, developers can achieve many benefits by creating many independent services that work together in concert. A microservice architecture delivers greater agility in application development and simpler codebases; updates and scaling the services can be achieved in isolation and services can be written in different languages and connected to different data tiers and platforms of choice.
Just like a zoo with hundreds of different species and exhibits, the big data stack is created from more than 20 different projects developed by committers and contributors of the Apache Software Foundation. Each project has its own complex dependencies structure, which, in turn, build on one another very much like the Russian stacking doll (matryoshka). Further, all of these projects have their own release trains where different forks might include different features or use different versions of the same library. When combined, there are a lot of incompatibilities, and many of the components rely on each other to work properly, such as the case of a software stack. For example, Apache HBase and Apache Hive depend on Apache Hadoop’s HDFS. In this environment, is it even possible to consistently produce software that would work when deployed to a hundred computers in a data center?…
All of these moving parts effectively serve one purpose: to create the packages from known building blocks and transfer them a different environment (dev, QA, staging, and production) so that no matter where they are deployed, they will work the same way. The deployment mechanism needs to control the state of the target system. Relying on a state machine like Puppet or Chef has many benefits. You can forget about messy shell or Python scripts to copyfiles, create symlinks, and set permissions. Instead, you define “the state” that you want the target system to be, and the state machine will execute the recipe and guarantee that the end state will be as you specified. The state machine controls the environment instead of assuming one. These properties are great for operations at scale, DevOps, developers, testers, and users, as they know what to expect.
