You are here

Planet Ubuntu

Subscribe to Feed Planet Ubuntu
Planet Ubuntu - http://planet.ubuntu.com/
Përditësimi: 1 javë 1 ditë më parë

Kubuntu General News: Kubuntu Disco Dingo (19.04) Beta Released

Mar, 02/04/2019 - 4:33md

The beta of Disco Dingo (to become 19.04) has now been released, and is available for download at http://cdimage.ubuntu.com/kubuntu/releases/19.04/beta/

This milestone features images for Kubuntu and other Ubuntu flavours.

Pre-releases of the Disco Dingo are not encouraged for:

* Anyone needing a stable system
* Anyone who is not comfortable running into occasional, even frequent breakage.

They are, however, recommended for:

* Ubuntu flavor developers
* Those who want to help in testing, reporting, and fixing bugs as we work towards getting this release ready.
* the Beta includes some software updates that are ready for broader testing. However, it is an early set of images, so you should expect some bugs.

You can:

Read more information about the Kubuntu 19.04 Beta: https://wiki.ubuntu.com/DiscoDingo/Beta/Kubuntu

Download the Kubuntu 19.04 Beta images

Read the full text of the main Ubuntu Cosmic Beta announcement:

https://lists.ubuntu.com/archives/ubuntu-release/2019-March/004743.html

The Ubuntu Cosmic Release notes will give more details of changes to the Ubuntu base: https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes

Simon Raffeiner: The state of the USB-C connector in 2019

Mar, 02/04/2019 - 2:13md

In episode 2x46 of the Bad Voltage podcast, Stuart Langridge predicts companies will finally embrace the USB-C connector in 2019. Which prompts both Jono Bacon and Jeremy Garcia to ask: "What doesn't ship with USB-C today"? Turns out a lot of devices still do...

The post The state of the USB-C connector in 2019 appeared first on LIEBERBIBER.

Jono Bacon: How to Track Community Growth in Forums

Hën, 01/04/2019 - 10:58md

When I work with clients, one of the key things they want to understand is how they track community growth and react to the data they are seeing. This can be a complex business: community platforms provide bazillions of metrics. Which ones should you track? Or, should you track them all?

Definitely don’t track everything. That is a fast-track to driving yourself bonkers.

Much to the chagrin of metrics nerds, tracking too many things can be a distraction. A better approach is to decide on a key set of dimensions and track those things effectively. Focus less on the number of graphs and more what you want to learn from the data.

Today I want to recommend what some of these metrics should be. For the purpose of this article, I am using Discourse as an example; they are a platform I commonly I use with clients.

The graphs you will see below are from a client of mine who are running a fairly specialist niche technical community that pre-launched late last year (who gave me permission to anonymously share the graphs). This are early stages for the community, but I think they are making great traction and these these graphs are illustrative of what you might want to measure and how you evaluate the data.

#1. Consolidated Page Views

The first thing you should track is general activity. How many people are coming to your forum, and what kind of traffic are you seeing?

Consolidated Page Views

In Discourse, Consolidated Page Views are helpful here. It shows the breakdown between logged in members (dark blue), anonymous non-logged-in users (light blue), and crawlers (red).

Most community members are window shoppers at first. They start browsing a forum (often to find answers to their questions or researching a product before they use it) before ever signing up. Your forum will likely crop up when they search for this information on Google.

As such, you want to track general traffic to the forum (to see how much utility the forum provides more generally), as well as track logged-in users to determine if your contributor base is regularly showing up.

If your general traffic is flatlining, you need to raise better awareness of your community: integrate it into your website, promote it on social media, mention it in content, etc.

#2. Signups

In the early stages of a community the most critical thing is to ensure that every member has a great experience. Don’t worry too much about growth: focus on delivering a great community experience. We will discuss this a little later.

It is though important to track sign-ups as they give us a good sense of people coming into the community:

Signups

As a general rule, you want to see this at least consistent, but preferably growing. Bear in mind that sign-ups do not exist in a vacuum: people need a reason to sign up, otherwise they will just browse anonymously.

As such, brainstorm how you incentivize people to join. How are you pulling them in? How are you engaging and rewarding them? Try new ways of incentivizing people and track your impact with the above graph: if you see spikes, you know you are doing something right.

#3. Posts

While we are on the subject of tracking activity, a useful metric to track how much people are posting. While least critical, it gives us a general sense of the growth (or lack thereof) of discussion:

