Language Selection

English French German Italian Portuguese Spanish

Mozilla: Flexbox Inspector, WebRender and Another Person Quits

Filed under
Moz/FF
  • Designing the Flexbox Inspector

    The new Flexbox Inspector, created by Firefox DevTools, helps developers understand the sizing, positioning, and nesting of Flexbox elements. You can try it out now in Firefox DevEdition or join us for its official launch in Firefox 65 on January 29th.

    The UX challenges of this tool have been both frustrating and a lot of fun for our team. Built on the basic concepts of the CSS Grid Inspector, we sought to expand on the possibilities of what a design tool could be. I’m excited to share a behind-the-scenes look at the UX patterns and processes that drove our design forward.

  • WebRender newsletter #35

    Bonsoir! Another week, another newsletter. I stealthily published WebRender on crates.io this week. This doesn’t mean anything in terms of API stability and whatnot, but it makes it easier for people to use WebRender in their own rust projects. Many asked for it so there it is. Everyone is welcome to use it, find bugs, report them, submit fixes and improvements even!

    In other news we are initiating a notable workflow change: WebRender patches will land directly in Firefox’s mozilla-central repository and a bot will automatically mirror them on github. This change mostly affects the gfx team. What it means for us is that testing webrender changes becomes a lot easier as we don’t have to manually import every single work in progress commit to test it against Firefox’s CI anymore. Also Kats won’t have to spend a considerable amount of his time porting WebRender changes to mozilla-central anymore.

  • thank u, next

    I don’t believe that has any chance of changing; when I’ve tried to express my frustrations, I’ve only gotten disciplined. Mozilla is not interested in hearing what I have to say. And that’s fine, but when I take a step back and think about things, that means it’s time to go, for both my sake and Mozilla’s. So I’ve just put in my two weeks’ notice.

More in Tux Machines

Reducing sysadmin toil with Kubernetes controllers

Kubernetes is a platform for reducing toil cunningly disguised as a platform for running containers. The element that allows for both running containers and reducing toil is the Kubernetes concept of a Controller. [...] The canonical example of this in action is in how we manage Pods in Kubernetes. A Pod is effectively a running copy of an application that a specific worker node is asked to run. If that application crashes, the kubelet running on that node will start it again. However, if that node crashes, the Pod is not recovered, as the control loop (via the kubelet process) responsible for the resource no longer exists. To make applications more resilient, Kubernetes has the ReplicaSet controller. The ReplicaSet controller is bundled inside the Kubernetes controller-manager, which runs on the Kubernetes master node and contains the controllers for these more advanced resources. The ReplicaSet controller is responsible for ensuring that a set number of copies of your application is always running. To do this, the ReplicaSet controller requests that a given number of Pods is created. It then routinely checks that the correct number of Pods is still running and will request more Pods or destroy existing Pods to do so. By requesting a ReplicaSet from Kubernetes, you get a self-healing deployment of your application. You can further add lifecycle management to your workload by requesting a Deployment, which is a controller that manages ReplicaSets and provides rolling upgrades by managing multiple versions of your application's ReplicaSets. Read more

Android Leftovers

Server: IBM, LAMP and Kubernetes

  • A HATS For Many Occasions
    IBM gives customers plenty of options when it comes to its Rational Host Access Transformation software, including several modes of operation, different runtime options, and support for different operating systems in screen modernization engagements. With last week’s launch of HATS version 9.7, the development and deployment options got even wider. Regardless of which downstream options a HATS customer ultimately chooses, it all starts out basically the same on the front side of the sausage machine: Customers come to HATS because they have a 5250 (or 3270 or VT100) application that they want to transform, but they don’t want to go through the hassle, expense, and risk of modifying the IBM i, z/OS, or Unix application’s source code.
  • Six top skills that you should acquire in 2019
    There is a growing demand for the fullstack development skill set, which is the ability to develop tech both on the front-end/client side and back-end/server side. As you can’t learn all, select combinations like MEAN or LAMP stack.
  • Kubernetes and the Enterprise
    The reason we were having this conversation was around SUSE’s Cloud Application Platform (CAP). This is our Kubernetes focused Cloud Foundry distribution. And as part of the Kubernetes focus, we have been supporting and running SUSE CAP on Azure’s AKS for the last year or so. The conversation continued with observations that Kubernetes was clearly the future across IT. Yet to date, Cloud Foundry still has a good following with the large enterprise. And the thinking was that the Cloud Foundry approach really helped the large enteprise work with their applications, even if the applications were purely ‘container’ applications. Cloud Foundry makes the container-side of managing your ‘container’ application transparent. This approach ultimately lowers the tasks, breadth of tooling, and knowledge you have to surround Kubernetes with. It was with this thought, that a light-bulb went on.

today's howtos