Language Selection

English French German Italian Portuguese Spanish

Programming: Google's Fuchsia, Go (Golang) and Python

Filed under
Development
Google
  • Fuchsia Friday: Android, Linux apps, and Fuchsia’s close relationship w/ Chrome OS

    Following along with the development of Google’s Fuchsia OS, it has become clear that it will be capable of running both Linux and Android apps. Chrome OS can also do both of these things, and that’s no coincidence, as the Fuchsia team has opted to use some of Chrome OS’s developments for their own benefit.

  • Golang Gets Cheaper Context Switching

    As good news considering how much longer it takes to perform a full context switch on Intel CPUs due to various vulnerability mitigations, the Go programming language run-time now has the ability for performing cheaper context switches.

    Landing in GCC 10 Git with the Golang code is a less involved context switching implementation for Linux x86_64 systems with the libgo run-time library.

  • Build an XML sitemap of XML sitemaps

    Suppose that you have so many thousands of pages that you can't just create a single /sitemap.xml file that has all the URLs (aka ) listed. Then you need to make a /sitemaps.xml that points to the other sitemap files. And if you're in the thousands, you'll need to gzip these files.

    The blog post demonstrates how Song Search generates a sitemap file that points to 63 sitemap-{M}-{N}.xml.gz files which spans about 1,000,000 URLs. The context here is Python and the getting of the data is from Django. Python is pretty key here but if you have something other than Django, you can squint and mentally replace that with your own data mapper.

  • Generate a random IP address in Python

    I have a commenting system where people can type in a comment and optionally their name and email if they like.
    In production, where things are real, the IP address that can be collected are all interestingly different. But when testing this manually on my laptop, since the server is running http://localhost:8000, the request.META.get('REMOTE_ADDR') always becomes 127.0.0.1 . Boring! So I fake it.

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