Posts

Just like the stock market, this is a graph that can be spiky depending on a given week or month, so don’t take it too literally.

What you want to look for is a general community growth pattern in discussion. If you have lots of people registering signing-up and logging in (our previous two graphs) but your posts are flatlined, your forum is simply not interesting/engaging enough. If you have a growth in posts and flatlined member sign-ups, it means you have a very engaging forum that no-one knows about or where many people struggle to find a way to participate.

#4. DAU/MAU

One of the hardest but most critical metrics to track is member “stickiness”. That is, how many of your members are sticking around, participating, and actively engaging. We don’t just want lots of members, we want them having an awesome experience.

The most critical metric here is the Daily Active Users/Monthly Active Users graph:

DAU/MAU

The formula here is simple: the graph presents a percentage score calculated by the number of members that logged in in the last day divided by the number of members that logged in in the last month. It gives us a good sense of overall repeated engagement and as a general rule, you want to shoot for over 30% stickiness.

As you can see in the above example, we had a bump around initial pre-launch, and then the engagement has flattened and is growing gradually. This is a pretty common pattern.

Our goal is to get this consistently up above 30% (which requires a combination of a diverse range of discussions to pull people in, constant encouragement of member participation, incentivizing and rewarding great contributions, and always adding more and more value for members to justify their time and participation.)

A common tool to get this figure up is rewarding active contributors. Just remember the The Risks Of Over-Rewarding Communities.

#5. Daily Engaged Users

While DAU/MAU is useful, it also fights crime with the the Daily Engaged Users graph, which is the number of members who have liked or posted in the last day:

Daily Engaged Users

This gives us a useful community growth curve for general member engagement. For a small early-stage community like this, the above graph is where I want to see it: consistent growth.

This graph is useful for determining the general growth curve for overall engagement. If you see this graph flattening out, it typically means there is not enough value for members (or a nervousness to engage.)

#6. Trust Level Growth

Finally, Discourse has the concept of Trust Levels. This is a powerful way to score members based on their active participation. It provides a great way to see which members are most active and then be able to reach out and engage with them. For example, with many communities I work on, we will work with the higher trust level members to provide mentoring and training.

This is enormously powerful. In this community I am referencing in this post, we have 92 people in Trust Level 0 (which means they haven’t done very much), 92 people in Trust Level 1, and 11 people in Trust Level 2. I am working with the client to start working with those 11 people in Trust Level 2 to engage as much as possible, give them additional opportunities and responsibilities, and make them feel part of the team.

The answers to how we build great communities live in the heads of your members. Identifying these people via trust levels is a great way to build real community and team spirit.

If you found this interesting, you may also want to check out my video on Measuring Community Health and The Importance of Validation and Decay In Community Reputation Metrics.

Of course, these graphs are just scratching the surface, but they are a place to get started. What other metrics do you track? What am I missing out here? Let me know in the comments….

The post How to Track Community Growth in Forums appeared first on Jono Bacon.

Stuart Langridge: The ray-traced pictures

Hën, 01/04/2019 - 5:41md

A two-decade-long search is over.

A couple of years ago I wrote up the efforts required to recover a tiny sound demo for the Archimedes computer. In there, I made brief mention of a sample from an Arc sound editor named Armadeus, of a man saying “the mask, the ray-traced pictures, and finally the wire-frame city”. That wasn’t an idle comment. Bill and I have been looking for that sample for twenty years.

You’re thinking, I bet it’s not been twenty years. And you would be wrong. Here’s Bill posting to comp.sys.acorn in 2003, for a start.

My daughter knows about this sample. Jono knows about it. I use the phrase as a microphone test sentence, the same way other people use “testing, testing, 1, 2”. It’s lived in my head since I was in middle school, there on the Arc machines in CL0, which was Computer Lab Zero. (There was a CL1, which had the BBC Micros in it, on the first floor. I never did know whether CL0, which was on the ground floor, was a subtle joke about floor levels and computers’ zero-based numbering schemes, or if Mr Irons the teacher was just weird. He might have been weird. He thought the name for an exclamation mark was “pling”.)

Anyway, we got to talking about it again, and Bill said: to hell with this, I’ll just buy Armadeus. This act of selfless heroism earns him a gold medal. And a pint, yes it does. I’ll let him tell the story about that, and the mindblowing worthlessness of modern floppy drives, in his own time. But today it arrived, and now I have an mp3!

