Years ago IBM coined the term First Failure Data Capture (FFDC). Capture enough data about a failure, just as it occurs the first time, so that reproducing the failure is all but unnecessary. An observability framework is a set of tools that enable system administrators to monitor and troubleshoot systems running in production, without interfering with efficient operation. In other words, it captures enough data about any failure that occurs so that a failure can be root-caused and possibly even fixed without the need to reproduce the failure in vitro.

Of course, FFDC is an aspirational goal. There will always be a practical limit to how much data can be collected, managed, and analyzed without impacting normal operation. The key is to identify important exceptional events and place hooks in those areas to record those events as they happen. These exceptional events are hopefully rare enough that the captured data is manageable. And the hooks themselves must introduce little or no overhead to a running system.

The trace point facility

The trace point facility, also known as ftrace, has existed in the Linux kernel for over a decade. Each static trace point is an individually-enabled call out that records a set of data as a structured record into a circular buffer. An area expert determines where each trace point is placed, what data is stored in the structured record, and how the stored record should be displayed (i.e., a print format specifier string). The format of the structured record acts as a kernel API. It is much simpler to parse than string output by printk. User space tools can filter trace data based on values contained in the fields (e.g., show me just trace events where "status != 0").

Each trace point is always available to use, as it is built into the code. When triggered, a trace point can do more than capture the values of a few variables. It also records a timestamp and whether interrupts are enabled, and which CPU, which PID, and which executable is running. It is also able to enable or disable other trace points, or provide a stack trace. Dtrace and eBPF scripts can attach to a trace point, and hist triggers are also possible.

Trace point buffers are allocated per CPU to eliminate memory contention and lock waiting when a trace event is triggered. There is a default set of buffers ready from system boot onward. However, trace point events can be directed into separate buffers. This permits several different tracing operations to occur concurrently without interfering with each other. These buffers can be recorded into files, transmitted over the network, or read from a pipe. If a system crash should occur, captured trace records still reside in these buffers and can be examined using crash dump analysis tools.

We didn’t intend to cut this release but changes in the way the latest OSX works meant that code highlighting didn’t work correctly. We also managed to apply a fix to an annoying bug relating to where Mu set the current working directory for scripts run in Python3 mode.

OSX Catalina has posed a number of problems, from the incorrect rendering mentioned above, to the way the application should be installed and problems with permissions when flashing a BBC micro:bit.

The simple answer to the installation story is, once you’ve installed Mu in your Applications folder, you should first open it with CTRL-click (not a double click) and select the “Open” button in the resulting pop-up. Subsequent runs of Mu can be started in the usual “double click” way. If you don’t do the “CTRL-click” trick you’ll see a pop-up complaining about Mu not being checked for malicious software.

I’m a self-taught programmer, a high school dropout, a core CPython developer, and a former PSF Board Director from Amsterdam, The Netherlands. I’ve been playing with computers for a long time, starting when my parents got a Commodore 64 with a couple books on BASIC, when I was 6 or 7. I learned a lot by just playing around on it. Then in 1994 I discovered the internet, while I was still in high school. This was before the days of the World Wide Web or (most) graphics, but I was sucked in by a programmable MUD, a text-based “adventure” environment, called LambdaMOO. LambdaMOO lets you create your own part of the world by making rooms and objects, and programming their behaviour, in a programming language that was similar to Python (albeit unrelated to it). One thing led to another and I dropped out of high school and got a job at a Dutch ISP (XS4ALL), doing tech support for customers. A year later I moved to the Sysadmin department, where I worked for ten years. I gradually moved from system administration to programming, even before I learned about Python.

Besides working with computers I also like playing computer games of all kinds, and non-computer games like board games or card games. I do kickboxing, and I have a bunch of lovely cats, about whom I sometimes tweet. I’m pretty active on IRC as well, and I’m a channel owner of #python on Freenode. I also keep ending up in administration-adjacent situations, like the PSF Board of Directors and the Python Steering Council, not so much because I like it but because I don’t mind doing it, I’m apparently not bad at it, and it’s important stuff that needs to be done well.

Python is the most reliable and renowned content management system for websites of any kind to create dynamically attractive web resources for their uses.

Python has got everything that developers can ask for to provide reliable user experience to end consumers and develop the business online.

For any website, maintaining the quality of the images becomes challenging because the high-quality image would result in the slow loading speed of the landing pages, which might result in poor user experience.

There are many tools available online that can compress the images and makes them uploadable on the website. However, the resulted images would often lose all the visual appeal after they are compressed through an online tool.

Unless you have been hiding under a rock, you have probably used Google Translate on many occasions in your life. Whenever you try to translate a word or a sentence from a certain language to another, it is the Google Translate API which brings you the desired results in the background. Though you can translate anything by simply going to the Google Translate web page, you can also integrate Google Translate API into your web applications or desktop programs. The best thing about the API is that it is extremely easy to set up and use.

You can actually do a lot of things with the help of the Google Translate API ranging from detecting languages to simple text translation, setting source and destination languages, and translating entire lists of text phrases. In this article, you will see how to work with the Google Translate API in the Python programming language.

This week I’m joined by Kelly Paredes and Sean Tibor, the hosts of the Teaching Python podcast. Join us as we discuss the benefits of learning Python outside of the code itself, and what it’s like to learn Python when you’re not planning to become a professional developer. So, without further ado, let’s meet Kelly and Sean!

My quest is to build beautiful things that help change the world, and I’ve been fortunate to spend the last 15 years in Silicon Valley, working with some of the major players shaping all sorts of technology. Today, I’m super excited to join SiFive - the company I believe is best positioned to transform the silicon industry, to lead the Platform Engineering team. With experience building and leading large-scale production systems that power our industry, I’m looking forward to making the dream of customized chips a reality with SiFive’s amazing team of engineers.

The end of Moore’s Law is a profound time, leading to new accelerators, new demand for custom ASICs, and new opportunities - and I believe that it is time for the semiconductor industry to change its approach to innovation. This industry has been defined by proprietary technologies that are difficult to use, don’t interoperate well, and have poor user experience. I believe that open tooling, world class engineering, and a focus on end-to-end user experience can transform the industry. Similarly, the RISC-V architecture pro-vides unique opportunities for SoC customization at every level. This is only possible with SiFive’s ambi-tious design methodology, which is unmatched in the industry.

My background includes experience creating and leading a number of large-scale technologies, including compiler technologies like the LLVM Compiler Infrastructure project, the Clang C and C++ compiler, the MLIR machine learning infrastructure, and others. I also spearheaded the creation of Swift - a program-ming language that powers Apple’s ecosystem - and led a team at Tesla that applies a wide range of tech in the autonomous driving space. Most recently, I built and managed an array of AI-related compiler, runtime, and programing language teams for Google Brain and TensorFlow.

This move for Chris comes after serving at Apple more than a decade where he led their LLVM-based toolchain efforts as well as developing the Swift programming language, a brief stint at Tesla focusing on their Autopilot software, and then for the past two and a half years has been at Google. At Google is where he was working on TensorFlow and the Machine Learning IR and other compiler-related efforts.