Skip to main content

Thanks Ubuntu

I have first used Ubuntu in 2006 after having been burned by RedHat in 1999. It was a surprise that it worked, was much faster than my current OS and allowed me to painlessly install / use: GIMP, LaTeX, Emacs and many electronics CAD tools. Later Ubuntu allowed me to learn a lot about Linux through the ubuntuforums, ubuntu irc channels, help / wiki, developer weeks, code review, etc. I have now got an open-source job because I have these skills.

Many of the above was either directly or indirectly sponsored by Canonical. From the first CD, to fixing bugs, to code review from exceptional Canonical hackers and of course free training sessions. All interaction I had with Canonical employees was very professional and timely. Heck, I've asked for URL-shortening service for launchpad and we have now as in http://pad.lv/1.

The upstream projects I'm involved in will probably never be part of any revenue questions. And some of them explicitly do not accept donations.

I can defiantly say that Canonical has spent more money on me personally, then the revenue I have brought them. Heck, partially I have a full-time job now because of them. Speaking of which - the company I work for has a good relationship with Canonical. Some of our developers were sub-contracted for initial Ubuntu release and even today we do ad-hoc development for them.

Nothing is free (as in beer). Somebody throughout the years has been sponsoring this: parents, universities, companies, individuals, etc. Who is paying bills for all the bandwidth, disk space, buildbots, that you have ever used? Surely it wasn't yourself all the time.

Debian is a phenomenon. And has been for the past 17 years. Two of directors in my company are Debian Developers, Canonical technical board are all past/present Debian Developers. All of us do share a certain set of common values. Our priorities do shift. I want a roof above my head, food on a table, bandwidth and an OS to run on it. I want to listen to my favourite online radio station in banshee, running gnome, on Ubuntu with back ends running Linux on Amazon cloud. If you yank any of these pieces out, the domino effect kicks in. I fail to see now affiliation fee split between banshee/ubuntu/gnome/amazon can affect any of the four projects in anyway since all four are directly or indirectly inter-dependant on each other.

The moral is, it doesn't matter which part of the community you kiss, you will still get slapped for it.

This "flame war" was actually very boring... I can't wait for the Natty UI freeze to get all the juicy comments, e.g. like in the past about Maverick wallpaper and the buttons on the left and the like ;-)

Comments

  1. Well said. People, me included, criticise Canonical because it's funded like a private enterprise but doesn't yet make money (I guess), which sounds unsustainable. Personally, I'd be keen to see Canonical a sustainable private enterprise. Debian has a different model. Debian is sustainable partly because it has a unique point of differentiation from all other major distributions, which Canonical only enhances.

    ReplyDelete

Post a Comment

Popular posts from this blog

How to disable TLS 1.0 and TLS 1.1 on Ubuntu

Example of website that only supports TLS v1.0, which is rejected by the client Overivew TLS v1.3 is the latest standard for secure communication over the internet. It is widely supported by desktops, servers and mobile phones. Recently Ubuntu 18.04 LTS received OpenSSL 1.1.1 update bringing the ability to potentially establish TLS v1.3 connections on the latest Ubuntu LTS release. Qualys SSL Labs Pulse report shows more than 15% adoption of TLS v1.3. It really is time to migrate from TLS v1.0 and TLS v1.1. As announced on the 15th of October 2018 Apple , Google , and Microsoft will disable TLS v1.0 and TLS v1.1 support by default and thus require TLS v1.2 to be supported by all clients and servers. Similarly, Ubuntu 20.04 LTS will also require TLS v1.2 as the minimum TLS version as well. To prepare for the move to TLS v1.2, it is a good idea to disable TLS v1.0 and TLS v1.1 on your local systems and start observing and reporting any websites, systems and applications that

Ubuntu Livepatch service now supports over 60 different kernels

Linux kernel getting a livepatch whilst running a marathon. Generated with AI. Livepatch service eliminates the need for unplanned maintenance windows for high and critical severity kernel vulnerabilities by patching the Linux kernel while the system runs. Originally the service launched in 2016 with just a single kernel flavour supported. Over the years, additional kernels were added: new LTS releases, ESM kernels, Public Cloud kernels, and most recently HWE kernels too. Recently livepatch support was expanded for FIPS compliant kernels, Public cloud FIPS compliant kernels, and as well IBM Z (mainframe) kernels. Bringing the total of kernel flavours support to over 60 distinct kernel flavours supported in parallel. The table of supported kernels in the documentation lists the supported kernel flavours ABIs, the duration of individual build's support window, supported architectures, and the Ubuntu release. This work was only possible thanks to the collaboration with the Ubuntu C

Ubuntu 23.10 significantly reduces the installed kernel footprint

Photo by Pixabay Ubuntu systems typically have up to 3 kernels installed, before they are auto-removed by apt on classic installs. Historically the installation was optimized for metered download size only. However, kernel size growth and usage no longer warrant such optimizations. During the 23.10 Mantic Minatour cycle, I led a coordinated effort across multiple teams to implement lots of optimizations that together achieved unprecedented install footprint improvements. Given a typical install of 3 generic kernel ABIs in the default configuration on a regular-sized VM (2 CPU cores 8GB of RAM) the following metrics are achieved in Ubuntu 23.10 versus Ubuntu 22.04 LTS: 2x less disk space used (1,417MB vs 2,940MB, including initrd) 3x less peak RAM usage for the initrd boot (68MB vs 204MB) 0.5x increase in download size (949MB vs 600MB) 2.5x faster initrd generation (4.5s vs 11.3s) approximately the same total time (103s vs 98s, hardware dependent) For minimal cloud images that do not in