The ray-traced pictures. The mask. And finally, the wire-frame city.

Interestingly, I thought it was in the other order. The sample actually says: “The ray-traced pictures. The mask. And finally, the wire-frame city.” I thought “the mask” was first, and it isn’t. Still, memory plays tricks on you after this many years. Apparently it’s from a Clares sound and music demo originally (Clares were the (defunct) company that made Armadeus. The name appears to have risen from the dead a couple of times since. No idea who they are now, if anyone.) Anyway, I don’t care; I’ve got it now. And it’s on my website, which means it will never go away. We found it once before and then lost the sample; I’m not making the same mistake again. Is this how Indy felt when he found the Ark?

Also, a shout out to arcem, which is an Archimedes emulator which runs fine on Ubuntu. It’s a pain in the bum to set up — you have to compile it, find ROMs, turn on sound support, use weird keypresses, set up hard drives in an incomprehensible text file, etc; someone ought to snap it or something so it’s easier — but it’s been rather nice revisiting a lot of the Arc software that’s still collected and around for download. Desktop sillies. Someone should bring desktop sillies back to modern desktops. And reconnecting to Arcade BBS, who need to fix all their FTP links to point to telnet.arcade-bbs.net rather than the now-dead arcade.demon.co.uk. I got to watch !DeskDuck again, which was a small mallard duck that swum up and down along the top of your icon bar. And a bunch of old demos from BIA and Arcangel and so on. I’d forgotten a bit how much I liked RISC OS, and in particular that it’s so fast to start up. Bring that back.

Nice one Bill. Time for a pint.

Jonathan Carter: Free Software Activities (2019-03)

Dje, 31/03/2019 - 6:47md

Wow. March is over already. Picture above taken on weekend away on a wine farm in Robertson, Western Cape.

Debian packaging work

2019-03-01: Upload new upstream version of bundlewrap (3.6.0-1) to debian unstable.

2019-03-05: Work on updating python-aniso8601 to version 5.1.0, defer upload due to new dependency: relativetimebuilder (needs packaging).

2019-03-11: Upload live-config (5.20190312) to debian unstable (Closes: #921921).

2019-03-12: Upload new upstream version of powerlevel9k (0.6.7-1) to debian unstable.

2019-03-13: File bug for removal of stale python-fabulous-doc package from debian unstable (ROM: #924469).

2019-03-14: Upload new upstream version of gnome-shell-extension-dash-to-panel (19-1) to debian unstable

2019-03-23: Upload new upstream version of bundlewrap (3.6.1-1) to debian unstable.

2019-03-23: Work on updating gamemode (1.2-1 to 1.3-1), some build problems with inih submodules.

2019-03-23: Upload new upstream version of gnome-shell-extension-dashtodock (66-1~exp1) to debian experimental.

2019-03-24: Upload calamares (3.2.4-4) to debian unstable.

2019-03-24: Upload connectagram (1.2.9-4) to debian unstable.

2019-03-24: Upload fracplanet (0.5.1-4) to debian unstable.

2019-03-24: Upload fractalnow (0.8.2-3) to debian unstable.

2019-03-25: Upload new upstream version of xfce4-screensaver (0.1.4-1~exp1) to debian experimental (Closes: #921835).

2019-03-25: Merge MR#1 for calamares (fix typo).

2019-03-26: File ITP for gnome-shell-extension-draw-on-your screen (ITP: #925518).

2019-03-26: Upload live-wrapper (0.9) to debian unstable (Closes: #924000).

2019-03-28: Upload xfce4-screensaver (0.1.3-1~exp2) to debian experimental.

Debian package sponsoring

2019-03-10: Sponsor package jag (0.3.5-4) for debian unstable (e-mail request).

2019-03-12: Sponsor package vitetris (0.57.2-3) for debian unstable (mentors.debian.org request) (Closes: #923969).

2019-03-12: Sponsor package blastem (0.6.3-1) for debian unstable (mentors.debian.org request) (Closes: #924177).

DebConf

Lots of stuff not mentioned here, I’m just not used to tracking this, but will hopefully get better at it.

2019-03-05: Take on two new DebConf roles that will consume a lot of time in the immediate future. I’m joining Nattie in a mentoring role for the DC19 team and heading up the bursaries team for the DC19 cycle.

2019-03-15: DebConf committee meeting to decide DC20 location.

Debian quality assurance

2019-03-11: Spot check latest weekly live builds mostly to check EFI/BIOS status when installing via calamares and current status of all desktop environments.

2019-03-30: Troubleshoot grub/luks/live issues.

Debian project leader campaign

Answered lots of questions throughout the month on the debian-vote list that you can read there.

2019-03-14: Jump into the volcano and declare my self-nomination to run for Debian project leader.

2019-03-18: Submit platform for DPL election to Debian secretary.

2019:03-19: Publish blog post “Running for DPL“.

2019-03-20: Publish blog post “GitLab and Debian“.

2019-03-23: Work on platform rebuttals.

2019-03-26: Publish blog post “DPL 2019 Election: Rebuttals“.

2019-03-28: Publish blog post “Fun and Debian“.

Full Circle Magazine: Full Circle Magazine #143

Pre, 29/03/2019 - 8:30md

This month:
* Command & Conquer
* How-To : Python, Freeplane, and Darktable
* Graphics : Inkscape
* Ubuntu Devices: OTA-8
* My Opinion: GDPR Pt3
* Linux Loopback: BSD
* Book Review: Practical Binary Analysis
* Interview: Simon Quigley (Lubuntu)
* Ubuntu Games: This Is The Police 2
plus: News, The Daily Waddle, Q&A, and more.

Get it while it’s hot: https://fullcirclemagazine.org/issue-143/

Kurt von Finck: Last post. I’m gone.

Pre, 29/03/2019 - 3:57pd

Last post. I’m gone.

https://reddit.com/r/ploos

https://pluspora.com

I’m “mneptok” just about everywhere. I’ll see you all in the next life, when we are all cats.

https://youtu.be/FqHIkkRrwcQ

Ubuntu Studio: Ubuntu Studio 19.04 (Disco Dingo) Beta Released

Pre, 29/03/2019 - 3:19pd
The Ubuntu Studio team is pleased to announce the beta release of Ubuntu Studio 19.04, codenamed Disco Dingo. While this beta is reasonably free of any showstopper CD build or installer bugs, you may find some bugs within. This image is, however, reasonably representative of what you will find when Ubuntu Studio 19.04 is released […]

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, February 2019

Mar, 26/03/2019 - 1:59md

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In February, about 204.5 work hours have been dispatched among 13 paid contributors. Their reports are available:

  • Abhijith PA did 14 hours (out of 14 hours allocated).
  • Adrian Bunk did 8 hours (out of 8 hours allocated).
  • Antoine Beaupré did 16 hours (out of 19.5 hours allocated + 11.5 extra hours, but gave back the remaining hours because he wanted to stop working on LTS).
  • Ben Hutchings did 4 hours (out of 19.5 hours allocated plus 1 extra hour, thus keeping 16.5 extra hours for March).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 18 hours (out of 18 hours allocated).
  • Emilio Pozuelo Monfort did 20.5 hours (out of 19.5 hours allocated + 3.25 extra hours, thus keeping 2.25 hours for March).
  • Hugo Lefeuvre did 19.5 hours (out of 19.5 hours allocated).
  • Markus Koschany did 19.5 hours (out of 19.5 hours allocated).
  • Mike Gabriel did 6 hours (out of 10 hours allocated, thus keeping 4 extra hours for March).
  • Ola Lundqvist did 14 hours (out of 8 hours allocated + 8 extra hours, thus keeping 2 extra hours for March).
  • Roberto C. Sanchez did 13.25 hours (out of 19.5 hours allocated + 9.75 extra hours, but he gave back the remaining hours).
  • Thorsten Alteholz did 19.5 hours (out of 19.5 hours allocated).
Evolution of the situation

The number of sponsors (and thus the funding level) did not change for a couple of months. On the contributors side, we have some turn-over: Antoine Beaupré is stopping after many years of good work. Many thanks to him! Fortunately, Sylvain Beucler just started and the workload did not increase too much on existing contributors. But we are still looking for more paid LTS contributors.

The security tracker currently lists 42 packages with a known CVE and the dla-needed.txt file has 28 packages needing an update.

Thanks to our sponsors

New sponsors are in bold (none this month).

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

David Tomaschik: So You Want to Red Team?

Mar, 26/03/2019 - 8:00pd

So there’s a lot of confusion out there about Penetration Testing and Red Teaming. I wanted to put together a list of resources for those familiar with infosec or penetration testing who want to get into red teaming or at least get a better understanding of the methodologies and techniques used by red teamers.

First, it’s important to note that Red Teaming is predominantly comprised of two things: alternative analysis and adversary simulation. Red teams do not attempt to find “all the vulnerabilities” and do not usually try to have a wide breadth of coverage. Instead, red teams seek to simulate an adversary with a particular objective, predominantly to act as a “sparring partner” for blue teams. Keep in mind, red teams are the only adversary that will debrief with the blue team so that blue team can figure out what they missed or could have done differently.

For more about the specific definition of Red Teaming, check out the presentation Red Teaming Probably Isn’t For You by fellow red teamer Toby Kohlenberg.

This is not intended to be a comprehensive list of everything you need to know, but more of a “differences course” for those with penetration testing or similar backgrounds to get an introduction to red teaming.

Concepts of Red Teaming Penetration Testing vs Red Teaming Technical Resources (Not Necessarily Red Team Specific) Red Team Courses Conclusion

This is by no means a comprehensive list, and if you have other suggestions, please let me know.

Stephen Michael Kellat: Middle of March Meandering

Mar, 19/03/2019 - 4:23pd

In no particular order:

  • I finally got the Trade Name Registration certificate notification from the Ohio Secretary of State as well as the EIN issuance from the Internal Revenue Service today. Later on this week I need to go open a business bank account. Erie Looking Productions will need to grow and my current "day job" looks increasingly like it is in a bad position.

    • If people think the current chaos in the House of Commons at Westminster is bad, the federal government in the USA is set for yet another budget crisis plus a debt crisis in September. It is time to exit the insanity.

    • A "story treatment" was given to somebody to make a storyboard. Getting shown at the Dam Short Film Festival would be nice. F/LOSS tools would be used for production.

      • Eventually I intend to try Ubuntu Server installations to the three idle Raspberry Pi 3B+ boards. The ultimate goal there is for being able to offload video transcoding.

      • A subject matter has been selected that could easily be presented at somewhere like LibrePlanet or CCC. Until I leave my current job, I can't go to those events. Trying to inject awareness of certain networking-related matters into the mainstream is what I'm limited to at this time.

    • The definition on file is "Media Arts Production". That doesn't limit me to making podcasts and other digital works. Making print materials in LaTeX is something I keep trying to increase my proficiency with.

  • The HDHomeRun receivers are still operating in the hazardous environment of the detached garage. This is good. Eventually a PVR computer will be mated up outside.

  • Radio reception has been horrible. Then again, sunspots are kinda missing too. Any SDR efforts are going to have to wait. I really want to get WEFAX reception up, if possible.

  • Is it time for me to set up a MediaGoblin instance?

Michael Lustfield: Tips for Living with an Ostomy

Dje, 17/03/2019 - 6:00pd

My experience with colorectal (adenocarcinoma, T3aN0M0 [Stage 2]) cancer officially began on the 9th of October in 2017. After 8 rounds of chemo and 27 rounds of radiation, I arrived at surgery. Unfortunately, I came out on the other side of surgery with a permanent colostomy. Learning to live with …

Serge Hallyn: Unprivileged container builds using stacker

Sht, 16/03/2019 - 6:38pd

One of the primary goals of user namespaces was to provide the ability for unprivileged users to have their own range of uids over which they would have privilege, with minimal need for setuid programs and no risk (barring bugs in the OS) of their privilege having effect on uids which are not “their own”.

We’ve had user namespaces for awhile now. While there are some actions which cannot be done in a user namespace, such as mounting a loopback filesystem, there are many things, such as setting up a build environment with custom package installs, which used to be a challenge without privilege but are now simple.

My friend Tycho wrote stacker stacker as a tool for building OCI images. A few of its features include:

  • Creates OCI images.
  • Can also be used for general software building.
  • Supports layer re-use between build stages to minimize redundant I/O and time.
  • Supports unprivileged use!

To show how to use stacker for unprivileged builds, I created a little demo readme. You can see it in the README.md at my stacker-demo github repo.

Jo Shields: Too many cores

Mër, 13/03/2019 - 3:48md
Arming yourself

ARM is important for us. It’s important for IOT scenarios, and it provides a reasonable proxy for phone platforms when it comes to developing runtime features.

We have big beefy ARM systems on-site at Microsoft labs, for building and testing Mono – previously 16 Softiron Overdrive 3000 systems with 8-core AMD Opteron A1170 CPUs, and our newest system in provisional production, 4 Huawei Taishan XR320 blades with 2×32-core HiSilicon Hi1616 CPUs.

The HiSilicon chips are, in our testing, a fair bit faster per-core than the AMD chips – a good 25-50%. Which begged the question “why are our Raspbian builds so much slower?”

Blowing a raspberry

Raspbian is the de-facto main OS for Raspberry Pi. It’s basically Debian hard-float ARM, rebuilt with compiler flags better suited to ARM11 76JZF-S (more precisely, the ARMv6 architecture, whereas Debian targets ARMv7). The Raspberry Pi is hugely popular, and it is important for us to be able to offer packages optimized for use on Raspberry Pi.

But the Pi hardware is also slow and horrible to use for continuous integration (especially the SD-card storage, which can be burned through very quickly, causing maintenance headaches), so we do our Raspbian builds on our big beefy ARM64 rack-mount servers, in chroots. You can easily do this yourself – just grab the raspbian-archive-keyring package from the Raspbian archive, and pass the Raspbian mirror to debootstrap/pbuilder/cowbuilder instead of the Debian mirror.

These builds have always been much slower than all our Debian/Ubuntu ARM builds (v5 soft float, v7 hard float, aarch64), but on the new Huawei machines, the difference became much more stark – the same commit, on the same server, took 1h17 to build .debs for Ubuntu 16.04 armhf, and 9h24 for Raspbian 9. On the old Softiron hardware, Raspbian builds would rarely exceed 6h (which is still outrageously slow, but less so). Why would the new servers be worse, but only for Raspbian? Something to do with handwavey optimizations in Raspbian? No, actually.

When is a superset not a superset

Common wisdom says ARM architecture versions add new instructions, but can still run code for older versions. This is, broadly, true. However, there are a few cases where deprecated instructions become missing instructions, and continuity demands those instructions be caught by the kernel, and emulated. Specifically, three things are missing in ARMv8 hardware – SWP (swap data between registers and memory), SETEND (set the endianness bit in the CPSR), and CP15 memory barriers (a feature of a long-gone control co-processor). You can turn these features on via abi.cp15_barrier, abi.setend, and abi.swp sysctl flags, whereupon the kernel fakes those instructions as required (rather than throwing SIGILL).

CP15 memory barrier emulation is slow. My friend Vince Sanders, who helped with some of this analysis, suggested a cost of order 1000 cycles per emulated call. How many was I looking at? According to dmesg, about a million per second.

But it’s worse than that – CP15 memory barriers affect the whole system. Vince’s proposal was that the HiSilicon chips were performing so much worse than the AMD ones, because I had 64 cores not 8 – and that I could improve performance by running a VM, with only one core in it (so CP15 calls inside that environment would only affect the entire VM, not the rest of the computer).

Escape from the Pie Folk

I already had libvirtd running on all my ARM machines, from a previous fit of “hey one day this might be useful” – and as it happened, it was. I had to grab a qemu-efi-aarch64 package, containing a firmware, but otherwise I was easily able to connect to the system via virt-manager on my desktop, and get to work setting up a VM. virt-manager has vastly improved its support for non-x86 since I last used it (once upon a time it just wouldn’t boot systems without a graphics card), but I was easily able to boot an Ubuntu 18.04 arm64 install CD and interact with it over serial just as easily as via emulated GPU.

Because I’m an idiot, I then wasted my time making a Raspbian stock image bootable in this environment (Debian kernel, grub-efi-arm64, battling file-size constraints with the tiny /boot, etc) – stuff I would not repeat. Since in the end I just wanted to be as near to our “real” environment as possible, meaning using pbuilder, this simply wasn’t a needed step. The VM’s host OS didn’t need to be Raspbian.

Point is, though, I got my 1-core VM going, and fed a Mono source package to it.

Time taken? 3h40 – whereas the same commit on the 64-core host took over 9 hours. The “use a single core” hypothesis more than proven.

Next steps

The gains here are obvious enough that I need to look at deploying the solution non-experimentally as soon as possible. The best approach to doing so is the bit I haven’t worked out yet. Raspbian workloads are probably at the pivot point between “I should find some amazing way to automate this” and “automation is a waste of time, it’s quicker to set it up by hand”

Many thanks to the #debian-uk community for their curiosity and suggestions with this experiment!

Faqet